Not exactly what I had in mind...
I would NOT write any of the applications I support in LISP, it makes no sense.
That is your prerogative; however, LISP is not just a historical footnote or a dead language. Lisp has an extremely successful track record in just about every domain of computing: everything from web companies (Yahoo store) to games (Dexter and Jak) to robotics (iRobot) to operating systems and even hardware has been done in Lisp.
There are lots of things that LISP just shouldn't be used for, even if it can do it. (Webservices anybody?)
Actually, many of the travel sites use a web service provided in... yep, Lisp. There are quite a few Lisp libraries for developing web apps, connecting to databases, etc. Paul Graham, Robert Morris and a 3rd person (the name escapes me at the moment) created what became Yahoo Store by themselves in an attic.
Most of the gods of computing (Dijkstra, Knuth, Kay, Minsky, Norvig and on and on) have all spoken out in favor a single language...
Why shouldn't it be a big deal that a new language has features giving more capabilities?
If a new language did offer "more" capabilities that would be a big deal. However, we both know that in the strict mathematical sense this isn't possible (ie LISP is Turing complete). In the pragmatic programming sense, if someone were to create an interesting new language feature like OOP, it could simply be added using the macro system -- this is how OOP was added to Lisp.
What do you REALLY have against OOP? Your last bit there seems to be really hating on it, which I don't see a reason to.
I have absolutely nothing against OOP. My last comment was critical of "industry". It is "industry" that has made OOP into the latest silver bullet in a long line of silver bullets. In another decade, industry will move on to using AOP to fix all of the problems that OOP supposedly caused (which, of course, isn't true).
Elaborate on this lang x with feature y stuff.... I am curious to where that goes. Why is fewer patterns better?
Part of it is the distinction between design patterns and design strategies (see Norvig's paper here: http://norvig.com/design-patterns/
). Design strategies are generally a good thing. The main criticism of "design patterns" is they provide functionality that is missing from more expressive/powerful languages (see Greenspun's tenth rule). Norvig's example of a subroutine once being a "design pattern" is pretty insightful. Adding functions to a programming language means that you no longer have to push parameters onto the stack, create a return label and jump to and from the subroutine. The "design strategy" is still there; The language has simply eliminated the manual work. Language features like first-class functions, closures, and language abstraction (ie Lisp's macro system), make many of the other design patterns invisible in the same way that a language supporting functions makes the "subroutine pattern" invisible (note: this isn't just something that is limited to Lisp, Smalltalk, Erlang, or Python, my book on Java Reflection gives several examples of how meta-programming simplifies and/or eliminates several of the original gang of four patterns).Interpreter pattern
The interpreter pattern specifies how to evaluate sentences in a language. The basic idea is to have a class for each symbol (terminal or nonterminal) in a specialized computer language. The syntax tree of a sentence in the language is an instance of the composite pattern and is used to evaluate (interpret) the sentence.
The reverse polish notation example given in Java and C# results in the creation of 5 classes, one interface, and approximately two screens of code (plus, keep in mind this is an extremely simple example). In Lisp, this design pattern "disappears" because you don't have to implement all of this machinery to support an embedded language.Strategy pattern
In computer programming, the strategy pattern (also known as the policy pattern) is a particular software design pattern, whereby algorithms can be selected at runtime.
Comparing the Java and Python implementation is quite an eye opener. Not only is the Python implementation a fraction of the length -- It is FAR clearer what the hell is going on.
You seem to favor "old" languages because of how they do t hings, and seem to "pimp" that they are better because they came first. Seems kind of silly actually. Just because it came first doesn't mean it is better.
No. I prefer Java to C++ and C++ to C with classes; however, I prefer C to C++ for lower-level tasks. The only "old" language that I really use is Common Lisp. It just happens to be the case that I can do things in CL that I simply can't do in Java or C++. Of course, just because something comes along decades later doesn't make it better either.