6 ms·

Common Lisp folks should really start designing a more modern version of CL. I'm pretty sure some old Lispers would come and say, 'Common Lisp's stability is a

Common Lisp folks should really start designing a more modern version of CL. I'm pretty sure some old Lispers would come and say, 'Common Lisp's stability is a great feature', 'There are lots of new dialects', and while they are right in some aspects, Common Lisp isn't appealing to anyone these days. (I mean, even C and C++ is improving. Why shouldn't CL?) Even for people who 'get' the ideas of s-exps and macros, there are too many quirks in CL to appeal to people, and most go to Clojure (where the interactive experience is at best moderate, debbuging support/error handling is a mess, e.g.). I believe the hypothetical CL++ should at least: * Straight out incompatibilites between implementations, especially the numerous opinions to make an image or binary, and the FFI parts. * Design a better CLOS system. CLOS feels like an object system thought after (well, after all it is a system thought after) and bolted on CL with duct tape. I would appreciate a CLOS-based type system (based on macros much like CLOS) that integrates well with CL. * Remove unused functions, and fixing some inconsisties in the standard library * Bigger, much much bigger standard library. Crucial, community-standard libraries like asdf & uiop, syntax-sugar like the arrow/diamond macros, and reader macros that allow infix syntax (this currently exists in the standard but nobody uses it partly because most Lisp users don't really care about infix, partly because it's extensiblity is bad) should be in the std. * A compatibility layer. Providing a 'cl' and 'cl-user' package with the usual CL symbols will be sufficient. to appeal to the users. This really isn't sufficient for the hypothetical CL++ itself; there really should be beginner materials that isn't PCL; Lispers shouldn't hate infix reader macros or syntax-sugar like LOOP(IMHO these show the real power of macros, after all, macros are another tool to write readable code with great abstractions) and beginner materials should use, or at least introduce them(infix reader macros and other syntax sugar). Just a rant about the language after reading the post and becoming sad.

nudpiedo 7y ago
Don't forget a package installer/dependency manager as in NPM/PIP/CPAN. Nowadays I cannot look to a programming language without one of those... it is just too painful to look for libraries, download them, set in a separate folder, etc...
- rjsw 7y ago
  There is quicklisp [1], works fine for me. [1] https://www.quicklisp.org/beta/ https://www.quicklisp.org/beta/
  - nudpiedo 7y ago
    I thought that it's not official and that it was largely criticized due the lack of test cases, and other problems.
    - varjag 7y ago
      It's fine and you'd know that if you ever used it. I guess there are some metrics by which you could criticise it, but not if NPM or CPAN are your yardsticks.
    - vindarel 7y ago
      Quicklisp is great (and better than npm/pip) because it works with distributions, aka releases. It's more stable, I never had dependencies of dependencies that break because they were not pinned carefully. Upgrade when you want. If you want to do otherwise, see Qlot and Ultralisp (a distribution that builds every 5 minutes).
stassats 7y ago
I don't want to ruin the language just so that it appeals to some people, it's already fine for me.
- pcr910303 7y ago
  > ruin the language just so that it appeals to some people May I ask why this can be considered ‘ruin’ing? These sort of changes will be useful for all CL users IMO. > it's already fine for me Maybe to you, but not for me or many, many people who went to Clojure apparently.
  - a0-prw 7y ago
    I don't mean this in a hostile way, but seriously, just go, then. If Clojure is best for you, vaya con dios :)
    - pcr910303 7y ago
      Okay, maybe I should clarify. I’m not a Clojure-lover; I use CL as my side project language and I love CL. I was just suggesting a way that CL can be more appealing language so that CL can reach more adoption (as CL has it’s strengths that Clojure can’t follow along).
      - zeveb 7y ago
        Speaking as another Lisper, I am glad that you're sticking with Lisp, not moving to Clojure. … and maybe someday you can propose your own project, something like CL21!
- oblio 7y ago
  > I don't want to ruin the language just so that it appeals to some people, it's already fine for me. To an outsider his comments seem pretty reasonable. Why would they ruin Common Lisp?
  - varjag 7y ago
taeric 7y ago
I have doubts. In particular, from my vantage, what common lisp lacked was a heavy sponsor from the big players in industry. Or academia, even. What it has, is a ton of people that are more than willing to voice what they don't like about it. Which most languages have. Just doesn't have folks also posting good blogs about it often.
- pcr910303 7y ago
  > what common lisp lacked was a heavy sponsor from the big players in industry. Or academia, even. I believe CL can thrive even without sponsors, most of the new languages in the town don’t have sponsors. (Like Julia, Nim, Ruby, e.g.) > a ton of people that are more than willing to voice what they don't like about it. The CL community can ignore people that just whine about the ((parens)). What the CL community shouldn’t is constructive criticism from itself. (For the record, I use CL as my side-project language, and use Clojure as my main language.) > Just doesn't have folks also posting good blogs about it often. IMHO, the CL community is too small to have much. The percentage of people who blog about CL is quite high; but the denominator is too small.
  - taeric 7y ago
    My doubts were meant as specifically against your points. CLOS is often lauded as one of the best object systems. To see it as one of the complaints feels odd. Cruft in the standard library? Examples would be good here. But, this is hard to get behind. Nobody would be really sad to see Java date leave. That said, many of us are happy we don't have to touch some code that is working fine with it. And this is next to a demand for a bigger standard library. Which will only lead to more cruft. Not sure what you mean about the compatibility layer. Care to expand? My point was if CL had the press of any of the alternatives to gave, that would put weigh the negatives you gave. Instead of chasing removal of stuff, marketing would make more of a difference.
    - rauhl 7y ago
      > CLOS is often lauded as one of the best object systems. To see it as one of the complaints feels odd. CLOS is awesome, better than the rest. But there are some weird seems between types and classes. And in places CLOS doesn’t go far enough — e.g. it’d be nice to specialise methods based on element types.
rauhl 7y ago
I absolutely love developing in Common Lisp, and I agree with you. Some suggestions: - Get rid of upcasing; 21st-century languages should be case-sensitive and case-preserving. Allegro’s modern mode is the Right Thing™ here IMHO. - Fix things like order-of-argument inconsistencies in the standard library. - Consider adding type to streams to indicate whether they are input, output or both and character, byte or both. - Base the package system off of Go’s. - More fully specify pathnames. - Specify a standard library roughly equivalent to Go’s. At this point I think it’s the gold standard (Python’s used to be, but no longer).
- vindarel 7y ago
  On upcasing: (setf *print-case* :downcase)
  - rauhl 7y ago
    Oh definitely — that is a must! But it doesn’t do you any good if e.g. you want to turn read symbols into shell commands. You can play some games with :invert, but at the end of the day it’s a hack. I don’t blame them for upcasing back in the 90s, but … it’s not the 90s anymore.
  - rurban 7y ago
    Not downcase, modern. I.e case-preserving and case-sensitive. E.g. to be able to define native ffi calls into CamelCase functions. Downcasing is destroying information, Modern is keeping the original symbol names
vindarel 7y ago
Some bits are here: - https://github.com/alex-gutev/generic-cl/ https://github.com/alex-gutev/generic-cl/ gives generic equality, predicates and other base functions. - the https://lispcookbook.github.io/cl-cookbook/ https://lispcookbook.github.io/cl-cookbook/ has nice topics and is growing. - there is also http://cl21.org/ http://cl21.org/, which works©, but is staling. - to make an image, I think asdf:make is all one needs (see the Cookbook). - Coalton is bring ML-types on top of CL. - … and I love CLOS. > there are too many quirks in CL to appeal to people I saw quirks at first. What was part of the learning process, I do wonder. Last, there are many things we cannot do in Julia, like the Next browser :) https://github.com/next-browser/next https://github.com/next-browser/next

nudpiedo 7y ago

Don't forget a package installer/dependency manager as in NPM/PIP/CPAN. Nowadays I cannot look to a programming language without one of those... it is just too painful to look for libraries, download them, set in a separate folder, etc...

rjsw 7y ago
There is quicklisp [1], works fine for me. [1] https://www.quicklisp.org/beta/ https://www.quicklisp.org/beta/
- nudpiedo 7y ago
  I thought that it's not official and that it was largely criticized due the lack of test cases, and other problems.
  - varjag 7y ago
    It's fine and you'd know that if you ever used it. I guess there are some metrics by which you could criticise it, but not if NPM or CPAN are your yardsticks.
  - vindarel 7y ago
    Quicklisp is great (and better than npm/pip) because it works with distributions, aka releases. It's more stable, I never had dependencies of dependencies that break because they were not pinned carefully. Upgrade when you want. If you want to do otherwise, see Qlot and Ultralisp (a distribution that builds every 5 minutes).

stassats 7y ago

I don't want to ruin the language just so that it appeals to some people, it's already fine for me.

pcr910303 7y ago
> ruin the language just so that it appeals to some people May I ask why this can be considered ‘ruin’ing? These sort of changes will be useful for all CL users IMO. > it's already fine for me Maybe to you, but not for me or many, many people who went to Clojure apparently.
- a0-prw 7y ago
  I don't mean this in a hostile way, but seriously, just go, then. If Clojure is best for you, vaya con dios :)
  - pcr910303 7y ago
    Okay, maybe I should clarify. I’m not a Clojure-lover; I use CL as my side project language and I love CL. I was just suggesting a way that CL can be more appealing language so that CL can reach more adoption (as CL has it’s strengths that Clojure can’t follow along).
    - zeveb 7y ago
      Speaking as another Lisper, I am glad that you're sticking with Lisp, not moving to Clojure. … and maybe someday you can propose your own project, something like CL21!
oblio 7y ago
> I don't want to ruin the language just so that it appeals to some people, it's already fine for me. To an outsider his comments seem pretty reasonable. Why would they ruin Common Lisp?
- varjag 7y ago

taeric 7y ago

I have doubts. In particular, from my vantage, what common lisp lacked was a heavy sponsor from the big players in industry. Or academia, even. What it has, is a ton of people that are more than willing to voice what they don't like about it. Which most languages have. Just doesn't have folks also posting good blogs about it often.

pcr910303 7y ago
> what common lisp lacked was a heavy sponsor from the big players in industry. Or academia, even. I believe CL can thrive even without sponsors, most of the new languages in the town don’t have sponsors. (Like Julia, Nim, Ruby, e.g.) > a ton of people that are more than willing to voice what they don't like about it. The CL community can ignore people that just whine about the ((parens)). What the CL community shouldn’t is constructive criticism from itself. (For the record, I use CL as my side-project language, and use Clojure as my main language.) > Just doesn't have folks also posting good blogs about it often. IMHO, the CL community is too small to have much. The percentage of people who blog about CL is quite high; but the denominator is too small.
- taeric 7y ago
  My doubts were meant as specifically against your points. CLOS is often lauded as one of the best object systems. To see it as one of the complaints feels odd. Cruft in the standard library? Examples would be good here. But, this is hard to get behind. Nobody would be really sad to see Java date leave. That said, many of us are happy we don't have to touch some code that is working fine with it. And this is next to a demand for a bigger standard library. Which will only lead to more cruft. Not sure what you mean about the compatibility layer. Care to expand? My point was if CL had the press of any of the alternatives to gave, that would put weigh the negatives you gave. Instead of chasing removal of stuff, marketing would make more of a difference.
  - rauhl 7y ago
    > CLOS is often lauded as one of the best object systems. To see it as one of the complaints feels odd. CLOS is awesome, better than the rest. But there are some weird seems between types and classes. And in places CLOS doesn’t go far enough — e.g. it’d be nice to specialise methods based on element types.

rauhl 7y ago

I absolutely love developing in Common Lisp, and I agree with you. Some suggestions: - Get rid of upcasing; 21st-century languages should be case-sensitive and case-preserving. Allegro’s modern mode is the Right Thing™ here IMHO. - Fix things like order-of-argument inconsistencies in the standard library. - Consider adding type to streams to indicate whether they are input, output or both and character, byte or both. - Base the package system off of Go’s. - More fully specify pathnames. - Specify a standard library roughly equivalent to Go’s. At this point I think it’s the gold standard (Python’s used to be, but no longer).

vindarel 7y ago
On upcasing: (setf *print-case* :downcase)
- rauhl 7y ago
  Oh definitely — that is a must! But it doesn’t do you any good if e.g. you want to turn read symbols into shell commands. You can play some games with :invert, but at the end of the day it’s a hack. I don’t blame them for upcasing back in the 90s, but … it’s not the 90s anymore.
- rurban 7y ago
  Not downcase, modern. I.e case-preserving and case-sensitive. E.g. to be able to define native ffi calls into CamelCase functions. Downcasing is destroying information, Modern is keeping the original symbol names

vindarel 7y ago

Some bits are here: - https://github.com/alex-gutev/generic-cl/ https://github.com/alex-gutev/generic-cl/ gives generic equality, predicates and other base functions. - the https://lispcookbook.github.io/cl-cookbook/ https://lispcookbook.github.io/cl-cookbook/ has nice topics and is growing. - there is also http://cl21.org/ http://cl21.org/, which works©, but is staling. - to make an image, I think asdf:make is all one needs (see the Cookbook). - Coalton is bring ML-types on top of CL. - … and I love CLOS. > there are too many quirks in CL to appeal to people I saw quirks at first. What was part of the learning process, I do wonder. Last, there are many things we cannot do in Julia, like the Next browser :) https://github.com/next-browser/next https://github.com/next-browser/next