It was used only in the form of Emacs Lisp, as a set of tools for customer service folks to make replying to typical email easier for them. They pretty much built all that themselves (and they didn't start out as programmers).
We worked together with Eric Benson and Dan Bornstein on ScriptX [2], which was basically Lisp with objects instead of parenthesis.
I found ScriptX quite useful for web programming [3]: "Link Globally, Interact Locally"!
ScriptX's legacy lives on: After Kaleida shut down, John Wainwright, the architect of ScriptX, created a very similar language called MaxScript [4] for 3D Studio Max, which I later used at Maxis for programming the character animation content pipeline for The Sims [5].
There was more Lisp influence than just the CS macros you mention here. Eric Benson was a major contributor to Lucid Emacs and many early Amazon engineers had Lisp experience. SICP was practically issued to every new software engineer--it was that popular.
The template language for Amazon's website at the time (catsubst) was a Lisp-inspired prefix notation language with a relatively small number of functions. For example, there was an add macro but not a subtract macro, so to do A-B, you had to say ${add A -B}. I might have the exact syntax wrong since it's been 20 years.
EB and I both worked at Lucid, which produced a Common Lisp system, not to my knowledge a version of Emacs (though maybe so after I left in 1989?). Some other early employees knew and liked Lisp, but we didn't use it on any core functionality. The text substitution logic you mention, that I wrote, was really simple and not particularly Lisp-like. Though again, after I handed it off, who knows what happened.
Lucid Emacs -> Xemacs was mentioned in a sibling comment, but I remember people being in awe about EB working on those. There were many interesting employees back then--J. Chenault, J. Gehlen, R. Braumeller, F. Eiden, K. Sears, etc. I've lost touch with most of them but I learned a lot from them.
I started in October 1997 and did Perl work on backend systems, but I had a few friends who worked on the frontend. They used to talk about how Catsubst had a very small set of verbs and that everything was a function, even arithmetic, and that prefix notation was used for all macro calls. They thought it was Lisp-inspired, but they were also pretty junior programmers too. I never worked with Catsubst myself, so my information is second-hand, while yours is zero-hand since you wrote it. :-)
Thanks for all the work you did on Amazon's infra!
Yes, there was a ton of Perl in the early days. This came about because Paul Davis was a Perl aficionado and did a lot of script writing with it early on, and the non-programmers, of which there were n-2, could pick it up much more easily than C (of course). Which is how some of them became programmers. Incidentally, we used C, not C++, though I liked OOP, because I had previously had less than great experience using C++ on large projects. We used a C++ compiler though because it could catch more errors than the C compiler could. This is one area where Steve Yegge was a bit off in that famous post.
After leaving Lucid I was really not paying much attention to what they were doing. It wasn't long before things started going badly there and they were out of business a few years later. But indeed, I had forgotten what little of the Emacs history I might have known. Here it is: https://www.jwz.org/doc/lemacs.html
But ... in the one case we are aware of, of a whole company, Amazon, using a service oriented architecture, they did it after the fact. The did bolt it on later, or rather, they (according to Steve) ripped everything up and re-did it in this way. I'm sure it was absolute hell to do this, but that is what they apparently did. So it isn't a requirement to build a platform first, then build everything else. It might be nicer to do it that way, if it's the best prioritization of resources at the time, but that's not what happened in the case being discussed.
Hi. Shel Kaphan here. Just to be clear, the negotiation you are referring to was simply over whether it would be stock or employee options. No reason to be sad. Founder's stock is more convenient and less of a taxation nightmare, but there was a concern (an irrational one, I think) about what would happen if I left early. There are of course ways, such as escrow, to handle that.
As for whether or not I'm a nice amiable guy, Chris (below) is probably right -- a lot of people including him got to experience the joys of my temper while I was trying to do what isn't possible: to contain the chaos ;^\
It's definitely a little odd. In one way it is just a matter of semantics: what exactly does the word "founder" really denote? But some may be asking whether I personally was all that important in the company's history. I can't judge that. All I know for sure is that I put my heart and soul into it especially during the first half of my time there, and I still feel a strong connection to the place (despite having left almost 12 years ago) even when they really get me angry, like with this sales tax thing. I'd prefer not to have to have a personal reaction to things like that, but there you are. As is pointed out elsewhere, Bezos was the only one who was really making strategic decisions, and it's probably still that way for all I know, though I participated in some. The idea to do a bookstore was his, though we were not the first on the web to do that. That doesn't mean I (and other early "participants") didn't have our own visions of where things ought to go too. When you do the engineering, hacking, and tech operations side of a startup, going from nothing to something, it's like it grows out of you and it feels like an extension of you. That's a different relationship from being the person with the idea who does the fund-raising and makes the big decisions. You need to have both.
At one point I'd say the company's "DNA" probably was influenced by me to an extent, but I've been gone for a long time, and it was tiny compared to its current size when I left, so it would be pretty surprising if any of that is still there. That's fine with me -- that's just how things work.
At the risk of mentioning something I did myself, here is a simple, STM implementation in C: http://github.com/skaphan/stmmap . It's at a very different design point from others like Clojure's in that it is just a simple API, not a language mechanism, it is for concurrency at the process level, not threads, adds no extra "goo" between the program and its data, but has a fairly coarse grain size for conflict detection (page size). Who knows, it might be appropriate for some situations...
