Language Oriented Programming: Everything is a Language

Some people don't 'get' Language Oriented Programming. It's a different perspective. Once you make the mental shift, everything starts to fall into place. Over the past few months, I've been looking at the software development world with LOP-coloured glasses, and I've come up with a quick zen-slap phrase which I hope will help shift your paradigm.

(If that last sentence made you think, "I hate the word 'paradigm'! It's a meaningless marketing buzzword," then read this before reading on below.)

Everything is a Language
Just as OOP introduced 'everything is an object', I propose for LOP that 'everything is a language'. Keep this in mind as you read about and discuss software, and suddenly things will look very different to you. But what the heck do I mean?

Programming is Communication
When you want to communicate an idea to someone, how do you do that? You use the tool that Homo Sapiens 1.0 has evolved over millions of years: Language. You'll speak, you'll make gestures. If you want the communication to last over time, you'll write it down in symbols. These days you can use fancy tools like keyboard, mouse, digital memory, and graphic display to write these symbols.

Now, when you want to instruct a computer, how do you do that? You write symbols using keyboard, mouse, digital memory, and graphic display. You're doing the same things, but instead of communicating ideas to people, you are communicating ideas to the computer. Now, of course, there are a couple of important differences, such as the fact that there are strict rules on which symbols are used and how they are arranged, and also the fact that the symbols have a very precise, concrete meaning (e.g. '2 + 2' actually performs a physical action in the computer to produce the symbol '4'). However, at the end of the day, a programmer's work primarily involves communicating to the computer via language.

The Editor is the Medium
Before I go into the examples, there is one important thing to know. Language does not exist without a medium. Spoken words require a mouth to speak, air to propagate sound waves, and an ear to listen. Sign language requires hands to make the signs, light to carry the image, and eyes to read the signs. Writing requires a pen, paper, and eyes. Programming requires a keyboard to type, an editor to accept the input, and a compiler or interpreter to execute the program. Take away any of these things, and communication is much more difficult.

Marshall McLuhan tried to emphasize this fact by saying that "the medium is the message". He, perhaps, overstated his case for emphasis. But the fact remains that the medium of language is an important, indispensable part of the language. So I will now put '2 + 2' together to state something that will likely bother some hard-core programmers: The editor is an important, indispensable part of the programming language. The editor is the medium of the programming language.

Examples
When you start to think 'everything is a language', you will start to see computer languages everywhere.

JUnit and TestNG
JUnit is the most popular unit testing framework, but there are many clones and variations. They are all languages. With a unit test, you attempt to communicate to your system that, when the environment is set up in this way, this is what you expect, and this is what actually occurs. But have you noticed how ugly it is to write a test that says "this method should throw this exception"? That is because JUnit is written in Java, and the only way to do this in Java is to wrap the method in a try/catch statement. JUnit is a language on top of Java. Notice how new frameworks such as TestNG try to modify Java (with annotations) to make writing tests more natural? That is because they want to be true languages.

EasyMock and jMock
The Mock Objects pattern is another language, and two popular frameworks again try to adapt Java into a mock-object language. EasyMock uses dynamic proxies to generate mock objects on the fly. But notice how you have to have this clumsy MockControl object to specify return values and exceptions? jMock goes further than EasyMock, allowing you to specify in a fairly natural way the expected inputs and outputs. But notice how you lose Java's language support for interfaces; instead you have to specify method names with Strings, making refactoring method signatures with an IDE more difficult. And while writing mock expectations may be fairly natural, it's actually not very natural at all; it doesn't look like a normal Java method call as it would with EasyMock. That's because both of these frameworks are languages on top of Java. I think it would be great if my editor allowed me to write out the expectations using special notation that isn't possible in Java, like this:

myObj.myMethod(obj equals expectedObj, date between startDate .. endDate) returns expectedResult;

XML this and XML that
Have you noticed the proliferation of all these XML dialects? Why is that? It's because XML gives you a standard and relatively easy way to invent your own languages. The parser is already built, all you need is a DTD for your syntax and to wire up the grammar to your Java (or other language) objects for your semantics. Ant is one example, but there are zillions more. Obviously, there is a need for the ability to easily create specialized languages. This is one of the primary forces behind Language Oriented Programming.

Struts, Spring, and Rails
Web frameworks are yet another kind of language we are seeing a lot of these days. Notice how Struts defines page navigation using XML, extends JSP with tag libraries, and provides special facilities with its class framework? I wonder why such a project as Struts Console exists, or the various IDE plugins. Could it be because Struts is a language? Spring wires up your application with a configuration script (hint: in its own specialized XML language). Rails rewrites entire classes, re-interprets method calls, and has dozens of other meta-programming tricks just to make your life easier. These frameworks are all attempts to work around the deficiencies of their host languages. Imagine the power that would be possible if they could be languages in their own right, with things like IDE support, refactoring, and whatnot. (I'm talking about LOP, people.)

Aspect Oriented Programming
Why isn't it popular? No IDE support. 'Nuff said.

Ruby, Python, PHP, and even JSP
Dynamic languages are on the rise. Why is that? Let's put on our LOP glasses. Static languages are great because you get lots of support from your tools. The compiler gives you lots of hints, and can do things like optimize your code. A smart IDE like IntelliJ IDEA can make judgments about code, allowing static analysis, refactoring, code completion, and navigation. But static languages also have some downsides. Every little detail has to be specified, sometimes more than once. Little errors can blow up in your face if you're not disciplined in your coding practices.

Dynamic languages make a trade-off. They try to be more flexible, and get out of the programmer's way, at the expense of losing some of the features of a static language. Sometimes, this trade-off is in the interests of the programmer. With more mature languages like Ruby and Python, the advantage is slowly tipping more and more in favour of dynamic languages. Wouldn't it be cool if you could have the power and flexibility of a dynamic language, with all the extra cool features of a static language, and a kick-ass editor to boot? Hmmm.

So...
Keep your eye out for this stuff. It's going to become more and more obvious to you. All you have to remember is that everything is a language.