My Dream Programming Language

If one day a fairy would appear in front of me and grant me three wishes, one of them would probably be a new programming language. Here is a list of some features I really want to have in one single language. In a future post I will probably look at some already existing programming languages and examine how much current languages are able to meet my desired features.

  1. Simple & Readable Syntax
  2. Static, Strong Typing & Type-Inference
  3. Functional Programming Support
  4. REPL & Compiler
  5. Easy module/packaging system
  6. Garbage Collection
  7. Immutable Data Types

1. Simple & Readable Syntax

This should be obvious, unfortunately many language totally fail on this one. I guess the problem is to invent a syntax which is powerful and simple. There seems to be some kind of trade off between such features. The syntax of Perl is quite powerful but also ugly as hell. And although it is possible to write good, readable code with C/C++ the syntax also allows to create a terrible mess. Maybe this is only a question of personal taste. But I want a language which does not allow developers to write messy code. I personally think Python does a great job on this. Ruby is nice too, although the way anonymous functions are written is a little bit awkward. Another good example for a powerful and simple syntax can be find in Clojure, a Lisp dialect for the JVM. One advantage of Lisps in general is the ability to write macros, the disadvantage is usually the representation of formulas. However, I wouldn’t mind the fairy to give me a new Lisp dialect.

2. Static, Strong Typing & Type-Inference

Dynamic programming languages are great! Dynamic programming languages are fun! Dynamic languages are a nightmare if you reach the 1000 LOC barrier and want to refactor your code without a decent test suite. OK, I admit, refactoring without a good test suite is always a stupid idea, but it is definitely more painful with a dynamic language than with a static one where the compiler warns you before running the code. Programming using a dynamic type system allows us to write code much faster, but actually there are very few situations where you really want to have dynamic types. Just look at a random piece of code written in a language like Python or Ruby, in most cases programmers use the language like it had static types. So do we really need dynamic typing? I don’t see the advantage except for coding speed. Static types make a program much more robust, the compiler can warn us about a lot of mistakes we would usually only find after testing our code. So instead of giving up robustness for faster coding we should find a way to write programs more faster.

In many cases it is obvious what type a variable has, so the compiler should be able to figure out the type of variable declarations on it’s own. Two good examples for languages where type-inference is used are OCaml and Scala. Just look at the two following code excerpts:

(* OCaml *)
let average a b =
(a +. b) /. 2.0;;

def average(a : Float, b : Float) = (a + b) / 2

It should be clear that average is a function receiving two float values and returning a float value. No explicit type declaration must be done, the compiler can figure it out. This allows to write concise code in a short time without loosing the power of a static type system. Of course this leads to a lot of other language design question. While in OCaml there are two different plus operators + and +. for adding integer or float values, Scala defines the function + on Integer and Float objects. That’s why Scala needs a type declaration in the method header and OCaml don’t.
Anyway, type inference makes code cleaner and improves coding speed. I believe this is a good compromise for the dynamic vs. static issue.

3. Functional Programming Support

I am sick of writing the same code over and over again. I don’t know how many times I wrote a Java loop like this:

public List<element> filterMyList(List<element> myList) {
   ArrayList<element> newList = new ArrayList<element>();
   for (Element elem : myList) {
       if (elem.meetsSomeCondition()) {
           Elem result = doSomethingUseful(elem);
           newList.add(Elem);
       }
   }
   return newList;
}

Instead I want to write something like this (with type inference ;-):

def newList = myFancyList.filter(elem : Element => meetsSomeCondition).map(doSomethingUseful)

or even just:

def newList = myFancyList.foreach(elem : Element => meetsSomeCondition, doSomethingUseful)

At the first glance functional programming only seems to offer shorter, concise code, but there is much more functional programming can do. Many (object-oriented) programming pattern just disappear when using functional programming. Typically features of functional programming languages help to avoid clumsy pattern and help to write cleaner code. For example pattern matching is a great deal to avoid Visitor patterns or think of the Observer design pattern! It is a pain in the a*** to implement observer and observable objects all the time. Even in a language like Java where already interfaces and abstract classes for such pattern exist it can be quite challenging to build them into your code because Java doesn’t allow multiple parent classes (Observable is an abstract class). This can also be solved by using another design pattern like Delegation. But it seems like design pattern are often just solutions for bad language design. In a functional language a callback function is delivered to the observable and it just needs to call this function to update the observer. Absolutely simple! Further more many problems can be solved elegantly when using functions like every other type, so this is a definitely a must-have feature. Advanced functional features like Currying would also be nice, but I can live without them.

4. REPL & Compiler

I need a language having an interpreter which can be used interactively, this makes it much more simple to just try out a few things outside the usual compile-wait-run cycle. Also a compiler which assembles the code into native machine code (maybe through intermediate C code) is necessary. If I want to write some small scripts or test things I would use the interpreter. But before deployment the code will be compiled to improve execution speed. There are just a few languages which actually have an interpreter AND a (native machine code) compiler. Most of them can be found in the Lisp and Scheme scene, the OCaml compiler is also absolutely wicked when it comes to speed. I think it is thrilling to see the good performance of compiled Common Lisp, Ikarus or OCaml code especially because these languages feel mostly like scripting languages.

5. Easy module/packaging system

Recently a friend pointed out that one indicator of bad language design is the disability of a programming languages to be usable without a proper development environment. And that’s true! I want a language which allows me to easily write programs with just a text editor and a console window. Of course there are benefits of using IDEs, but the standard UNIX environment provides already a lot powerful commands to search text files, so it shouldn’t be too difficult to write code with my dream language. One feature which allows to live without an IDE is an easy syntax. The other feature would be a simple module/packaging system. Just imagine how simple it is to import a library into Python and how painful this task is in Java. Maybe Java is the best example of how to not implement a library system. It is absolutely impossible to remember package names and the fact that there is no, absolutely no similarity between library names and JAR file names makes it nearly impossible to write (or even run) Java code without a decent IDE and a build system like Ant or Maven. Here is an example of how to parse RSS feeds with Python and Java and print the title of the first feed… I hope you’ll understand what I mean ;-)

Here is the Java code, to use the code like this rome.jar and jdom.jar must be in your classpath:

> javac -cp ./lib/rome-1.0.jar;./lib/jdom-1.0.jar FeedTest.java
> java -cp ./lib/rome-1.0.jar;./lib/jdom-1.0.jar FeedTest
import java.net.URL;
import com.sun.syndication.feed.synd.SyndFeed;
import com.sun.syndication.io.SyndFeedInput;
import com.sun.syndication.io.XmlReader;
...
   URL feedUrl = new URL("https://danielkaes.wordpress.com/feed/");
   SyndFeedInput input = new SyndFeedInput();
   SyndFeed feed = input.build(new XmlReader(feedUrl));
   System.out.println(feed.getEntries().get(0).getTitle());

And the same piece of code in python (just put the code into a file names “feed.py” chmod it and type “./feed.py” into the console and there you are)

#!/usr/bin/env python
import feedparser
feed = feedparser.parse("https://danielkaes.wordpress.com/feed/")
print feed['entries'][0]['title']

6. Garbage Collection

OK, that is not a surprise. Computers are much better than human beings in finding unused memory chunks, so they should do it all the time. Alternatively it can make sense to switch off the garbage collector and do the dirty job for yourself. But the small performance loss of automatic garbage collection compared to the huge gain of cognitive resources which are now free to be used for more important stuff should always lead to the decision of implementing a garbage collector. Thanks to new multi-processor systems it could also make sense to run a collector in another process, but I leave the implementation details to the little, friendly fairy.

7. Immutable Data Types

In a multi-processor environment immutable data types are really a blessing. They allow programmers to just write code and don’t think about possible problems which can occur when two processes are manipulating the same list of items at the same time. I especially like the way Scala solved the implementation of this problem. For every type of collection (List, Map, Set, etc …) there is an immutable and a mutable type which both have the same method names. The only difference is that the methods of the immutable types returning the result, while their mutable counterparts have no return type and just change the object they are called upon. However, implementing such a feature is not an easy task, normally a copy of the original data structure is to expensive, that’s why functions returning a copy of a immutable type need to do a lot of intelligent pointer acrobatic.

Advertisements

2 Responses to “My Dream Programming Language”


  1. 1 anoymous December 3, 2009 at 1:05 am

    You might want to look at vtd-xml, the latest and most advanced xml processing model, far better than DOM or SAX

    vtd-xml

  2. 2 Arne December 8, 2009 at 6:01 pm

    You should take a look at Haskell, I guess you’ll like it.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s





%d bloggers like this: