3 ms·

> over time lisp would change to become more like PhP. 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

> over time lisp would change to become more like PhP. 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.

kahrkunne 10y ago
You're putting words in my mouth. I never said PHP was bad - it's reasonably good for common use cases on the web. 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).
- Annatar 10y ago
  I'm just saying that if hypothetically lisp became super popular, it would inevitably change to fit the work flow of the mainstream. 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! (:-))
- Nekorosu 10y ago
  Sorry. I've reread my answer. It was kinda offensive. 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.
kazinator 10y ago
> It has very basic and clear core which doesn't need to be fixed If that core doesn't evaluate (car nil) -> nil, it's broken to me.
- kahrkunne 10y ago
  (car nil) -> nil doesn't seem obvious to me. It implies that (equal nil (cons nil nil)) i.e. (equal nil '(nil)). 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.
  - kruhft 10y ago
    Unlike NULL (a void* of value 0), nil is an interesting construct in that it's a special cons cell, an element of two pointers, where each cell points to itself. Or that's one way to think of it.

kahrkunne 10y ago

You're putting words in my mouth. I never said PHP was bad - it's reasonably good for common use cases on the web. 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).

Annatar 10y ago
I'm just saying that if hypothetically lisp became super popular, it would inevitably change to fit the work flow of the mainstream. 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! (:-))
Nekorosu 10y ago
Sorry. I've reread my answer. It was kinda offensive. 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.

kazinator 10y ago

> It has very basic and clear core which doesn't need to be fixed If that core doesn't evaluate (car nil) -> nil, it's broken to me.

kahrkunne 10y ago
(car nil) -> nil doesn't seem obvious to me. It implies that (equal nil (cons nil nil)) i.e. (equal nil '(nil)). 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.
- kruhft 10y ago
  Unlike NULL (a void* of value 0), nil is an interesting construct in that it's a special cons cell, an element of two pointers, where each cell points to itself. Or that's one way to think of it.