Google's Dart is nothing new

Ran across Google's Dart programming language today with an announcement they made.

Those design goals are interesting. Hrmm. Only Node.js and GWT target client and server? How about Fantom and haXe? I suspect there are many more. I'm just mentioning ones that I'm most familiar with. I haven't gone on a link search.

I think Fantom is especially aligned with many of the goals of Dart. But making one's own language is fun (and time-consuming). Been there before myself. Maybe again someday. In addition to having been around longer, Fantom has the benefit of the compiler being implemented in Fantom. Dart seems not to be self-hosted yet. Maybe they'll get there someday.

Meanwhile, if Dart sounds interesting to you, I'd recommend taking a look at Fantom first. It even has Eclipse and NetBeans plugins already.

Update: It seems Google Dart has some Eclipse IDE stuff in the works, but I'm having trouble finding detailed discussions on it.

Update 2: I also missed the native VM. With the compiler in Java, I wrongly assumed the whole back end thing was Java-based despite their discussion of a VM for Dart.

Update 3: It seems Gilad Bracha's involved, and the type system is more dynamically-focused than I thought at first glance. I'm concerned that making types too optional will make code tooling weaker, but maybe they have clever tricks planned for performance and tooling. (I mean, V8's pretty good at performance with little-to-no static type information at all.) On the happy side, generics are reified.

Thanks for git, Google!

I assume everyone else is in the know by now, too, but I still wanted to say a public thank you to Google for supporting git at Google Project Hosting.

Now I need to decide if it's worth the effort to consider switching from GitHub. I don't even know if Google supports the sweetly convenient ssh keys thing. At first glance, I don't see it.

At least I know git is an option at Google now, should I decide to go back.

Node.js on the way

I've been becoming a fan of Node.js. Liberally licensed, V8 speediness, JS enjoyment. I haven't followed all the news, and I'd missed the recent great announcement of Microsoft helping with first-class Windows support. Also, while job listings for Node.js are still few, they are caught up to Erlang and keeping pace with Scala.

I look forward to JS replacing Java (and the JVM) all around someday.

Robots that eat

For years, I've been occasionally distracted with a fascination about robots that eat, either plants or meat or whatever. I have not investigated research in artificial chemical reactions of this sort for producing energy, but I suspect some work has been done (such as this example).

I think a carnivorous robot could also make a great just-barely-sci-fi story. Probably also been done. There's nothing new under the sun. I just haven't run across it myself yet, nor have I searched such a thing out much. I'm not much a fan of horror, so I wouldn't take it there myself, but I don't mind getting a bit edgy and uncomfortable. I think it could be well done.

In any case, just got reminded of that notion by this blog post. I haven't actually watched the mentioned ads yet, but I'll likely get around to it.

And, of course, solar powered robots are a lot more palatable (pun considered) to our sensibilities and are clearly practical for some situations.

Coburn vs. Robots

It seems that Senator Coburn (of the state of Oklahoma, where I currently live) has decided that research in domestic robotics is wasteful.

I beg to differ. (Another example of someone else who also differs.) General purpose robots are a bit pie-in-the-sky but are also amazingly important, in my view, both to understanding who we are as people and in their possible pragmatic application. Domestic tasks are often at the center of this, in my view.

Say we did shave the 1-3 billion dollars that Coburn thinks could be saved through better NSF management. Sweet, that's like up to 0.4% of US military funding.

I don't have numbers on it, but a couple of years ago, I sat with a small group of researchers at a robotics conference who were lamenting how far behind the US is in robotics research, at least outside the military perspective. Supposedly, at least Europe and Japan do a much better job of funding basic robotics research. I wonder what the effects might be of that? Hard to say.

I agree research funding is hit and miss, but so is entrepreneurship or anything else in life. And I'd love to see more robotics funding in the US, not less.

Cloud Robotics vs. Safety

So, with Google also now pushing cloud robotics, it seems likely to get more and more attention. However, I want to see more discussion of safety on the matter.

I mean, didn't we already have a Will Smith movie implying safety risks for combining the internet with robots? Robot perception is linked with behavior, and if either perception or behavior can be downloaded at any moment, there had better be some serious safety mechanisms outside of any such easy cloud intelligence.

There really needs to be some underlying primitive coping level that enforces certain levels of safety, there needs to be serious levels of "don't dare touch this without top security clearance" baked in.

As long as we are talking toys, maybe it's not a big deal, but anything strong enough to do real work is strong enough to cause damage, and that needs secured.

Native ROS (Robot OS) for Java ... and MATLAB?

So, Google and Willow Garage just announced about an alpha-status pure Java implementation of ROS, the robot operating system (from Willow Garage). ROS in some ways is just another messaging system, and there are already about five billion of those in Java. However, it's also getting serious traction from all over the robotics community, has lots of ready-made robot awesomeness, and nicely seems to be overshadowing non-open competitors in robot middleware.

They are pushing it as a solution for Android. Android-brained robots are cool, but in our lab (and others), we use MATLAB a lot. There presently isn't any stable support for MATLAB is ROS, just GNU Octave. We have connected ROS with MATLAB, but the software hasn't been much more stable than the official support from Willow. Though I've been dodging Java since the Oracle lawsuit, I'm seriously planning to try out the new rosjava as a MATLAB option. MATLAB integrates easily with Java. Just import packages/classes, and use them.

As a side note, it seems like the new rosjava (unlike normal ROS) supports multiple nodes per process. I'll have to see if I can work multiple Java threads into communication with the main MATLAB thread ...

WebGL not there on Firefox, either

I recently lamented the lack of general support for WebGL in Chrome. Here's what Mozilla says about the state of Firefox WebGL. Google says they are working on a software renderer for Chrome.

However WebGL reaches the masses, I have to say that it's not there yet. I'd consider it an early adopter technology at best. Would it have been better to focus on older OpenGL features to reach everyone today? Or is it better that they focused on the current modern, so that we don't regret old lock-in later? Whatever is best, I think WebGL will be safe to use for most of the web in about 5 years or so. I say five years because we need time for implementations to stabilize, support more drivers, use software rendering effectively, old computers to get replaced, and so on.

That's my guess. Five years. So 2016, I guess. (And I'm ignoring IE. I consider IE only as relevant as Microsoft wants it to be, by playing nice with everyone else.)

We'll see if I'm being too conservative.

But 2016 is still cool. Arbitrary 3D awesomeness. And I suspect JS will run very close to native speed by then, too.

What platform are you targeting for 2016?

Bullet in JS

I've recently found node.js bindings for Bullet and a JS port of JBullet. I'm not sure whether either supports hinges or capsules or other things I like. Lousy LGPL on that port. Not sure about the license on the bindings.

Or maybe JigLibJS is the right thing to try?

Maybe robot sim in browser will come before too many years.

Chrome WebGL a no go, methinks

So, Chrome has WebGL on by default ... if you have hardware OpenGL 2.0 support, so far as I can tell. Well, I suppose modern Direct3D support on Windows would also suffice, given their ANGLE compatibility library.

One of the Linux computers I use regularly has no such support, so WebGL content doesn't render at all. Said computer is a little over two years old, so I suspect I'm not the only one with problems.

Saying "Sorry, the web doesn't work on your fairly modern computer" isn't good enough.

Until WebGL just works on everyday computers and handhelds across Chrome and Firefox and Safari (and Opera?), it's a no go for me.

Anyway, if I'm misunderstanding the state of Chrome WebGL support, let me know, but for now it's just vaporware in my book.

Web server in CoffeeScript and Node

So, here's a first stab at a web server using CoffeeScript and Node:

# Imports.
{createServer} = require 'http'
{parse: parseUrl} = require 'url'
{readFile} = require 'fs'
{resolve} = require 'path'

# Setup.
base = "#{resolve('.')}/"
log = console.log

# Server definition.
server = createServer (request, response) ->
  reqPath = parseUrl(request.url).pathname
  filePath = ".#{reqPath}"
  status = 500
  respond = (content) ->
    response.writeHead status,
      'Content-Length': content.length
      'Content-Type': 'text/html'
    response.end content
    log "#{request.method} #{reqPath} #{status}"
  # Verify the path is local to the base!!!
  # TODO Better startsWith
  if resolve(filePath).indexOf base
    # TODO status = forbidden?
    respond("")
    return
  # Handle the request.
  if request.method is 'GET'
    readFile filePath, (err, data) ->
      if err
        if err.errno is 2
          status = 404
        data = ""
      else
        status = 200
      respond(data)
  else
    respond("")

# Start the server.
port = 8080
server.listen port, ->
  log "Running on #{port} from #{base} ..."

Not so bad. Probably could be cleaned up. I get tangled in CoffeeScript sometimes, but usually it's straightforward.

I don't drink coffee, but this is nice little scripting all right.

Python import angst

I've said it before, and I'll say it again, Python importing stinks. Either you corrupt your module namespace, or you put imports in all your individual functions. Both are horrible options.