MIND YOUR LANGUAGE!

Spring at last! Along with planting the potatoes, it’s as a good time as any to write a new programming language. But why on earth would anyone need a new language? There are dozens – hundreds – of the things around right now. Choose the one you want.

Writing your own language for a specific job seems a bit eccentric. A bit like forging your own spade when all you need is something to plant the potatoes with. But computing is different – especially when you get into the really big projects. Big engineering projects often get specialist tools built. Take building a tunnel - the EuroTunnel, for instance. I’m no expert in holes, but I suspect that the machines that did the boring weren’t exactly ‘off the shelf’ items.

Similarly, I’d argue that if you are designing a big project, it’s better to construct a language suitable for, say, writing health applications (having ‘Doctor’ as a keyword, for example). The current way that big projects, and many smaller ones, are run is that the designers talk to the users and produce a specification which is then implemented by programmers. I’ll say this slowly: it hasn’t worked; it doesn’t work and it will never work.

There’s a classic cartoon sequence illustrating the system design process. The cartoon starts out showing a simple swing attached to a branch of a tree – ‘what the user wanted’. Then follow a number of drawings, each becoming more ludicrous and impractical as the ‘system’ goes through specification, design, implementation, etc. The final image shows a totally unusable swing – ‘what the user got’. It’s all too close to what actually happens in practice.

What the cartoon misses out, though, is the stage after – the management consultant part. The only thing that management consultants do well is employ more of their own kind, until you end up with an infestation of zombies bleeding the project to death. If you ever find yourself working in a company or on a project where management consultants are used in a serious manner – get out. Fast. It’s a sure sign that management has lost the plot.

Domain Specific Languages

Rather than ending up at the terminal ‘management consultant stage’, a better approach would be to design a language suitable for the project in hand and then train the programmers to write in it. Hell, train the users to write in it. A doctor or a nurse has a far better idea of how a health clinic runs than a software architect. These mini-languages are often termed ‘domain specific languages’ or DSLs. Take VBA (Visual Basic for Applications). That’s a DSL – a pretty general one, it’s true, which lives in many Microsoft applications such as Excel or Word.

In the past, writing a non-trivial DSL was pretty difficult: almost the equivalent of writing a general-purpose compiler. I’ve personally only ever seen one decent sized example - a risk management system written in Smalltalk. The idea was that the architects would write language tools that would allow financial specialists (not programmers) to write the applications. I’m not sure of how well the system worked out. I suspect that given the nature of Smalltalk, it proved to be rather too object oriented (and slow) to be sufficiently flexible for the financial specialists to build systems rapidly enough.

In finance, specifically in risk management, the best systems I’ve seen are written in C++ (warts and all). This is because many financial ‘instruments’ are slight modifications of an existing instrument. Object orientation works well in this ‘program-by-difference’ world. Also, C++ is fast – again an advantage in the specialised area of financial derivatives.

But now it’s quite possible to write your own language using widely available tools. The two tools I’m currently using are the Antlr parser (www.antlr.org) and Visual Studio 2005. Antlr is a recursive descent parser (technically an LL(k) parser) that makes designing and building you own language a breeze. It’s one Java application I’ve come across that’s genuinely useful; the alternative is to use the standard C Bison and Flex (YACC/LEX) parsers. Having used both, I can tell you that an Antlr language is an order of magnitude faster to develop and debug than a language specified in YACC/LEX.

You could, of course, develop your own language using Notepad to edit it, with print statements to debug it – but you probably wouldn’t want to. This is where Visual Studio 2005 comes in. Using this, you can develop a language ‘package’ – much more than a Visual Studio ‘add-in’ – to edit, compile and debug your new language. I’m not normally a fan of Microsoft where language developments are concerned, but I think that Visual Studio is simply the best development environment around. It really is an excellent tool.

You Say Tomaytoe, I Say Tomartoe…

If you’re going to be an unadventurous soul and stick with the existing languages, what choices have you got? For general purpose work on a Microsoft platform, you’d be hard pushed to chose anything other than C#. It’s good, fast, well-supported and C# programmers are readily available. Why choose anything else? And in the future there’s Language Integrated Queries (LINQ) coming up on the horizon. I won't go over the Visual Basic argument again. Suffice it to say that I don’t think VB has a future in its present form.

What about Java? I can’t put my finger on it, but I get a whiff of decay about Java. It’s no longer the sexy upcoming language that it was. After a slow start, I think that C# is getting the edge over Java, partly I suspect because of Sun’s obsession with trying to take on Microsoft on the desktop. I really can’t see any point in Sun putting a whole load of money into desktop infrastructure (Swing, etc). Almost nobody uses Java on the desktop. Sun would be better off putting its money where Java is used: web business logic.

But Java for writing business logic and web database applications is about as unsexy and boring as it comes. Java only thrives because Microsoft can’t be bothered to put any effort into Mono. The best positive reason I can think of for using Java is that Sun isn’t likely to ditch it and leave its loyal customers high and dry.

Turning to a world elsewhere, Smalltalk has popped up on my horizon again after a long absence. But there’s a question to be answered here. If Smalltalk is that great – and I really do think it’s a nice language – why hasn’t it become anything more than a boutique? The reason has to be that it’s so monolithic. Other languages produce exe and dll files as standard; Smalltalk prefers to produce an ‘image’ which is the world as far is it is concerned. Smalltalk really is an island unto itself.

That leaves Perl, Python and Ruby. Apart, of course, from the few hundred languages I don’t have the space or time to discuss – Miranda, Haskell, ML, F#, Scheme, Caml, BCPL, Snobol - name your favourite. To my mind Perl is quite decent – I’ve used it extensively – but difficult to maintain. I wouldn’t want to write a big application in it; it would cost too much to keep going. Python I know nothing at all about apart from the fact it has nothing in common with snakes. Sorry – life is short.

But Ruby … well, Ruby is ‘interesting’. Ruby is a sort of amalgam of object oriented bits from Smalltalk, scripting from Perl and straight procedural code like C#. Unlike Smalltalk, Ruby doesn’t hit you over the head with objects. You can write in a pretty un-object-oriented way with Ruby if you want. The Ruby ‘mix-in’ mechanism is also a very pragmatic and useful way of integrating into the outside world.

Unfortunately, Ruby is very much a work in progress. Don’t be seduced by the hype into thinking that Ruby is perfect. It isn’t, as you’ll find out if you try to do any serious work in it. It’s still the case that there is no perfect language. Apart, of course, from the one I’m writing...

Bytegeist Archives