The curious incident of the Lisp in the night-time
Gregory (Scotland Yard detective): "Is there any other point to which you would wish to draw my attention?"
Holmes: "To the curious incident of the dog in the night-time."
Gregory: "The dog did nothing in the night-time."
Holmes: "That was the curious incident."
- "Silver Blaze" (Sir Arthur Conan Doyle)
Yesterday, I heard a lecture by David M. Baggett, a well-known software businessman. Baggett was a co-author of the world-famous game "Crash Bandicoot" and co-founder of ITA Software. Baggett credited a number of things, including luck, with the success of his ventures -- but did not mention Lisp even once.
I can think of a number of possible reasons for this omission. But perhaps it boils down to the simple fact that even a truly-superb marathon runner, when showing the world his gold medal, would rather not mention the seven-league boots he wore.
Not to put a positive spin on your take, but perhaps, Law of averages is at play?
Dear Lex Lapax,
The key role of Lisp in both of Baggett's ventures has been widely-known for years. And both have already been sold to megacorporations. So I don't see how Paul Graham's article about keeping one's secret weapon hidden from competitors could apply here. I should also note that his latest venture doesn't have the "scent of Lisp" at all. Certainly not in the sense of standing head and shoulders above the competition with respect to functionality or programmability, at least.
Yours,
-Stanislav
If you'd looked at either ITA or Crash at a similar stage of development, you wouldn't have detected those attributes either.
Dear Dave Baggett,
If you’d looked at either ITA or Crash at a similar stage of development, you wouldn’t have detected those attributes either.
Fair enough. Now brace for some real criticism:
I admit that I remain puzzled as to the question of what your product can accomplish which I do not already get from Google's Gmail - without having to use a closed-source operating system and run a closed-source app on each of my machines. The entire concept of Inky seems to have a very 1990s feel to it - from the proprietary desktop app to the assumption that ordinary users are still bedeviled by an ocean of spam (I almost never see spam, and due to no effort on my part.)
Yours,
-Stanislav
Opinon noted.
Dear Dave Baggett,
To be fair, I'm probably not your target market. I can only assume that you've found someone, somewhere, who has hinted at being willing to pay for such a thing. Or maybe some very... optimistic... investors. In either case, best of luck.
Yours,
-Stanislav
I didn't mention lisp because it's pretty tangential to the stories, and I was trying to cram nearly 20 years of my life story into 45 minutes.
That said, we didn't use lisp in a functional programming way at either ITA or Naughty Dog: at Naughty Dog we used an unusual lisp-syntax language called GOOL that wasn't in an way an FP language, but was very compact and pragmatic for writing the character control logic. As well, all my work on the rendering pipeline and collision detection systems was in C and R3000 assembly. On later games, Andy Gavin actually extended GOOL to generate machine code, and Naughty Dog actually had some of the rendering pipeline written in lisp.
At ITA, we used lisp primarily because that's what Carl de Marcken wanted to use; he wrote most of the lisp code in the beginning. That codebase wasn't really functional-programming style either; it was like C or Pascal written with lots of parentheses and a layer of lisp macros. There again, my own work was mainly on the seat availability system, which was a C++ in-memory NoSQL database tailored to the domain.
At the end of the day, lisp was both an advantage and disadvantage for both companies. The advantages were everything you'd expect: expressiveness, ability to create DSLs easily, and programmer productivity. The main disadvantage was that nobody coming in off the street ever knew lisp or why we were using it. After Andy and I were gone, Naughty Dog's developers rebelled against lisp, and the current games aren't written using GOOL or its derivatives.
For the new startup, inky.com, a primary goal was being able to readily hire people who already knew the tools. So we're using Python, and we get many similar advantages from it as we did from lisp, though not the macros (which I miss).
Dear Dave Baggett,
Thank you for these interesting details! I did once read an article about Naughty Dog (I assume you meant GOAL - or was there another system called GOOL?) but ITA remains shrouded in secrecy.
I should probably explain that the reason for my surprise at your Lisp-less lecture was that I had only ever previously heard your name in the context of famous businessmen who were not afraid to take advantage of Lisp. Most decision-makers shy away from tools which excessively empower those whom they hire, for reasons which are not difficult to understand.
Yours,
-Stanislav
I was in the Ph.D. program at the MIT AI Lab -- of course I wasn't afraid to use lisp.
But the idea that there's a conspiracy on the part of businesspeople to prevent their employees from using the best tools available -- simply to preserve the ability to arbitrarily replace those employees -- seems pretty absurd to me.
Dear Dave Baggett,
Consider Mark Tarver's observation in his infamous "The Bipolar Lisp Programmer":
"The phrase 'throw-away design' is absolutely made for the BBM and it comes from the Lisp community. Lisp allows you to just chuck things off so easily, and it is easy to take this for granted. I saw this 10 years ago when looking for a GUI to my Lisp (Garnet had just gone West then). No problem, there were 9 different offerings. The trouble was that none of the 9 were properly documented and none were bug free. Basically each person had implemented his own solution and it worked for him so that was fine. This is a BBM attitude; it works for me and I understand it. It is also the product of not needing or wanting anybody else's help to do something. Now in contrast, the C/C++ approach is quite different. It's so damn hard to do anything with tweezers and glue that anything significant you do will be a real achievement. You want to document it. Also you're liable to need help in any C project of significant size; so you're liable to be social and work with others. You need to, just to get somewhere. And all that, from the point of view of an employer, is attractive. Ten people who communicate, document things properly and work together are preferable to one BBM hacking Lisp who can only be replaced by another BBM (if you can find one) in the not unlikely event that he will, at some time, go down without being rebootable."
All of modern industry rests on making labourers fungible. No conspiracies required, just businessmen doing things which make perfect sense from a business standpoint. And my hypothesis is far from absurd: it is in fact the only possible explanation for an atrocity like Java.
But I would also like to point out that the labourers themselves deserve a hefty share of the blame for the dominance of inferior tools. Most programming work would be rendered entirely unnecessary if the right tools were in wide circulation (for example, just about the entire computer security industry would vanish like a bad dream if type-tagging and bounds-checking were used in modern CPUs, like they were in the MIT Lisp Machine...) and so programmers themselves become psychologically-attached to the buggy systems which put bread on their tables through never-ending and barely-remediable dysfunction.
Yours,
-Stanislav
I can point out examples which might say otherwise, at least for more menial tasks. Though it's more for having control over those employees than replacing them.