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).

AppEngine and the MicroISV

Amazon pioneered the effort of providing computing and storage resources as a services like S3, EC2, SimpleDB, SQS and so on. There were rumors that Google would come up with something like this but boy did they surprise everyone. Instead of exposing individual services they have now exposed a coherent framework to build applications on Google scale infrastructure.Google AppEngine used in conjunction with Google Apps for your domain is a brand new market for microISVs to target. They could develop enterprise applications on Google scale hardware and have it integrate with the rest of Google's application suite. Google already had provided Sites and Page Creator. These were at best very weak for an organization's web presence. With Google's AppEngine small and medium scale organizations can look at Google AppEngine as a serious option for their enterprise IT system.

Google Apps for your domain, for those who were living under a rock, provides GMail, GTalk and collaborative office suite for free or for a small fee. Imagine the tons of money that you save on licenses if you had to use Windows servers for your domain and email. Even if you had chosen Linux, the costs of administration and anti spam filtering and the hardware for the servers simply do not exist with Google Apps for your domain. It was almost good for enterprises but not good enough. They still had to worry about their ERP, CRM and other enterprise TLA systems. Salesforce was an option but something was still off with it. That's for a different post.

Google, with its new AppEngine offering, has opened the floodgates of various applications that can be hosted on Google scale infrastructure with pay as you use model for application resources. This is just as Nicholas Carr from the IT doesn't matter fame suggested. Google is commoditizing the computing resources. This is a disruptive innovation which would change the dynamics of how applications are created. It wouldn’t be long for Google to provide a repository of applications that you could just deploy with a click on your domain. Currently Google AppEngine allows you to write applications in Python. They have very clean APIs for integrated User authentication, mail integration, ability to build mashups using the URL Fetch API and store data on Google's BigTable. Google has said that it would add support for other languages. But who needs other languages when you have Python. :-)

Google's offering levels the playing field for ISVs looking to build web-based enterprise products. So, stop reading and start coding. You know I am.