John McCarthy, Discoverer of Lisp, Has Passed Away 354
The first of a few submitters, szo sent in an early
report that John McCarthy passed
early yesterday. Paul Graham
(among others) confirmed: the news
was true. And so, shortly after a fellow
founder of countless language descendants, goes the founder of the Lisp
tree at the age of 84.
Re:Discoverer or Lisp? (Score:5, Interesting)
I think you mean creator or inventor. It's not like the Lisp programming language was just sat out in the wilds of Chile under a rock waiting to be found by an archaeologist.
He was an old time computer scientist, publications with titles like "A basis for a mathematical theory of computation". Hard core math.
Philosophically, you don't "create" or "invent" math you discover it. Logical concepts exist independent of who wrote a paper about them first. Take two 256 bit random prime numbers, multiply them, and you have not "created" or "invented" the result but merely discovered it, or rephrased discovered its two factors.
Re:Discoverer or Lisp? (Score:3, Interesting)
I think you mean creator or inventor. It's not like the Lisp programming language was just sat out in the wilds of Chile under a rock waiting to be found by an archaeologist.
Actually Lisp is just one of the many languages heavily influenced by Lambda calculus [wikipedia.org] which was introduced by Alonzo Church back in the 1930s and 40s. Back then Lamda calculus it was just another system in mathematical logic that only a few mathematicians and logicians knew or cared about. So in a sense John McCarthy did find it under a rock although not in the wilds of Chile but rather in a scientific paper.
Re:RIP and thank you for AI (Score:4, Interesting)
I know zip about other projects, but I was hacking on Maxima for use in my robotics assignments and something is to be said for conciseness of Lisp's way of dealing with data structures. Something more is to be said for macros: the programmatic generation of code (they are nothing like C macros). Of course you can generate code in C, but it's a shitty experience, and you have to roll it all yourself. The C/C++ languages do not come with any sort of a data structure to express themselves. Even Python has an ast module. I've found that programmatic generation of code is a big win in embedded world, especially on small microcontrollers (RAM in single kilobytes, etc). Most platform libraries become quite bloated if you want to truly fully support all peripherals, even if a typical application only uses a small subset of the functionality. The compilers are usually too stupid to properly optimize it, even if a fairly rudimentary constant propagation would indicate that 90% of the library is dead code. With macros you can easily generate just the code you need. Macros can easily and cleanly replace external tools like lexer and parser generators. They are also great for implementing extra language features. You don't need hacks like Duff's device [wikipedia.org] or coroutine horkage [greenend.org.uk]. LISP is powerful enough that you can have features like yield implemented in a library [cliki.net].
In the end, it's all about ease of use. Even though I do a lot in C and C++, I detest their verbosity. I mean, come on, ML family had type inference for three decades! Heck, I have worked with a structured basic running on CP/M Z80 that had rudimentary type inference (although didn't have algebraic types). You didn't have to assign types to your variables, and if you tried adding an integer to a string it would balk -- not at runtime, but before it'd accept the new or modified line of program! Variables were assigned types at first use, and if you had a function returning a value (yes, it had functions, but sadly no tuples), it knew what type it'd be based on the code inside of the function. That was in late 80s! Then you come to C++ and get to experience template metaprogramming -- sure it's powerful, but it feels about as expressive as programming a Turing machine directly. And metaprograms are interpreted by the compiler, in a very inefficient way.