The Language of 2016? Part 1: Simple Semantics

"I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies." -- C. A. R. Hoare

It's often said that since all languages are Turing complete, you can do the same thing in any of them.

This is a dirty, dirty lie (no offense to Turing).

What you can do is get the same output from two programs written in different languages given the same input. Internally, depending on what the individual semantic models of the language are and what the desired conversion from input to output is, you will be doing very different things. If you attempted to do them both with the same methodology, you would have to implement the semantics missing from the other language in the language you were attempting to fit the methodology to.

Because at some point, you will find a problem that is exponentially easier in one set of semantics than the one supported by the language you're using, making it easy to modify the semantics of that language is critical. What's the best way to do this? Having a simple underlying semantics to the language. This will be absolutely critical to the Language of 2016.

Smalltalk and the Lisp's both practice this. Since I haven't used Smalltalk, I will refer to it via the proxy of Ruby (which shares similar semantics).

In Ruby, since everything is an object and all actions happen because of messages, I can model and manipulate new behavior easily. Changing the behavior of an object is as simple as creating a new function and slapping it into the object at the needed point. Likewise, Classes being objects allows me to talk to them and tell them how they should start acting. Since even the environment of execution is an object, I can capture that and use it to my nefarious purposes.

Lisp goes in a different, but possibly even more powerful direction. The readtime Macros allow programmers to turn semantics into syntactic abstractions with nigh unlimited power. This power is enabled because every statement in Lisp is an S-Expression: that is, the execution of some code. Because all Lisp Code is in S-Expressions and all Data likewise (after all the Data has to be stated in some form), Macros enable the manipulation of code exactly like data. Since I have little real experience with Lisp, I hesitate to venture further into a discussion about the Macro system.

Though I haven't read them yet, the two books in this area that I have heard as most relevant are The Art of the Metaobject Protocol and On Lisp.

This is an article in my series of entries entitled "The Language of 2016?"