God Sure Didn't Write in Java
It bemuses me to read about people who are seriously working on artificial intelligence using stone-age programming languages like C++ or, heaven forbid, Java. Take this following backstory excerpt, for example:
Sure, the thinking machine might not get finished in the 3 months that our seed money would last us. But, in the meantime, to tide us over, we’d solve a simpler problem: we’d use some of the bits and pieces of our unfinished AI engine to predict the financial markets.
The technical co-founders and I had been working on the first version of the AI engine for many months, by the time the seed funding came in. A healthy amount of software code existed (although the code itself wasn’t entirely healthy). ...
Now that we knew what we were doing better, we moved further and further away from the brain as a concrete design inspiration. ...
We found the increasing complexity of the various agents in the system was stressing the codebase. After a lot of difficult debate, we decided to grit our teeth and rewrite the core of the system from scratch. ...
Cassio proved to be an outstanding manager as well as an excellent software engineer and designer, and we let him accumulate assistants until, at one point, we had 60 people there out of a total company staff of 130. ...
We were quickly realizing what should have been obvious from the get-go – that getting our thinking machine to work could well be a multi-year pursuit. ...
The Webmind system we had a month ago consisted of over 750,000 lines of Java code. ... Most of the 750,000 lines of Java is still useful — it covers issues like communicating with other software processes, balancing processing among different machines, reading parameters from files, and so on and so forth. Necessary infrastructure. ...
I reckon that, at this point, I’m at serious risk of becoming the Charles Babbage of AI. Babbage designed the first computer — a purely mechanical computer, pre-electronics. But it was just too damn complicated to build using the technology he had at his disposal. He spent all his money and his life on it, and never got it done.
— Ben Goertzel, Waking Up from the Economy of Dreams
If you’re going to attempt scaling the formidable, cloud-obscured peak of Mount Intelligence, you’d think that choosing the best possible toolset would be of some importance. While you might certainly overcome a small hill even crawling barefoot, blindfolded, and with your hands tied behind your back, why in the world would you suppose that this approach could possibly apply to the single most difficult climb out there?
If a lot of very smart people working on artificial intelligence using one of the most powerful programming languages known to man didn’t make all that much headway, it’s safe to say that programming in Java, a language explicitly designed by good programmers for average programmers, isn’t going to cut it.
After all, it’s no coincidence that the phrase artificial intelligence was first coined by John McCarthy, the very same guy who invented Lisp. Solving difficult problems necessitates better tools than solving easy problems.
Lisp’s significance rests on some fundamental tenets, which is why the language has since its inception invited cosmic comparison. Adventurers setting out to conquer Mount Intelligence would do well to heed the advice from the song God Wrote in Lisp Code
I was taught assembler in my second year of school.
It’s kinda like construction work — with a toothpick for a tool.
So when I made my senior year, I threw my code away,
And learned the way to program that I still prefer today.
Now, some folks on the Internet put their faith in C++++.
They swear that it’s so powerful, it’s what God used for us.
And maybe it lets mortals dredge their objects from the C.
But I think that explains why only God can make a tree.
For God wrote in Lisp code
When he filled the leaves with green.
The fractal flowers and recursive roots:
The most lovely hack I’ve seen.
And when I ponder snowflakes, never finding two the same,
I know God likes a language with its own four-letter name.
Now, I’ve used a SUN under Unix, so I’ve seen what C can hold.
I’ve surfed for Perls, found what Fortran’s for,
Got that Java stuff down cold.
Though the chance that I’d write COBOL code
is a SNOBOL’s chance in Hell.
And I basically hate hieroglyphs, so I won’t use APL .
Now, God must know all these languages, and a few I haven’t named.
But the Lord made sure, when each sparrow falls,
that its flesh will be reclaimed.
And the Lord could not count grains of sand with a 32-bit word.
Who knows where we would go to if Lisp weren’t what he preferred?
And God wrote in Lisp code
Every creature great and small.
Don’t search the disk drive for man.c,
When the listing’s on the wall.
And when I watch the lightning
Burn unbelievers to a crisp,
I know God had six days to work,
So he wrote it all in Lisp.
Yes, God had a deadline.
So he wrote it all in Lisp.
Incidentally, by far the best introduction to Lisp with a classic-AI bent is Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp , written in 1992 by Peter Norvig, now Director of Research at Google. This book is something special that should be on every programmer’s bookshelf, and it certainly demonstrates why Lisp is uniquely suited for tackling hard problems such as AI. As a shortcut into the mind-expanding aspects of learning Lisp, I would even recommend this over newer introductory books.
The Lisp song is freely redistributable provided it isn’t altered. Muchas kudos to Bill Clementson for the pointer. Oh, and just so there’s no confusion for the too literal-minded: “God”, in the scope of this article, has nothing whatsoever to do with the Christian deity nor any other purported supernatural entity of your choice.Novamente, the successor to WebMind, implements LISP-like internal constructs as a core part of its design. From the Novamente FAQ under the “Why C++?” section:
Novamente’s “internal procedures” are autogenerated (by internal learning procedures) by the system in a language called Combo that has more in common with LISP or Haskell than C++ (it’s purely functional).
Combo is a simple programming language designed (mainly by Moshe Looks) for use within the Novamente Cognition Engine. Novamente Schema are represented internally in a format that is easily translatable into textual Combo programs. Combo has been described as “LISP with a bad haircut,” and with a bunch of primitives designed specifically for interaction with other aspects of the Novamente system.
@Simon: Indeed! That sure would explain a lot ;-)
@David: Thanks for the update — I understand that you’re involved in the present effort? In that case, let me first say that it’s a laudable undertaking and I’m certainly following the results with much interest. However, the FAQ entry you pointed me at reads a bit like a C++ apologist’s defense, and seems to indicate that there indeed is some dissatisfaction with (or at least need to defend) the current toolset.
If so, I would respectfully suggest that the text there betrays total unfamiliarity with Common Lisp, both in principle and current implementation status. Even for the moment ignoring all unique features and productivity advantages of Lisp, the specific high-level dynamic language limitations mentioned in the FAQ don’t quite apply, either:
- GC was originally invented for Lisp, and you can get pretty darned fine-grained control over it in the best modern Lisp implementations. No other programming language directly benefits from so much directed research into advanced GC techniques. (See some sample research papers.)
- Similarly, due to some 40 years of compiler research for dynamic languages, Common Lisp is these days usually compiled down to machine code, and performance is comparable to C/C++. There’s no need to use several other languages for prototyping purposes; just stick with the one.
Glad to see that Greenspun’s Tenth is doing all right, though — and the Haskell mention certainly gives some hope :-)
Actually, anecdotal evidence that there exists in this world at least 1 clueless idiot who happends to use doohickey X (in this case, java), is not proof or even indication that doohickey X is bad. For someone who is very aware of mathematics and logic, one would expect this to be quite obvious :-)
Fortunately, there’s an analogy to this observation: Anecdotal evidence that there exists in this world at least 1 logic-impaired blogger comparing his favourite doohickey Y (let’s say, for argument’s sake, lisp), to being ‘godlike’, is not proof or even indication that users of doohickey Y are all elitist bastards.
That second observation seems useful somehow.
I don’t mean to impinge on your stance here; not writing AI projects in the language used by the leading researchers is certainly a strange and probably ill-fated choice, but I seriously doubt these guys would have gotten anywhere with LISP, either. I’m just questioning the implications of this post.
I know pointing and laughing at idiots is fun, I mean, there’s a reason American Idol is such a successful enterprise, world-wide no less. Perhaps I overreact.
@Reinier: Excellent, glad to have some pushback :-) Note, however, that I did not (in this particular opinion piece, anyway) actually claim that Java is universally “bad”, merely that it’s not a particularly powerful tool for a problem this complex.
To use an analogy, a kitchen knife is not inherently a “bad” tool just because a surgical scalpel happens to be a more advanced instrument. If you’re going into brain surgery, I’m sure you’d prefer the use of the scalpel, but on the other hand, the kitchen knife would do just fine for cutting bread. (Well, I actually compared Java to something like a flint knife, but you get the point…)
In addition, the quoted article itself has little to do with my opinion that Java isn’t up to the task (though a figure of 750KLOC for “infrastructure” code does tend to support that position). Perhaps I’ll elaborate my take on Java’s specific deficiencies at some future time, albeit plenty of people have already previously done so and I’m not sure how much new I could possibly add. I think I’ll rather focus on writing about the specific unique advantages of Lisp, and folk can then always do a diff with some other language to get a feel of that language’s evolutionary status.
Now, in this particular case I didn’t get into any further analysis since I think the excerpted article pretty much speaks for itself, and not just from a technical viewpoint. So, possibly you have too high expectations for a mere rant ;-)
Given the amount of computation power any strong-AI system would doubtless need (I’m sure estimates vary but I think most people would agree there is no way you could write a self-conscious piece of software that ran in real-time on a single (existing or foreseeable in the next decade) processor, and probably you’d need hundreds or thousands at a minimum), my tendency would lean towards a language like E (or maybe Erlang, if you must be “fashionable”), since a lot of your effort and bugs will come from distributing the stuff properly (one good argument for E over Erlang here is that there is an E implementation built on Common Lisp, so you can implement your low-level or GOFAI code in CL (or in C/asm through your CL’s FFI, if need be, rather than having to drop directly to C as typical in Erlang).
Last I heard, the Singularity Institute is also attempting to build their AI system in Java. Which is one of the reasons I don’t think they’re ever going to get anywhere (not that an AI couldn’t be implemented in Java, but doing it with a very small number of people, and using a language that forces you to write a lot to say relatively little, seems like it doesn’t make things any easier).
To say it shortly: the biggest difference between so called static and dynamic languages is that the latter’s programmers spend most of their time arguing on how superior their language is, and the former’s ones just write code.
There is plenty of Java and C# code just begging to be used, free libraries for nearly every task on earth while most software libraries written for dynamic languages fall into the category which some people call advocacyware (that is, software that crippled that it’s plain unusable and the only purpose of its existence is to be mentioned in advocacy arguments, as in “of course, common lisp can do threads portably”).
@Jack: Yes, gratuitous verbosity sure doesn’t make it any easier. On the E and Erlang note, you might be interested to check out Termite, an Erlang-like concurrency model implemented on top the Gambit-C Scheme system and capable of supporting millions of concurrent lightweight processes.
@Albert: You’re reading this on a site built using a dynamic language ;-) Sounds like you hail from a rather interesting niche in the B&D-oriented software ecosphere that dynamic languages haven’t at all penetrated to yet. Even ignoring Lisp and Smalltalk, your claim is rendered fallacious by Perl, PHP, Python and Ruby, all of which have been around for a while now.
Albert: that’s because programmers who prefer dynamic languages spend much less time writing boilerplate and redundant code, so they have a lot of time to argue how their languages are superior :)
Actually, God hacked most of it together with Perl.