Posted: Mar 15, 2012 7:54 pm
VazScep wrote:Well, that's a huge can-of-worms right there. I've heard that the popular theory for why it almost died out completely in the early 90s was because it was so heavily tied to AI and the Lisp machine, both of which went under because of the "AI winter". I think the more interesting question is why Lisp came back to life in the 2000s.
Right.
VazScep wrote:I'm not sure what it would mean to have a "fatal flaw" other than a flaw which leads it to die out. And I'm not sure that's the right way to look at things. I mean, I think Java and Python are full of flaws, but it doesn't seem to affect their popularity.
Yeah that came out badly. What I meant was, in more broad terms, what kind of mistake was made so that it would start losing popularity. My own experience in the matter seem to be that they are not making it look interesting to CS students, as it happened to me, but that could be very biased. But the fact is, none of my peers became interested even slightly in LISP.
But why is that? Bad PR? is LISP specially hard to teach to the inexperienced?
VazScep wrote:1) Refactoring tools. I want to be able to intelligently replace identifiers, add arguments to functions, fix name-clashes, import new functions, automatically add deriving clauses and so on and so on, with a few keystrokes or mouse presses.
2) The ability to develop entire systems at the toplevel and save a runtime image (as it is, even my interpreter bindings are erased when I reload a file).
3) A rich reflection API, with all types, kinds, modules, declarations and docstrings available as runtime objects, including cross-references to source files. This is the real enabler. It makes things such as Common Lisp's/Clojure's SLIME mode possible, it allows for intelligent autocompletion without having to continually parse code and generate TAGS files. It also means you can autocomplete definitions entered at the toplevel, as with SLIME. And it means that programmers can easily write their own developer tools.
4) The ability to query the type inferencer to ask what the type of an expression is in a partially written function definition. Visual Studio does this brilliantly for single identifiers with F# and it's a massive help to me. Poly/ML in JEdit does it for arbitrary expressions.
Yeah, those would be nice, but how for example 3) fit with compiler implementations of Haskell? Besides there being no standardization for many of the needed things, it seems it would tie the hands of the optimizer even more.
I gather that all of those except number 3 could be done without a new Haskell standard.