The Artima Developer Community
Sponsored Link

Heron-Centric: Ruminations of a Language Designer
Why I Decided to Design a Programming Language
by Christopher Diggins
October 24, 2004


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!


RSS Feed


About the Blogger



Sponsored Links

