What do you dislike most about your computer? Let me guess. It is crashing software, right? You read: „The program has unexpectly quit“ or: „A bus error occured“ or: „segmentation fault“. And then your program lies buried in the mud leaving no trace of your activity (bad case), your data (worse case) or your system (worst case).

But people stopped to wonder about it. They take it for granted. Programs do crash sometimes. It is a law of nature. But why does it happen and does it really have to be that way? The answer is simple: no. There is no need for software to crash at all. But there is an equally simple reason it does still crash. It is called C.

When the C programming language was conceived by Brian Kernighan and Dennis Ritchie, it was a revolution. It was created to be a replacement for the awkward and processor-specific assembler instructions and prepared the ground for the highly portable family of UNIX systems we all now use (except for the minority of Windows users of course :-). C was adopted by many programmers and today there is (almost) no system that does not contain at least some code written in C. The language was considered to be a high-level programming language by many and therefore was broadly endorsed as a new approach to write system and application level code.

The problem with C: it isn‘t a high-level programming language. It is more a readable, processor-independent machine code. C does not provide any kind of abstraction in terms of objects, encapsulation, polymorphism and is neither dynamic nor is it functional. Well, you don‘t have to understand all these buzzwords as there is a simple feature C doesn‘t deliver as well: memory management.

A C program has to do almost everything itself: asking the system for memory, organizing and accessing it on the lowest possible level. Access to memory is done with pointers, telling the processor directly where to look for the information.

Well, this is not a problem as long as the address the pointer points to is correct. But if the program gets confused and the address is modified by some means or other and the processor tries to access the that malformed address, shit happens. Much has been tried to prevent C programs from crashing, but as you can experience on a daily basis, they have all failed. An there is no cure. And yes, this holds true for C++ and Objective C as well.

So while C is beyond remedy, there is hope for application development. One is called Dylan. Dylan stands for Dynamic Language and is fully buzzword compliant programming language. Originally invented by Apple, this language is about to come of age.

Two implementations of Dylan exist so far. One is mature, but only available for Windows: it is called Functional Developer, it is reported to be very stable and mature, implements all the language specs and is rumored to be open-sourced somehow in the future.

The second implementation is known by Gwydion Dylan. This is a Dylan-to-C compiler (making use of C as a „low-level“ language to interface the processors) and is free software under GPL. The GD hackers are fighting hard to advance the project but there is still some way to go.

You might want to read: the Dylan Language WikiWikiWeb, the Dylan Reference Manual, the Dylan Programming book (good introduction, comparing Dylan to C++ and Java) or just a short overview of Dylan Features And Benefits.