Wednesday, October 03, 2007

The Preference for Hard Languages

A language is a tool. When skilfully used, it allows you to craft great works. This is the same for computer languages. Engineering a good piece of software is, more art than science. The skill in designing and writing pieces of code that function seamlessly is like that of a sculptor, who is constantly crafting his works to achieve perfection. Those little touches of detail on usability and functionality, or in just providing a sensible error prompt, are equivalent to the amount of detail a dedicated sculptor puts in, chipping away the pieces of imperfection to reach the ultimate state of beauty.

Unsurprisingly, some tools are better than others. A chisel is and a hammer is better used for carving rocks than sandpaper is. A stick of dynamite makes it faster to shape Mount Rushmore than with just a pair of chisel and hammer. In the end, it is a matter of choosing the right tool for the right job.

It is not uncommon to come across people who are adamant on their choice of a 'hard' language when it comes to writing software. But the myth about computer languages is, that 'hard' is really subjective.

The choices of newly popular languages like Python or Ruby is generally no harder than old school languages like C or Java. 'Hard' languages can be easily spun around and to be interpreted as 'easy'. Easy because it will allow you to write solutions with considerable less lines of code.

Prolog and Lisp are more suited for solving logic problems, like the 'Missionaries and Cannibals' problem. It will probably just take a skilled programmer less than 10 lines of code to solve, whereas the same thing will take a good C or Java coder hundreds of lines to accomplish.

Conversely, higher level languages take away the nitty-gritty details of the underlying hardware for which may sometimes be undesirable. Someone can write a Ray Tracer in Python or Ruby, but nobody will expect the language will be a real fit, or to be executing at a speed that is of any realistic practicalities. Abstraction has its cost, and while this cost may be acceptable for some classes of applications, will not be so for others.

In the end, the choices of languages are all about its expressiveness and suitability. For people who love the self-celebration of their choice of 'hard' languages, it either smacks a sense of insecurity seeking justification, or a case of 'the person with a hammer' - everything else looks like a nail!

Such people if they can't stop ranting about how hard or cool 'language X' is, my remedy is to recommend them to learn Malbolge, the language that is hard. Good luck trying to code in that :)

0 comments:

Post a comment