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.
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.
Parrot 0.5.0 was released just over a week ago. As this article discusses, one of the major changes was the transition to NQP.
While NQP brings some very interesting technical benefits, it also further shows one of the significant problems with Parrot that I identified a couple of months back. Namely, the near complete lack of design and architecture stability as the project matures.
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.
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.”
When it comes to programming languages and programming technologies, I think we’re getting close to a point similar to that of twenty years ago. In 1987, many enterprise software systems were being written in languages like C, COBOL, and even PL/I at some shops. Some places were ahead of the curve, and were using Smalltalk.
When the computing world moved from manually toggling input switches to machine code encoded on paper tape, there was a vast improvement in programmer