Summary
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:

1. 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.
2. Easy to Read and Write
   Some languages are very obfuscated when it comes to any kind of sophisticated code.
3. 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.
4. 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.
5. Efficient
   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.
6. Interfaces
   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.
7. Delegation
   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.
8. Parameterized Types
   Parameterized types have been in use as long as typed arrays have existed, it is just illogical to not allow parameterization of other types.
9. Imperative Programming
   Certain classes of algorithms are not easily expressed in pure functional languages. It is an arbitrary restriction which provides no practical advantage.
10. 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.
11. 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.

Talk Back!

Have an opinion? Readers have already posted 5 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Christopher Diggins adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

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.