7 ms·

I just spent months working on a large piece of software and could say without a doubt, Lisp is awesome! But I also want to say that most implementations are ha

by u89012 4y ago

I just spent months working on a large piece of software and could say without a doubt, Lisp is awesome! But I also want to say that most implementations are hashing out a spec written decades ago and not trying to improve what's obviously lacking -- a full modern standard library! Trying to piece together functionality from here and there (and Quicklisp which is an unversioned mess) will only take you so far and in the end you will realize the amount of time wasted chasing this great language! AFAIK Lisp needs more backing from the heavyweights to make any reasonable progress which I'm sure won't happen.

mark_l_watson 4y ago
Good comments. Quicklisp has certainly helped. A few years ago, after Common Lisp being my favorite language since around 1982, I thought that I might switch for my personal projects to Racket Scheme since it does have good library support. What holds me back is that I have found plentiful work opportunities over the last several decades with Common Lisp, but except for getting paid by Springer-Verlag to write a Scheme book, I have never been paid to use Scheme. Also, to be really honest, so much of my work in the last ten years has involved deep learning, that I have somewhat reluctantly learned to love Python for writing short programs.
can3p 4y ago
I think every programmer that tries common lisp eventually comes to the same conclusion, however none of the new versions of "standard" libraries got any traction to my knowledge. Usually it's used only by the author who created it which makes their code unique in some sense, like a recent post from Ron Garret [0]. The spec is really valued by cl community and I guess I'll tell an unpopular opinion now, but I think there could be a place for an ecosystem built around one of the compilers like sbcl with all the old cruft removed and a really good all purpose standard library (similar in capabilities to the one of go for example). What that will achieve is that it will allow new developers to write the code without reading on why the things were designed is a certain way 40 years ago because of now forgotten os or hardware limitation. Similar to what was done with neovim project [0]: http://blog.rongarret.info/2023/01/lisping-at-jpl-revisited.html http://blog.rongarret.info/2023/01/lisping-at-jpl-revisited....
- lispegistus 4y ago
  What part of Common Lisp would you consider old cruft and what value would removing it bring to the language that would offset the value we have from having one of the most stable language definitions still in use? I can think of a few dusty parts of the language that are rarely used today but it's perfectly safe to ignore. Lisp has a good all purpose library ecosystem, it's just informal rather than baked into the language, and I haven't had any significant issues with quicklisp since it came out however many years ago. Writing portable common lisp is not at all difficult and there is no problem like with say Scheme of one library needing a specific compiler. And libraries tend to have a long shelf-life too. How much of Python's standard library is old cruft with better alternative packages available now for example? Didn't they have to prune a bunch of stuff in the python2->3 transition? There is considerable risk in including standard libraries in a standard, and the risk is that those libraries will end up being outdated eventually. You want to add more potential for more old cruft to be in Lisp and then pruned again? Why? Just use quicklisp or one of it's alternatives that are cropping up. Lisp is not Go, it's an agreement between many different parties about what lisp is, it's not a codebase under the defacto control of one organization, or even an informal group or "community". This is extremely valuable and recent events around Go show why, I am extremely glad that I never payed much attention to Go because honestly I cannot trust it's governance model, but a specification that hasn't been and won't be updated in decades I can trust completely, and if one implementation betrays that trust, I can always move to one of the many alternatives listed in the OP. sidenote: > I think every programmer that tries common lisp eventually comes to the same conclusion if this refers to "Lisp needs more backing from the heavyweights", then OH GODS PLEASE NOOO! I want to write code that will run in a year without modification and won't have some corporation put spyware in my compiler while trying to convince me it's for my own good and have my IDE slurp my code to train some LLM to make it easier to pile even more pointless unmaintainable code upon the world. The "heavyweights" have shown themselves very poor stewards of the discipline of computing indeed.
  - SiVal 4y ago
    recent events around Go show why, I am extremely glad that I never payed much attention to Go... What are you referring to? This is a literal question, not advocacy. I haven't been paying enough attention to know what you mean.
galdor 4y ago
But no one is stopping you from building a "full modern standard library". I am doing just that with https://github.com/galdor/tungsten https://github.com/galdor/tungsten. Of course it would be nice to have a large company do all the work as it is the case for Go, but it is not going to happen. As always, you either do the work yourself or pay someone to do it. The specification is limited, no doubt about that, but I am convinced that any modernization effort would end up in a huge mess with everyone trying to inject their own preferences from the languages they already know with no regard for the spirit of the original specification.
vindarel 4y ago
I quite agree, so I'm making a meta-library to have useful libraries available out of the box: https://github.com/ciel-lang/CIEL/ https://github.com/ciel-lang/CIEL/ It's CL, batteries included. You can use it as a library, as a core CL image (loads up faster), and as a binary to have a REPL, and to run scripts: ciel --script myscript.lisp (edit) or just ./myscript with a #!/usr/bin/env ciel shebang. where you have access to HTTP clients, JSON parsers, CSV readers, DB drivers… and much more, out of the box. It is not done, I am dogfooding it.
- cellularmitosis 4y ago
  I’ve noticed many lisps and schemes are not set up to simply accept a single file name as the sole command line argument, which is something common to nearly every other platform. Seems like an easy target for reducing friction for newcomers.
  - vindarel 4y ago
    Thanks for the feedback. I'll look into it, it's early enough to change. (edit) forgot to mention we can simply call ./myscript with the right shebang line. Gets as succinct as one can.
- ducktective 4y ago
  Excellent. It's kinda like Janet, right (in terms of being a battery-included LISP)?
  - vindarel 4y ago
    Yes, and kinda like Babashka for Clojure, in terms of fast starting scripting environment with one binary and useful built-in utilities.
    - ducktective 4y ago
      You are very active in CL community, vindarel. Thanks!
oblio 4y ago
> and Quicklisp which is an unversioned mess Quicklisp is the Common Lisp package manager from what I remember. It doesn't version its packages?
- tmtvl 4y ago
  Not really, but there are ways around it: http://blog.quicklisp.org/2011/08/going-back-in-dist-time.html http://blog.quicklisp.org/2011/08/going-back-in-dist-time.ht...
  - oblio 4y ago
    I'm confused, is this about Quicklisp itself or about the packages it manages? I.e. quicklisp 1.1 versus quicklisp 1.0 or libfoo 1.1 vs libfoo 1.0?
    - tmtvl 4y ago
      It's about the packages, a Quicklisp dist has a list of packages of specific versions (like libfoo 1.1, libbar 1.0, and libbaz 1.2) and you can switch to an older dist (which can have libfoo 1.0, no libbar, and libbaz 1.2).
      - oblio 4y ago
        Oh, so it's actually a carefully curated limited list? Because otherwise the combinatorial explosion would make this unmanageable super fast.

by u89012 4y ago

mark_l_watson 4y ago

Good comments. Quicklisp has certainly helped. A few years ago, after Common Lisp being my favorite language since around 1982, I thought that I might switch for my personal projects to Racket Scheme since it does have good library support. What holds me back is that I have found plentiful work opportunities over the last several decades with Common Lisp, but except for getting paid by Springer-Verlag to write a Scheme book, I have never been paid to use Scheme. Also, to be really honest, so much of my work in the last ten years has involved deep learning, that I have somewhat reluctantly learned to love Python for writing short programs.

can3p 4y ago

I think every programmer that tries common lisp eventually comes to the same conclusion, however none of the new versions of "standard" libraries got any traction to my knowledge. Usually it's used only by the author who created it which makes their code unique in some sense, like a recent post from Ron Garret [0]. The spec is really valued by cl community and I guess I'll tell an unpopular opinion now, but I think there could be a place for an ecosystem built around one of the compilers like sbcl with all the old cruft removed and a really good all purpose standard library (similar in capabilities to the one of go for example). What that will achieve is that it will allow new developers to write the code without reading on why the things were designed is a certain way 40 years ago because of now forgotten os or hardware limitation. Similar to what was done with neovim project [0]: http://blog.rongarret.info/2023/01/lisping-at-jpl-revisited.html http://blog.rongarret.info/2023/01/lisping-at-jpl-revisited....

lispegistus 4y ago
What part of Common Lisp would you consider old cruft and what value would removing it bring to the language that would offset the value we have from having one of the most stable language definitions still in use? I can think of a few dusty parts of the language that are rarely used today but it's perfectly safe to ignore. Lisp has a good all purpose library ecosystem, it's just informal rather than baked into the language, and I haven't had any significant issues with quicklisp since it came out however many years ago. Writing portable common lisp is not at all difficult and there is no problem like with say Scheme of one library needing a specific compiler. And libraries tend to have a long shelf-life too. How much of Python's standard library is old cruft with better alternative packages available now for example? Didn't they have to prune a bunch of stuff in the python2->3 transition? There is considerable risk in including standard libraries in a standard, and the risk is that those libraries will end up being outdated eventually. You want to add more potential for more old cruft to be in Lisp and then pruned again? Why? Just use quicklisp or one of it's alternatives that are cropping up. Lisp is not Go, it's an agreement between many different parties about what lisp is, it's not a codebase under the defacto control of one organization, or even an informal group or "community". This is extremely valuable and recent events around Go show why, I am extremely glad that I never payed much attention to Go because honestly I cannot trust it's governance model, but a specification that hasn't been and won't be updated in decades I can trust completely, and if one implementation betrays that trust, I can always move to one of the many alternatives listed in the OP. sidenote: > I think every programmer that tries common lisp eventually comes to the same conclusion if this refers to "Lisp needs more backing from the heavyweights", then OH GODS PLEASE NOOO! I want to write code that will run in a year without modification and won't have some corporation put spyware in my compiler while trying to convince me it's for my own good and have my IDE slurp my code to train some LLM to make it easier to pile even more pointless unmaintainable code upon the world. The "heavyweights" have shown themselves very poor stewards of the discipline of computing indeed.
- SiVal 4y ago
  recent events around Go show why, I am extremely glad that I never payed much attention to Go... What are you referring to? This is a literal question, not advocacy. I haven't been paying enough attention to know what you mean.

galdor 4y ago

But no one is stopping you from building a "full modern standard library". I am doing just that with https://github.com/galdor/tungsten https://github.com/galdor/tungsten. Of course it would be nice to have a large company do all the work as it is the case for Go, but it is not going to happen. As always, you either do the work yourself or pay someone to do it. The specification is limited, no doubt about that, but I am convinced that any modernization effort would end up in a huge mess with everyone trying to inject their own preferences from the languages they already know with no regard for the spirit of the original specification.

vindarel 4y ago

I quite agree, so I'm making a meta-library to have useful libraries available out of the box: https://github.com/ciel-lang/CIEL/ https://github.com/ciel-lang/CIEL/ It's CL, batteries included. You can use it as a library, as a core CL image (loads up faster), and as a binary to have a REPL, and to run scripts: ciel --script myscript.lisp (edit) or just ./myscript with a #!/usr/bin/env ciel shebang. where you have access to HTTP clients, JSON parsers, CSV readers, DB drivers… and much more, out of the box. It is not done, I am dogfooding it.

cellularmitosis 4y ago
I’ve noticed many lisps and schemes are not set up to simply accept a single file name as the sole command line argument, which is something common to nearly every other platform. Seems like an easy target for reducing friction for newcomers.
- vindarel 4y ago
  Thanks for the feedback. I'll look into it, it's early enough to change. (edit) forgot to mention we can simply call ./myscript with the right shebang line. Gets as succinct as one can.
ducktective 4y ago
Excellent. It's kinda like Janet, right (in terms of being a battery-included LISP)?
- vindarel 4y ago
  Yes, and kinda like Babashka for Clojure, in terms of fast starting scripting environment with one binary and useful built-in utilities.
  - ducktective 4y ago
    You are very active in CL community, vindarel. Thanks!

oblio 4y ago

> and Quicklisp which is an unversioned mess Quicklisp is the Common Lisp package manager from what I remember. It doesn't version its packages?

tmtvl 4y ago
Not really, but there are ways around it: http://blog.quicklisp.org/2011/08/going-back-in-dist-time.html http://blog.quicklisp.org/2011/08/going-back-in-dist-time.ht...
- oblio 4y ago
  I'm confused, is this about Quicklisp itself or about the packages it manages? I.e. quicklisp 1.1 versus quicklisp 1.0 or libfoo 1.1 vs libfoo 1.0?
  - tmtvl 4y ago
    It's about the packages, a Quicklisp dist has a list of packages of specific versions (like libfoo 1.1, libbar 1.0, and libbaz 1.2) and you can switch to an older dist (which can have libfoo 1.0, no libbar, and libbaz 1.2).
    - oblio 4y ago
      Oh, so it's actually a carefully curated limited list? Because otherwise the combinatorial explosion would make this unmanageable super fast.