Need for a business language

As many of my readers already know, I work for SAP. It is my personal belief that SAP R/3 is so successful only because of its ABAP system. The language provides the right level of abstraction and has appropriate tooling to build business applications. I learned ABAP only a year before (while I have been with SAP for over 3 years now). I was amazed by the speed and agility with which you could create a database driven application and expose your business logic to the outside world in minutes.

The language, as any old language, has its idiosyncracies. But the way it handles database interactions with transparent and internal tables and "Open SQL" is really cool. I haven't programmed in the OO version of ABAP yet. But at initial glance it seems to have been corrupted by the idea of OO from C++ and Java. No one could have put it more adequately than Alan Kay himself.

I invented the term Object-Oriented, and I can tell you I did not have C++ in mind. -- Alan Kay

As we move on to the new decade, we are in need of a language that is closer to the business roots. A language that can be molded to best describe the problems in the business domain. As a hacker, the language that immediately comes to my mind is Lisp. Unfortunately, Lisp is not taught in schools as much it should be taught.

In an excellent essay by the folks from AdaCore, they express their concerns about using Java as the first language that is taught to programmers.

It is our view that Computer Science (CS) education is neglecting basic skills, in particular in the areas of programming and formal methods. We consider that the general adoption of Java as a first programming language is in part responsible for this decline. We examine briefly the set of programming skills that should be part of every software professional’s repertoire.

Further in the essay they insist on why Lisp still matters. (Emphasis mine.)

Why Lisp Matters

Every programmer must be comfortable with functional programming and with the important notion of referential transparency. Even though most programmers find imperative programming more intuitive, they must recognize that in many contexts that a functional, stateless style is clear, natural, easy to understand, and efficient to boot.

An additional benefit of the practice of Lisp is that the program is written in what amounts to abstract syntax, namely the internal representation that most compilers use between parsing and code generation. Knowing Lisp is thus an excellent preparation for any software work that involves language processing.

Finally, Lisp (at least in its lean Scheme incarnation) is amenable to a very compact self-definition. Seeing a complete Lisp interpreter written in Lisp is an intellectual revelation that all computer scientists should experience.

Page 13 of this book(PDF) by John McCarthy is literally the source of intellectual revelation.

Eric Raymond's essay was one of the reasons that I started learning Lisp. He has the following opinion on Lisp.

LISP is worth learning for a different reason — the profound enlightenment experience you will have when you finally get it. That experience will make you a better programmer for the rest of your days, even if you never actually use LISP itself a lot.

I strongly suspect that the source of the "profound enlightenment experience" lies somewhere in understanding the code in Page 13 of the book.

I do not insist that the new business language has to be lisp. But lisp is the only language that satisfies such criteria. Problem domains keep changing and the by far the only language that is agile enough and malleable to fit the problem domain is lisp. Note that I am not saying that we would have to use Scheme, Common Lisp or Arc. I am just saying that we need a language similar to these. It could as well be a lisp written on top of any of these lisps, CLR or JVM. What matters here is the language - a formal notion to express our ideas. The compiler, VM and the platform are implementation details. Paul Graham explains this nicely in a rather long essay titled "The Hundred-Year Language".

But you might argue that Java and C++ are established languages. People are creating enterprise software with Java and C++. Why should we change? But look at the enterprise software carefully. Most of what took man years to implement in Java/C++ could have been achieved with much less effort using Lisp. Or if the system was well designed using the popular knowledge of design patterns that has evolved in the community, you would have created half of the abstractions present in lisp anyway. This is called the Greenspun's Tenth Rule of Programming. Although it explicitly states C or Fortran, I believe that it holds good for languages like Java too.

"Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp."

- Philip Greenspun

Even the co-auther of the Java language spec, Guy Steele, accepts that Java is no match for the features in Lisp.

And you're right: we were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp. Aren't you happy? -- Guy Steele

Why are we still targeting Java as the language of choice to build business applications? The cool kids have already moved to Ruby. But wait, I heard Matz said something about lisp.

Some may say Ruby is a bad rip-off of Lisp or Smalltalk, and I admit that. But it is nicer to ordinary people. - Matz

Its time to revive the 50 year old language and start to rediscover the language used by our previous generation.





As Kernighan and Ritchie once suggested -

The only way to learn a new programming language is by writing programs in it. - K&R

Keep coding. You know I am (in Lisp).