The development of programming language technology is going at a relatively moderate pace. And it seems like every new programming language tries to become the (singular) language that can be used to solve all problems, I believe that is the wrong approach since it tends to make the languages big, complex and hard to learn. This complexity is reflected in the readability and maintainability of code in such languages. According to Bruce Eckel and Neal Gafter it seems like Java is close to reaching some of those pain points.
Domain-specific languages (DSLs)
I believe a better approach would be to create small and highly domain-specific programming languages that can be mastered in a few minutes and function as specialized tools.
If you've ever done house refurnishing you know the thrill of finding the exactly right and highly specialized (frequently electric) tool for the job, it may not always be more efficient to use than a more general tool, but surprisingly often it is, and often by orders of magnitude (in user time).
I believe there is potential for similar efficiency gains by increasingly using domain specific programming languages. The alternatives to create domain-specific languages are usually to add features to already large and complex languages (not an option) or add more libraries to the large language, the latter is ok, but it can be hard to make these library APIs as syntactically efficient, expressive and pleasant to use as a domain-specific language.
Domain-specific languages - where and how?
Functional programming has in the last few years had a revival, e.g. Google's mapreduce for large-scale parallel computing, Python and Ruby adding Lisp-like features, and in upcoming languages such as Haskell and Erlang. I believe future domain-specific languages will borrow some from functional programming, but probably even more from declarative programming (e.g. Goedel or languages with inductive logic programming support, e.g. Aleph).
A typical sign of where a domain specific language could fit is when you need to write hundreds of lines of boilerplate code to get something done, and that something can be described in one sentence. Boilerplate code is in my opinion about as useful as heat from a light bulb, or noise produced by a computer. And since syntax matters I believe the syntax of most domain specific languages should resemble Python since Python leads the expressivity axis (i.e. gzip of source) of the great computer language shootout (but I am open to even more pleasant alternatives, please enlighten me). One issue with using a Python-like syntax is the representation of types, but I don't think that will be big issue for tight and highly declarative domain-specific languages.
But how should all the domain specific and other languages communicate?
Great question. Not sure, but I believe mainly through some kind of network/RPC interface. It is of course tempting to make the domain specific languages borrow from their "carrier" (e.g. jython being python + relatively full java access), but I am not sure if that is the right direction. But for runtime environments they should be both interpretable and being able to run on common virtual machines with just in time compilers (e.g. jvm). Even though there are some nice parser and compiler tools, e.g. antlr out there, I still think there is plenty of opportunity to create tools to support (rapid) development of domain-specific languages.
So I believe the number of programming languages is likely to diverge from singularity.
No comments:
Post a Comment