Last week I posted a blog on the similar topic of why Ruby and RoR are not ready to be used in enterprise systems. I've got quite a discussion in response (over 30 comments) which was roughly divided in half - those who support my point of view and those who don't.

I don't use Ruby in development. I live and work in Silicon Valley and have yet to see the first person who's using it or the first project that is using it (granted I don't mingle much among those who develop website for living). But I stumbled upon an article about concurrency support (the lack of thereof to be precise) in Ruby and RoR and that's what provoked by previous blog. But...

...the funny thing is that this is really a small potato comparing to... dynamic typing in Ruby. See, I fully agree with those saying that Ruby/RoR are just in their first version and glaring wholes like lack of normal threading will be eventually patched - just look at JDK 1.0 and compare it to today's Java. No doubt Ruby, as a language and system, will mature over time. What will not mature is its dynamic typing foundation...

I can pretty much say that I belong to a silent majority that view dynamic typing as a clear regression as far as general purpose languages go. All of us used or using languages with some form of dynamic typing from time to time be it JavaScript, Tcl/Tk, Perl or Shell. Even back in 1995 we were using these languages and when Java was introduced it was a sigh of relieve, at least for a huge silent majority, with its static typing and one of the best strong typing foundation - checked exceptions leading the way in innovation here.

I remember that I felt that we can finally move away from the silliness and inefficiency of writing 1000s line of backends in Perl or C++ and move to something much more stable, robust and adequate for large projects - Java. Even in its first version Java was miles ahead of anything else for enterprise development - something its designers didn't really anticipated in the beginning. Java was and still is the best language and system for developing large and complex enterprise systems. Strong and static typing, checked exceptions, rich libraries, huge open-source eco-system, concise and familiar C-based syntax, and sane design for the most parts (thanks to the same engineering organization that produced Solaris) - all of these characteristics contribute to Java's success initially and over time.

I've read this short article on Dynamic Typing (http://www.dzone.com/links/dynamic_typing_more_superior.html) and I think it sums it up very politely and succinctly. Please, read it and especially read the comments (some of the them are truly delusional - where do these people come from?). Yes, when you write small scripts in Ruby or PHP or Perl you can get away with pretty much anything: dirty "duck typing", bizarre syntax border-lining on fetishism, no intelligent refactoring (no wonder most of Ruby-ist are working in Vi - and I love Vi, by the way), dozens of ways to do the same thing (welcome back to Perl), embedding types into variable names, spending hours resolving what should have been a compile time error (welcome back to C++).

But when you develop something more than a script on you web page or shell script in your environment using languages with dynamic typing is practically dumb. And that's the common wisdom of the silent majority. And when you read the comments on Soon Hui's articles you can really feel for McMurphy in the movie "One Flew Over the Cuckoo's Nest"...

I'm continuing previewing some of the features that GridGain team is working for upcoming release. One of them is support for RESTful applications. Basically, that's how you could, for example, invoke a grid task from your RESTful web application by pointing to this URL:

http://www.myhost.com:7080/gridgain/taskid=mytaskid&arg=myarg&timeout=5000

This will return XML document back with execution results which can be easily parsed by JavaScript in a usual Ajax way. That's it - you basically pass task ID, and optional argument and timeout and that's all it takes to execute a grid task. You can develop, test and debug your grid task as usual in any preferred Java IDE with all the productivity features that GridGain provides such as transparent deployment, our simple APIs or peer-to-peer class loading.

Note that this is exactly the same way as you would use, for example, Google Charts. Now, I don't know of any other grid computing framework that can get your Web 2.0 grid enabled easier than that!

Stay tuned and meanwhile download the current release of GridGain at http://www.gridgain.org/downloads.html