# Give Me a Real Programming Language The modern programming language is a complex and beautiful thing. Decades of research have gone into making it, and great accolades await anyone who can make even the slightest of improvements. The idea of "visual programming", expressing programs not as simple text files but some kind of rich, graphical, colourful view (usually based on some kind of "flowchart"), has been a perennial favourite, fruit for numerous PhD theses. Of course, each year no more than a handful of new languages gain any kind of traction, and not one visual programming language has ever been widely adopted. So why do so many companies seem to think they can do better? All too often a system requires a turing-complete configuration, but we users are made to express it in some custom, tool-specific language - or worse, by dragging and dropping in some GUI. The worst case I've seen is the ESB that IBM tried to sell to my previous company - a software company, no less. The idea of a tool that would let non-programmers program is appealing, for obvious reasons - but it proves too much; if there were such a tool, companies would be using it already for all their programming, not just for this particular tool. The recent [case against cucumber](http://blog.8thlight.com/kevin-liddle/2013/09/18/a-case-against-cucumber.html) is a good example of the general problem with this kind of tool. Even tools by and for real programs aren't immune from these problems. Consider ant, which used an XML syntax which rapidly expanded into a full-blown programming language, complete with <if> and <for> tags - but not the kind of language a sane developer would ever use. An XML/json/yaml document for configuration is an excellent idea if your system's configuration is truly declarative (e.g. Maven). But if you're going to use a Turing-complete build system, you need a reasonable syntax for it. You need to be able to modularize your code; you need a good library of standard datastructures and testing support. You need an editor that understands the language... in short, you need all the things you need in a regular programming language. So far better to use a tool like SCons or SBT where you express your build in an established programming language. It seems impossible to design a "domain specific" language beyond a certain level of power without it becoming a full-blown programming language - perhaps because programming is all about abstraction, and so a sufficiently powerful language can always abstract away from the domain. This is, in my view, the reason why XML+XSLT failed and has been displaced by modern client-side rendering in javascript. XSLT was a language explicitly, carefully designed for a single task - transforming XML from one representation into another - and it *sucked*. Javascript isn't even a very good general-purpose programming language, but it still turned out to be far better suited for this task. Can it go the other way around? Yes - the format for sendmail's config file, M4, was eventually released separately as a programming language in its own right, and enjoyed some minor success (autoconf is written in it). But most companies would think twice about trying to write a programming language, even one with the modest ambitions of M4. But they somehow fail to realize that once you offer a sufficiently advanced configuration format, that's exactly what you're doing. If you're reading a declarative configuration, stick with a standard declarative format like json, yaml, or even XML - better that than the awkward half-xml of e.g. Apache's configuration file. If you need something more powerful, consider embedding a scripting language designed for that purpose - [lua](http://www.lua.org) is a popular option, although javascript via [Rhino](https://github.com/mozilla/rhino) is becoming increasingly popular. That way at least your users will have access to a wider ecosystem, and corporate clients can hire programmers relatively easily, rather than needing people with experience with your specific product. And whatever you do, stay away from creating a graphical programming language. Better people than you have tried and failed. [Home](/) <div id="disqus_thread"></div> comments powered by Disqus