Top 8 Features of My Dream Programming Language
Reading Steve Yegge’s recent blog posting outlining what he claims will be the Next Big Language (NBL) got me thinking about things I would like to have in my ideal programming language. Here, in no specific order, and with no claim for completeness (and trying to avoid the obvious ones which everyone else has covered ad nauseam) are my top language features for My Dream Language. I’ve covered some of these points before, but since then some new ones have come up.
Object-orientation
Any new language has to be object-oriented from the ground up. Python’s self parameter always makes me cringe, as it exposes that object-orientation was slapped on as an afterthought.
Multiple inheritance would be useful, but can lead to “strange” designs. A single-rooted hierarchy where everything is an object and is polymorphic to the common base class is vital. This means no int which is incompatible with an Integer and cannot be put into a bag of Object. Operator overloading should be supported on all types.
Strong concurrency support
Strong support for concurrent, multi-threaded, multi-processor development should be built into the language, as should the required synchronization mechanisms. Modern machines come with high-performance multi-core processors. A good new language should allow application developers to make use of these.
Java has pretty good concurrent programming support, which I use a lot. Using any object as semaphore (block/pass) is quite helpful. One problem I have with Java’s concurrency support is that it involves way too much syntactic overhead for small concurrent tasks. Subclassing Thread, possibly in an inner class, overloading run(), etc. just makes what is a very nice language feature look very messy.
Mix of static and dynamic (duck) typing
I agree with Steve’s assessment that it makes sense for a new programming language to allow dynamic typing for the prototyping stage but also to provide a strict typing idiom for those cases where you really need to rely on type checking for correctness and compile-time error detection. I actually like the strictness of statically typed languages and the design-by-contract idea they impose (i.e. I say you have to give me a String, so giving me anything else is an error). This makes it especially easy to document and understand software. When learning a new library, there’s a lot that can be learned about its methods just by seeing which types of parameters they take.
The downside of that, though, is a lot of syntactic overhead which you have to tackle even in places when you don’t really need typing. Good examples of this are the earlier Java’s collection classes such as Vector, Hashtable, etc., where a lot of casting has to be done simply to use them. Generic types improve the situation a lot. But still — sometimes you just want a bag of things and don’t really care one way or another what’s in them.
Transactional access to data structures
Seriously. Transaction support (ACID, implying all-or-nothing behaviour) as a programming language concept (should probably be optional, since most applications don’t really need it). In many business applications (as well as in many Web applications) transactional access to variables and data structures would be very useful. Mutually exclusive transactions, with all-or-nothing semantics, with the ability to be notified on commit and rollback. Coupled with strong concurrency support (see above) this would allow some pretty cool solutions to what could otherwise be rather tricky problems.
Sure - we can supply this by doing all our data structure modifications in the database and relying on the database support for transactions. But a) in doing so you incur a performance impact and b) not everything really belongs in the persistent data model. I really want transactions which, on undo, revert all temporary variables back to their previous state.
Readable syntax
i.e. no PERL. ’nuff said.
Interactive Shell
I like Python’s interactive shell which allows me to quickly try out something, with full access to the language libraries, etc. Whether it’s just to quickly try out a library method or running a test case in my own implementation without the need to write a main method and run that, interactive access can really speed up development.
Good IDE support
I’m totally in love with IntelliJ IDEA as a Java IDE. Its refactoring support is incredible. It’s find support (”Find usages of” on anything instantly shows you where that item is accessed, including indirectly through use of setters and getters) is nothing short of brilliant. Every time I use another IDE (including Eclipse), development feels slow and stupid and I feel as though I’m confined by the IDE rather than supported by it. So any new language would have to have IDE support at least as good as IntelliJ IDEA.
Easy deployment
An ideal language would provide great deployment support. Whether deploying your application as a local desktop application, as a Web service or Applet-style in a browser, deployment should be easy and consistent. This includes consistent and strict use of configuration options (i.e. if you’ve configured one application developed in My Dream Language, you know immediately where to go for the other ones and how the configuration works). Having a consistent and descriptive configuration interface for deployed applications would allow a central configuration tool (GUI, wizard, whatever) on each user’s platform of choice, which would only have to be developed once for each platform.
Tags: programming language; software development; language design.
Bookmark on del.icio.us
Add this post to digg.com
Bookmark on reddit.com
July 7th, 2007 at 5:38 pm
I agree with all points…and would like to add
Pattern Incorporation-
I have to develop applications that run on PocketPC, WindowsCE, Windows Desktop (any flavor), Tablet, SmartPhone, of course the Web, etc. I’m lucky I’m only dealing with Microsoft OSes as far as you can consider yourself lucky in that regard. There is talk of opening our backend to run on unix based system. Then some genius realised Macs run on a unix based backend so they are considering opening the UI to macs. You can imagine the nightmare.
A development language and IDE combination that lent itself to things like the MVP pattern would be extreemly useful. I could remove UI logic from the model and possibly only face a recompile on each target platform and/or OS. As it stands now I have to implement everything regarding an MVP pattern myself. Imagine an IDE/Form designer where you drop a TextControl on the form and the IDE asks you whether or not the Text property should be bound to the view and presenter…. It wouldn’t fix everything but it would raise refactoring to a higher level of architecture vs. plain coding.
Design by Contract:
You touched on this but I would like to expand a bit. Microsofts R&D team came up with a pretty cool model for doing Design by Contract work using Attributed programming. Check out Spec# and XC# for examples. I was somewhat put out that Microsoft did not include these in the 3.0 framework because I don’t see any disadvantage in doing so. With attributed programming you can literally take it or leave it.
For example: I write a method defined as
string DisplayPercent(int percent)
{
return string.Format(”Percent = {0}%”, percent);
}
Anyone can realize that the parameter passed in should be a value from 0-100 inclusive. However, as we all know, this method may be called 1000 times. Why check to see if the parameter “percent” is between the range through code? Let’s have true design by contract where we can set the valid values at the method level through attributed programming that can be picked up by not only the compiler but the runtime.
[ValidateRange(”percent”, 0, 100)]
string DisplayPercent(int percent)
{
return string.Format(”Percent = {0}%”, percent);
}
Let the attribute throw an ArgumentException to the caller not us.
If built into the compiler:
DisplayPercent(500);
should display an error during build. Obviously percentages and go below 0 and above 100. I’m only illustrating a point.
Now consider your documentation as a class library author. You could easilly pick up on the Attributes rather than method body code to create documentation of what the method requires to execute correctly.
Just some thoughts. Love the blog been reading a bit and posted earlier.
Dave Jellison