Heron-Centric: Ruminations of a Language Designer Why I Decided to Design a Programming Language by Christopher Diggins October 24, 2004
I designed the Heron programming language because, like many other programmers, I was dissatisfied with other languages. In this entry I list some the features that what I was looking for in a programming langauge.
The answer the commonly asked question: "Why did you write a programming language" is that I am dissatisfied with the other programming languages that I have studied, worked with or come into contact with over many years of working as a software developer. I have consistently found myself fighting the language to get it to do what I wanted, correctly, succintly and efficiently.
Over time I developed a feature wish list for my ideal programming language. Rather than being a reasonable man and adapting myself to existing languages, I decided to design my own programming language. Here is a summary of the feature wish list that inspired me:
OOP (Object Oriented Programming)
Encapsulating data and methods is one of the best things to happen in computer science since the invention of the subroutine.
Easy to Read and Write
Some languages are very obfuscated when it comes to any kind of sophisticated code.
User Defined Value Types
Without value types it means we are stuck with whatever primitives the language designers decide to throw us, along with whatever predefined
behaviours. No matter how hard a language designer tries, it is virtually impossible to provide all of the conceivable
value types a programmer may need.
First Class User Defined Types
Too often in languages user defined types are either inefficient, or crippled in some way when compared to the
built-in types. For instance, many languages don't allow casting but the built-in primitives follow
magical promotion rules. This is frustrating and unneccessary.
Moore's law not withstanding, software shouldn't be a needless cpu or memory hog. Because today's software is more
sophisticated, and more is expected from it, efficiency is as much a concern now as ever.
Object oriented software design starts with interfaces. Unfortunately most interfaces are implemented as abstract base classes. ABC's are slow, inefficient, and force pointless virtualization of functions, just to achieve a degree of run-time polymorphism.
Sometimes delegation of interface implementations to member fields makes much more sense in a software design than simple inheritance. There is no reason not to have this functionality.
Parameterized types have been in use as long as typed arrays have existed, it is just illogical
to not allow parameterization of other types.
Certain classes of algorithms are not easily expressed in pure functional languages. It is an arbitrary restriction
which provides no practical advantage.
AOP (Aspect Oriented Programming)
Aspect oriented programming allows full use of PwC (Programming with Contracts) by making it easy to express invariants.
It also allows us to simply express some otherwise very complex designs.
No Garbage Collector
Garbage collectors are inefficient, and they make it hard to use the useful RAII (Resource Acquisition is Initialization) technique.
I would rather have control over memory management, but have help doing so from the language.
Have an opinion?
Readers have already posted
about this weblog entry. Why not
If you'd like to be notified whenever Christopher Diggins adds a new entry to his weblog, subscribe to his RSS feed.
Christopher Diggins is a software developer and freelance writer. Christopher loves programming, but is eternally frustrated by the shortcomings of modern programming languages. As would any reasonable person in his shoes, he decided to quit his day job to write his own ( www.heron-language.com ). Christopher is the co-author of the C++ Cookbook from O'Reilly. Christopher can be reached through his home page at www.cdiggins.com.