roestava

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.

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.

Maybe with static typing and bytecodes the author was meaning lower level and hence riskier stuff. Not that Dart was lower level.

By being higher level Dart can work from a subset, keeping the surface area smaller as a result.

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.

Cheers.

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.

In other words, you find it more advantageous to be a late adopter, which is fine as well.

Letting the market to select the tools you'll be using seems like a standard approach to most people.

Early adopters can be such trouble makers. All tools bring tradeoffs with them and many times early adopters don't anticipate them all.

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.

Yes, Dart. It's a Google sponsored language that's shaping up great. http://www.dartlang.org/

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.

With Ruby folks can always try to remove redundancy. :-)

I find it amazing that "DRY" has become such a positive pattern when it was touted as one of the driving points of the Ruby on Rails framework. Don't repeat yourself.

For instance, Java folks are always ready to throw exceptions instead of letting stuff resolve itself if it doesn't quite work.

There has been a huge incentive for operating systems to try to adapt to the laptops and smaller form-factors distancing themselves from the age-old desktop form-factor. We all have been affected by that push at some point. Ubuntu has been no different.

Ubuntu more than any other has tried a bit of everything. I've long settled on the Xfce version called Xubuntu. So after trying Unity for a couple of hours after installing the recent Ubuntu I could just install "xubuntu-desktop" and be done with it, back to my trusted experience.

Interestingly, many users seem to settle on the default experience and then feel cheated when it changes to something they don't like. Users coming from Windows found home in some version of Ubuntu. Then felt cheated when it changed some more.

Experienced users have all of this baggage, all the learning they have undergone... But the Linux distros namely Ubuntu want to try to make something for people who have barely used a computer, pushed by partners like Dell and so on.

Windows too has changed a lot throughout versions. The lucky ones kept on using Windows XP.

The syntax may be a mixed bag. Some old and new stuff. The problem is that they didn't try harder and instead preferred explicit code too much in my opinion. I still like Go, but its main selling point in my opinion is that programs written in it start fast enough. Maybe a second important feature is that deployment is helped by statically linked programs, where one .exe is all you need.

That sends me back to the Delphi days and I'm not too happy either. Because Delphi provided those kinds of features and we ended up losing it in favor of Java and .NET craziness.

The thing is, Go web apps start faster in the App Engine than web apps made with some of the other languages and also may take up fewer resources. That means that App Engine applications can be scaled up and down because spinning up new processes (with Go apps) is instant.

Here's an example:

    $ cat hn.go && 8g hn.go && 8l -o hn hn.8 && time ./hn
    package main

    import "fmt"

    func main(){
      fmt.Println("Hello HN!");
    }
    Hello HN!

    real	0m0.002s
    user	0m0.000s
    sys	0m0.000s

Cheers.

Go is cool. Go isn't too fast and doesn't have as much tool support as Java/Xtend. Go may be great if you're doing network programming on Linux. Like many tools originating from Unix environments, the cross-platform support may not be a top priority.

You're set as you already use Eclipse. :-)

It's not an easy comparison to make, yes. But Go isn't really that low level. It has garbage collector, type inference, unique concurrency support that hides threads... And it's provided on App Engine.

App Engine also supports Python and Java. I figure folks could use Xtend to write Java web apps that cut some of the boilerplate and perhaps even deploy to App Engine, for instance. Giving folks an alternative to going with Go as a static typed language.

Perhaps Xtend using Java source-code as an intermediate medium confuses people a little. Using Eclipse to program using Xtend/Java may just be too seamless for it not to matter much after you've grown used to it.

I'm sorry to say, but I think the Go programming language has just been owned by this Extend programming language for Java. Go missed the boat when it did not include some minimum class support to appease the developers used to Java, C++, and so on.

I'm not sure either. I can tell you this. A couple of days ago I tried using TorqueBox with JRuby. After struggling a little getting the right JRuby (within TorqueBox) to get started and finding out what to do with Rakefiles, I managed to get a simple "Hello World" kind of Ruby (Rack) app running with it in-loco. I just went to the directory of the config.ru file. Created a Rakefile there. Then ran commands like rake torquebox:deploy and then rake torquebox:run

It started the JBoss process and at the end of it loaded my simple app. I tested it a little on the browser and ran the Apache benchmark tool on it like ab -n 1000 -c 10 http://127.0.0.1:8080/hello

After it had warmed up, further benchmark runs were much faster.

On my weak hardware, going up to 2.2k requests/second or something. I was like "wow! Give me more of that." Not really that it couldn't be matched by other technologies for that kind of stuff, but that it was a single process easily configured.

If we think that the same process could be shared by many other scripts, programs and so on, it's a good way to reuse all of that in innovative ways.

Deep down it's not much more than having a stable multi-threaded environment that you can rely on.

Then I thought: wait! When I started with Ruby, I was running from all of that kind of complexity!

It's as if we were being assimilated by Java again. Only this time we don't have to use so much Java or xml.

Inter-operating between processes is difficult and may be inefficient. That's why languages try to call each other's libraries within the same process.

By embedding Ruby or Python within the Java Virtual Machine or the .NET CLR you start your program/library with a single process.

For instance, Ruby by default didn't have great concurrency so users ended up spawning more processes to handle amongst other things concurrency. JRuby's selling point is that you don't have to work with so many processes and you can instead rely on the battle-tested multithreading of the JVM. It opens up the chance for more bugs when using threads, but you do cut on the need to use so many processes.

Besides, scripting languages have always made it easier to string together a program for testing, managing and prototyping. Not only do you not need to spend time recompiling programs in scripting languages, but you also have more freedom regarding your code. Java for instance demands one class per file. With a scripting language, you can have as many as you want. With a scripting language you don't need a Makefile as it's easier to use just a few files to get your job done.

Now you could question the need to have so many different scripting languages. But you could also question the need to have so many different non-scripting languages as well.