That code is so beatiful: clear, easily understandable. I don't think I've ever seen any C++ code which even comes close to this in readability. And it just flows.
Really, LISP gets way too little credit (and use) than it deserves.
Really, LISP gets way too little credit (and use) than it deserves.
Wanting something like lisp to gain mainstream popularity would be a naive wish - your average web developer wouldn't be able to appreciate it, and over time lisp would change to become more like PhP. No offense meant to such people of course, not everyone needs to have that kind of passion, and someone needs to do web development - God knows it won't be me!
A lot of things are so wrong in this statement.
First of all, PHP isn't bad. Don't get me wrong I don't like it (I also don't like Go but that's another story) but it has become so much better. Several of my colleagues use it (that's not the only language they use though) and believe me they are quite passionate about programming. Actually there is some zen in being able to use any tool life throws at you to solve some practical problems.
Second, you are comparing family of languages to the one particular language. This doesn't do justice to both.
Third, if the comparison with PHP was another way to say that Lisp would become worse then here is another thought. It won't. Every mainstream language I know is becoming better in a sense of better defaults and FP features. Java has got lambdas. JS ES6 is going to have TCO and strict mode which fixes a lot of old vague behaviour. Yes, there are a lot of crazy stuff in those languages because their features weren't well thought out back in the day and now it's impossible to fix everything without breaking the core semantics and behaviour. Basically you can fix some things but you can't evolve one language into another.
Getting back to Lisp now. It doesn't need fixing. It has very basic and clear core which doesn't need to be fixed and a lot of advanced language features can be built upon it (and actually was built and are being built). Taking in account both that languages are becoming better with time and that Lisp has awesome core I don't see at all how's popularity can make it worse.
I'd suggest reading some PLT books or taking some related courses. It helps to get the whole picture. You won't love Lisp less (probably the opposite) but you'll accept other languages more. :)
I have to add I'd prefer something Lispish over anything else any day of the week. I'm looking into Clojure(ClojureScript). It's not as elegant as original Lisps and Schemes but it's tradeoffs come from real world use cases (running on top of JVM and JS). Even with them it's an awesome language.
I'm just saying that if hypothetically lisp became super popular, it would inevitably change to fit the work flow of the mainstream. Maybe not directly (i.e. through the spec changing) but definitely indirectly, through changes in common practice, libraries etcetera, as well as the general culture of relatively CS-literate, experienced hackers surrounding it.
Of course, I'm not worried about this happening - what's happening instead is that lisp features are finding their way into other languages (a process that has been going on since the 70s).
Being a functional language designed for metaprogramming, it is expected that it be extended: just by defining a new function, one defines LISP on the fly. That's the core idea of LISP! (:-))
I don't see anything bad in Lisp becoming good for common use (on the web or wherever else) and I don't agree with your hypothesis. Lisp would just become more diverse in terms of libraries ecosystem and community. It will keep it's spirit and a core of really experienced users.
If that core doesn't evaluate (car nil) -> nil, it's broken to me.
Now I'm not a very experienced lisp programmer, but I don't see why those two would be equivalent. FWIW, at least on SBCL, (car nil) does evaluate to nil.
I would request that you please reconsider this position. It's demonstrably false, because there are great and famous programmers we could think of who have no particular opinion on lisp.
The condescension toward web developers is also not solid ground. There are geniuses and passionate people who take all kinds of different life paths, or don't go to college, or whatever artificial litmus test we think of.
I try to really be careful of personal biases like this during interviews because it's easy for them to creep in. So if I find myself wanting to ask "tell me about lisp", I try to catch it and instead ask directly about what I want to know. For example, "what work have you done that shows your quality as a programmer?", or "can you explain what makes you passionate about code?"
I stand by knowing lisp being a good indicator of programmer quality, but it's pretty one-sided: knowing lisp is a very good indicator that one is a reasonably good programmer, but not knowing lisp isn't really an indicator of anything; the vast, vast majority of people don't know lisp, after all.
College is the same way of course: having been to college is a reasonable indicator of competence (though not as good as knowing lisp inside-out), but not having gone to college is not an indicator of incompetence - yet nobody would doubt that a college as a whole is an indicator of competence, because if they did, college degrees would be worthless - which they aren't.
Regarding correlations, I understand your logic. My point is that correlations, or generalizations about large groups of people usually do more harm than good.
Forget the morality of it; In most real life situations it's simply more productive to use other metrics. For example, some companies use having a college degree as a coursely grained filter, when other approaches can be just as time efficient, and more productive because they don't incorrectly screen out the negatively correlated candidates.
Of course I don't mean general indicators are inherently bad or useless, just that they are often given too much weight against people, especially when better information is available.
It turns out ~99% of violent murders are committed by men. Luckily, most people don't hold this against me personally.
While it is true that PHP suffers from "the neighbor's kid" syndrome and design inconsistencies, PHP programs can be very elegant, fast and simple in the hands of an experienced Greybeard UNIX programmer. I think PHP gets a lot of bad rap, but it doesn't necessarily mean that PHP itself is a priory a bad language. Yes it has had, and still does have its fair share of iconsistencies, but in the right hands it could be programmed just like Bourne shell. Or AWK. Or C... Or LISP! Completely functionally. No objects.
One of the principal reasons why I sympathize with ANSI common LISP is that when I'm done writing it in a REPL, I can compile it into an ELF binary executable, for performance.
Elisp gets undue hate.
>I like CL, but I wouldn't configure my text editor in it.
Why not? As Dynamic Scoping falls out of popularity and the cl packages become increasingly widely used, idiomatic elisp becomes increasingly close to CL, despite RMS's distaste for that language.
re: dynamic scope, I agree that Emacs' future is with lexical-binding for non-special variables. Chris Wellons recently wrote a great post which has shown up on my radar: http://nullprogram.com/blog/2016/12/22/