Ruby is so unique. Back when I was also surprised by Ruby's reflection and metaprogramming features. So much easier than it was in the languages I had used before.
Nowadays I see people wanting to change Ruby to be more like those other languages. Needless to say, Ruby is best when all of Ruby is available. Putting restrictions on it wouldn't begin to turn it into what some people want.
On the server-side, people can use all kinds of languages, with no restrictions on choices. That's why these languages can flourish. On the client-side we are more restricted. The industry gets to dictate what goes on the client-side more.
Sigh.
I'm trying to use Dart lately which compiles to Javascript. While it can seem a bit like Ruby in OO and dynamic typing, it's a world of difference in other regards. Languages like Ruby that can evolve while breaking backward compatibility have more chance to be useful out of the box.
Hehe. I guess Dart users are troubled by it as well because the way it works is surprising based on our previous experiences. Basically you can run the program in checked mode so you do get more feedback from the usage of the types. But checked mode is meant for development as it isn't as optimized as in other languages. We need to recall that Dart gets translated into JavaScript and adding type checks and stuff to all the code required puts an extra burden on it that can be hard to justify.
All in all, you should run in checked mode for more feedback. The idea is that you get warnings when stuff is bad. When stuff is super bad you get runtime exception.
Dart is optimist and will give you warnings and let your code run until it cannot.
I certainly agree that the translated JavaScript shouldn't need to enforce types in any way, unless Dart provides some kind of "downcasting" mechanism to give something a type it doesn't already have. However, that only applies if the Dart compiler doesn't statically enforce the types when compiling the code to JavaScript.
For one example: Haskell's strong static types all go away when you compile; the generated code does not do any type enforcement or verification.
The biggest thing I hoped the article would talk about got shot down in the very first section, which just said "Dart is dynamically typed" and explicitly dismissed any need to justify that, other than by saying "Users of dynamically typed languages ... will understand why we chose this".
I honestly can't even begin to understand why people consider dynamic typing a feature; when I saw the headline I hoped to see an interesting justification, but instead I saw it taken as a given and then used to justify many other things. I agree that almost all of those things do follow naturally from the assumption of dynamic typing, but I'd still like to know the rationale for that assumption.
The only justification I've ever seen for dynamic typing amounted to "because I like duck typing". However, a static type system can trivially enforce duck typing.
Dart is built with c++ and the algorithms won't always be super-optimized. I'm a little skeptical regarding performance as well, but the idea is that Dart makes code a little more static than JavaScript and that can help with calling methods in tight loops for example. If anything, it will allow Dart to close the gap to more static languages in that regard. More optimizations will only be possible with the longterm success of the platform. And for that will have both JavaScript and Dart.
That's a good point to make. Miguel de Icaza has said that after taking a brief look at Dart he thought it was pretty academic. Maybe he was refering to more than the optional typing that Dart makes use of. The truth though is that Dart is in some ways experimental while folks such as Miguel are sitting on already established tech in c#. They aren't going to welcome potential competitors.
I recall Pascal and C when I was starting out and how tough it was to grasp them. But I also had trouble with Perl when I first encountered it. I got quite a bit done with some languages based on basic and with Delphi, when I could finally understand some of the errors I used to get with Pascal.
Based on my experience, I'd say that errors you get help you with learning about languages that make those errors evident. I learned about recursion before I learned about getting the compilers happy, for instance.
It's funny though that I can count Python as one of the languages that I've barely used and learned simply because I was never too fond of it.
Anyways. I think Ruby is a fine language as it resembles basic and doesn't demand ";" and parentheses, and it also has great OO support which helps with the documentation and even IDE support. With name completion, for example. Methods in Ruby are very straightforward and control-flow structures are plenty capable in Ruby. Not having to declare variables can also help, and Ruby does report some errors quite handily.
I prefer white backgrounds out of habit. So my terminal is white, text editor is white, browser is white, Linux desktop theme is brighter...
I must say that other users may well like it the other way, because when I used to browse for GTK themes on the http://gnome-look.org/ site, many of the new themes were cooler when they were darker...
BTW, I just found out the http://gnome-look.org/ itself is whiter and brighter. Oh the joy! Cheers.
With JavaScript ordinary developers hit a wall at some point and can't make further progress. Like Java has shown, how good the language is seems secondary to how good the implementation, the runtime, is.
JavaScript runtimes have kept on improving and with the V8/Node.JS combination have started taking over the server-side code.
With careful engineering, developers can get even further with just JavaScript the language. I wonder for instance whether using the Google Closure Tools can bring more gains there. Such tools help with checking the code for common pitfalls and the style guidelines also help a bunch. Plus, they might help with deployment, with the packaging for the specific program you've written so you don't need to package up all the library with it. Then you don't need to feel ashamed of making use of lots of library code, if only the part of it that you're using gets deployed.
Still, working with JavaScript directly can also bring debugging challenges, even more when you're trying to debug code that has been mangled since leaving your library source files.
Languages like CoffeeScript and Dart have success because the alternative in pure JavaScript is still quite painful, as I've mentioned above. It's a mistake to dismiss languages like CoffeeScript and Dart because you want that 50% extra performance.
Still, CoffeeScript is a concept. It could be said to have been over-engineered in places. Some of the stewards of JavaScript would have found it better if it was more like a JavaScript with JSLint turned on and some niceties on top of it.
Just to clarify one thing, it's very unlikely that you'll take a 50% performance hit when moving from JS to CoffeeScript. That may be true for Dart as well--I don't know.
Also, since CoffeeScript transcompiles to JS, it will generally reap the benefits of future improvements to JS runtimes, packaging tools, etc.
Dart goes beyond what CoffeeScript offers. For instance, Dart can use a lot of library code and try to produce a final script that ships only the methods your program uses.
Dart has many parts to it. There's a Dart Editor that uses Eclipse as a foundation but actually strives to be a lightweight editor. The Dart compiler shipped with the Dart Editor is the more stable one in my experience, but it tends to produce scary JavaScript at the moment. If you tell it to produce "optimized" JavaScript it will try harder to make the final script smaller, but it isn't too pretty. The Editor will get some good debugging features soon.
Then there's a new compiler that's still being developed for Dart called Frog. It actually produces much more decent JavaScript code.
And there's a VM for Dart that's useful for testing and developing smaller scripts that can run without the browser. There's a promise that the VM will be integrated with a branch of the WebKit browser component which should help with making use of the VM in a browser environment. Maybe next week we'll get a first version of it. (I speak as a user.)
As they say, the sky is the limit. I'm excited and have written thousands of Dart code, much of which has been converting my JavaScript library code to Dart.
I do like it. It compares well with my Ruby code which is saying a lot. :-)
A lot of years ago when I started with Ruby, one of the first things I cared about was how easy it was to write OO in Ruby. I like it perhaps even better in Dart. Ruby has features that Dart will never have, not to mention that once Dart is released it may stop evolving, whereas Ruby that has evolved so much will continue to do so.
Nowadays I see people wanting to change Ruby to be more like those other languages. Needless to say, Ruby is best when all of Ruby is available. Putting restrictions on it wouldn't begin to turn it into what some people want.
On the server-side, people can use all kinds of languages, with no restrictions on choices. That's why these languages can flourish. On the client-side we are more restricted. The industry gets to dictate what goes on the client-side more.
Sigh.
I'm trying to use Dart lately which compiles to Javascript. While it can seem a bit like Ruby in OO and dynamic typing, it's a world of difference in other regards. Languages like Ruby that can evolve while breaking backward compatibility have more chance to be useful out of the box.