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.
Users of of dynamic languages such as Python, Perl and PHP, are often faced with the additional task of ensuring that type-related errors do not occur in their programs at runtime. Some authors [1, 2] claim that this can be done effectively by the use of extensive automated unit tests. However, practice has shown this to just not be the case.
For the past couple of weeks I have been working with a very interesting system administrator. He’s responsible for maintaining a large number of Web servers, mail servers, and database servers. Like most system administrators, he employs a number of scripts he’s developed to automate a variety of tasks. While most sysadmins would use a language like Perl or Python for developing their scripts, this fellow uses Haskell. Of course, I asked him why he used Haskell. His answers really aren’t surprising to somebody who has used Haskell before.
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.
There was some discussion at Slashdot recently about bloat-free software. Many people were giving examples such as Firefox, Opera, and GIMP. But when it comes to truly bloat-free software, I think NetBSD is a perfect example.
Necessity is part of the reason why NetBSD is bloat-free. A bloated operating system just cannot run on the wide array of vintage hardware that NetBSD supports. So bloat-avoidance is an integral part of their development philosophy.
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.