>>20
Yet my Lisp still does type inference, even in the presence of subtypes.
And stop spreading lies! What you want is easy to do e.g.
(declare (type array float (100))). Now if you have declared a high enough optimize speed value and low enough safety value, your compiler will probably emit some very fast code.
The reason this isn't done all the time is because maybe one day I'll have e.g. complex numbers in my array and I don't want to have to change 690 declarations in 69 functions cause of my earlier shorted sightedness, nor should I, nor should any programmer worth his salt.
Unlike languages you might be used to, Common Lisp trusts the programmer. For example there's no way to make symbols (i.e. classes, functions, generic functions, variables, conditions, restarts) truly "private" in a package; You can only mark them as not automatically exported, but the client is free to explicitly import them, or otherwise access them if they wish.
Another example is "advising functions". This refers to, dynamically (as in dynamic scope), "advising" an existing function to execute program text before or after it is called, without modifying the program text where it is called.
So it's not a matter of bad "indian body shop" programmers not declaring types all over the place and wrecking havoc for everyone, rather, it's good Common Lisp programmers that don't declare types unless they have a very good reason to limit what clients of their programs can do with that program.
I know for someone who has not yet experienced the pure bliss of writing large systems in Common Lisp, and who has been so thoroughly sold the "Now now son if I gave you a chain saw to cut that tree, you'd only cut your hands of too" nanny programming mentality, a lot of this sounds like gobbledigook. But it's not. Just try it, otherwise please stop spreading lies about Common Lisp (e.g. Common Lisp is not statically typed or Common Lisp can't do static type checking, or Common Lisp can't optimize my array function. These are lies). It's a dishonest thing to lie.
>>22
Two good examples of "dead" Lisp AIs are Computer Algebra Systems, and proof assistants. They are so dead that I use them all the time.
Another good example is unification and knowledge representation. So dead. Completely useless. Dead. Forgotten. Why would anyone want to do this?
And the (Symbolics) Lisp machine may be out of business, but that doesn't stop it from having existed. That doesn't stop it from still, to this day, being the finest operating system and development environment ever created. Nothing has topped it.