I recently wrote about how undetected type errors when using languages like Ruby and Python can be quite dangerous. That article has gotten some notice, with one response considering Groovy.
The article about Groovy purports to have an example of a statically typed Groovy script that compiles fine, but results in a type error at runtime. The script is:
int x = "test"
The error received at runtime is:
Several days back I wrote about how unit testing is not a substitute for static typing. A comment posted to that article by James asked for more clarification regarding what I was talking about. James wrote, “I can’t recall the last time I had Ruby code break because I tried to act on an object of the “wrong” type.” Well, I will give a simple example of how such problems arise, and how different languages deal with them. The languages in question will be Ruby, Python, OCaml and Haskell.
Several months back, there was somewhat of an uproar in the Ruby and Ruby on Rails communities when it was revealed that after two years of effort, the CD Baby Web site was abandoning their Ruby on Rails rewrite. The CD Baby site was reimplemented in mere months after returning to the use of PHP. This past week, I have been working with another company that is in a very similar situation.
As most people involved with Web development know, Ruby on Rails 2.0 was released on December 7. There was some discussion about the release on Slashdot, where I noticed some interesting comments regarding scalability in the age of Ruby on Rails.
Although it hasn’t (yet?) caught on much in industry, anyone who follows modern computing trends will no doubt have heard of D. Its Web site describes it quite nicely: D is a systems programming language. Its focus is on combining the power and high performance of C and C++ with the programmer productivity of modern languages like Ruby and Python. Special attention is given to the needs of quality assurance, documentation, management, portability and reliability. The D language is statically typed and compiles directly to machine code. It’s multiparadigm, supporting many programming styles: imperative, object oriented, and metaprogramming. It’s a member of the C syntax family, and its appearance is very similar to that of C++.
About a month ago, I considered the factors that were holding back one open source project with much potential, Parrot. Today I will do the same for another open source project: .
As the GNUstep homepage states, “GNUstep is a cross-platform, object-oriented framework for desktop application development. Based on the OpenStep specification originally created by NeXT (now Apple), GNUstep enables developers to rapidly build sophisticated software by employing a large library of reusable software components.”
Several days back I wrote about Parrot, specifically the doubts I have that it will ever be suitable for production use. A link to my article was submitted to Reddit, and it generated some discussion. From that discussion, there is one comment in particular that I would like to respond to.
Earlier today I was reading an article about Parrot. Parrot is, as stated on the project’s Web site, “a virtual machine designed to efficiently compile and execute bytecode for dynamic languages. Parrot currently hosts a variety of language implementations in various stages of completion, including Tcl, Javascript, Ruby, Lua, Scheme, PHP, Python, Perl 6, APL, and a .NET bytecode translator.”
I saw an article today, written by Clinton Forbes, suggesting that it’s useless to compare compiled and interpreted programming languages. The target of his wrath is this comparison of D and Ruby, with it claimed that it is “comparing apples to oranges.”
That is clearly not the case. It is often necessary, and quite acceptable, to compare two programming languages. Both Ruby and D allow for a human to instruct a computer how to perform various tasks. Thus they are the same thing. The execution method (compilation versus interpretation) is nothing but yet another factor to be considered when performing a comparison.
Recently I voiced my concerns about the IronMonkey effort. It aims to allow programming language implementations like IronPython and IronRuby to run on the Tamarin VM.
My main concern is with regards to the runtime performance of such a stack. In short, running a program with an interpreter that is itself running on a bytecode virtual machine embedded in a Web browser raises many warning flags. When you stack one slow technology upon another, there’s a really good chance that what you’ll end up with with be, well, slow!