Dart Bashing

I’m amazed at how the JS communities are already bashing Dart; even before it gets out. I can see lots of good reasons to make a new language; new languages appear almost every day, a few of them make it to real use, but most disappear. No reason to barf at them for that, if you don’t like it; just ignore it.

Now, I don’t know what Dart will be like; but as I posted earlier, the only way I can see this being successful is not trying to be a better JavaScript. It seems pretty obvious that JavaScript cannot be pushed away easily, so why even try? So, I don’t think that’s what they’ll try.

There are lots of other languages that are also not trying to be JavaScript: Java, C#, F#, Clojure, C, C++, Python, Objective-C, Ruby, Erlang, Haskell. The list goes on. Most of these target other audiences that JavaScript; they solve other problems; they are good at other things.

One of the things that are important these years to be “good at” is to build client apps; i.e. programs that run in/with the client environment (mobile apps, desktop apps, interactive web applications, …). Java never really succeeded as a client platform (Android app framework is terrible, Java on the desktop never happened); C# only so because of Microsoft’s muscle. JavaScript and Objective-C on the other hand are some of the languages that have frameworks and/or client containers that are really good for this kind of work. And I think that Google will try to — at least initially — position Dart as a language in this space of building client/GUI apps. So in that sense, it is likely to be a “competitor” for JavaScript; but that’s no reason for bashing it, is it?

There are many areas where we’ve become a lot smarter since the last batch of main stream programming languages came into existence in the mid-90′s. Java, C# and JavaScript can’t easily be changed/improved in fundamental ways because they also need to be backwards compatible to some degree. Its now more or less “common knowledge” that we’re challenged with concurrency (and utilizing multicore), and that some aspects of functional programming is needed to make this better. We now know that distributed objects is not such a good idea; it’s better to send data explicitly around and reinterpret it when it arrives. We’ve come to realize that we need a better module system than provided in those languages. It has become apparent that it is a big advantage if it is easy to create internal DSL’s, one of Ruby’s big advantages. We’ve learned a lot of things, and if the Dart team is able to wrap up those leanings of the last 15 years and repackage it as a new main stream language, there’s a good chance for success I’d say.

One example: When I was at NeXT we often talked about how difficult it is to build apps that run things concurrently — i.e. with threads. Mind you these were smart colleagues I had, and we had no idea how to do this in a proper structured way. Everything we could come up with felt like a hack; still today in Objective-C you have to be very careful to get things processed on the main event loop. In JavaScript this problem is “solved” by programming such things entirely event driven in one thread; making you program “backwards” in may ways. In Java/Swing runOnMainThread is a horrible explicit way to have to schedule things to make them “thread safe”.

But there are other options: Erlang gets this right. With message-passing concurrency and selective receive you can do concurrent and event driven programming with a lot less headaches. As it happens, Erlang just isn’t a language that comes pre-installed on all desktops (even though it is now in standard Ubuntu distribution), and Erlang also does not have a good GUI library. Erlang was not created for doing GUI programming. But the idea would fit perfectly well to do concurrent + event driven programming in GUI programs. I’ve said this numerous times, and will do again, GUI is the next killer-app for actor programming.

So that’s just one area where there is IMHO, immense opportunity for improvement. One can only hope that message passing concurrency does, in some way, make it into Dart. I am an Erlang-head after all. But even without, there is a lot of other areas in which the programming language community has learned from our troubles with the old main stream languages, and so there is amble room for improvement.

I welcome the attempt. No bashing from here.


Post a Comment