7 ms·

Tangential question, but what Lisp is the most promising one to invest time on right now? Common Lisp still has some activity, mainly coming from SBCL, but is

by nextos 7y ago

Tangential question, but what Lisp is the most promising one to invest time on right now? Common Lisp still has some activity, mainly coming from SBCL, but is a bit stagnant. It has a fantastic literature and many mature implementations. Scheme is great, but a bit too fragmented. Racket seems to be gaining some momentum. The merge with Chez may be the tipping point to attract a critical mass of developers. Clojure has many interesting modern ideas, but I feel being so tied to Java and the JVM has hurt a bit in the long run. I miss a bit of innovation in the typed lisp area, like e.g. Qi or Shen which never took off. Carp [1] looks nice. [1] https://github.com/carp-lang/Carp https://github.com/carp-lang/Carp

grzm 7y ago
> ”Clojure has many interesting modern ideas, but I feel being so tied to Java and the JVM has hurt a bit in the long run.” Would you expand on this? From my perspective, it actually opens up Clojure to a lot of opportunities where introducing, say, Common Lisp or Racket, would be a much harder lift. Clojure’s just a library, and immediately has available the entire Java ecosystem. Granted, it’s based only on my experience, but I’ve much more frequently seen first-class (provided by a vendor or otherwise officially sanctioned) Java libraries for services and other tooling than Common Lisp or Racket. Being able to take something like that off the shelf for integration is a big plus in my experience.
- fiddlerwoaroof 7y ago
  For Common Lisp, there's ABCL ( https://abcl.org https://abcl.org ) which is a CL on the JVM and, otherwise, LispWorks bundles a nice Java FFI. But, additionally, CL makes binding to C libraries really easy via CFFI and things like cl-autowrap ( https://github.com/rpav/cl-autowrap https://github.com/rpav/cl-autowrap ) so, when there isn't a native lisp library, it's often easy enough to just use a C library in your program (or, I suppose, anything that can compile to something compatible with C like `extern C` in C++ and the equivalent constructs in Rust)
  - slyrus 7y ago
    It would be nice if ABCL's JDK 11 support were brought into the main repo. Speaking of which, it would be nice if the main repo moved away from SVN to, e.g., gitlab. And, while we're at it, the issue tracker could be brought into the new millennium.
    - fiddlerwoaroof 7y ago
      Yeah, I just noticed this: https://mailman.common-lisp.net/pipermail/armedbear-devel/2019-April/003973.html https://mailman.common-lisp.net/pipermail/armedbear-devel/20... so, perhaps it's coming soon?
jpittis 7y ago
It's interesting that there's so much resistance to Clojure given it's modern / being used in production a fair bit. I've had a number of great experiences working on toy projects using Clojure but nevertheless feel resistance to adopt it fully "because of the JVM". I've pinned my own resistance down to three things: - Slow startup times. (Most of my use cases are not long running servers.) - Not "unixy". (I write programs to run on linux and OSX exclusively and am used to using non-portable APIs maybe?) - I've been lead to believe Java is "gross" and "enterprisy". Really, of those three reasons only the first one has merit. It kind of sounds silly when I put it this way: When I'm hacking on fun projects, I enjoy using a "hacker" language and Clojure doesn't feel like one. One implementation you didn't mention that's pretty neat is Chicken Scheme [1]. [1] https://www.call-cc.org/ https://www.call-cc.org/
- logicchains 7y ago
  Idiomatic Clojure is also really slow compared to SBCL-compiled Common Lisp or one of the faster scheme implementations. The compiler's fairly basic and it relies on the JVM for optimisations, which isn't great at the kind of optimisations a compiler aware of higher level semantics can do. It is possible to achieve decent performance by using it as basically a Java wrapper, but that's much uglier than idiomatic code, compared to e.g. SBCL Common Lisp where idiomatic code can still be fairly performant.
  - User23 7y ago
    Do you happen to know what the present state of SBCL optimization is? The old CMUCL manual had quite a lot of guidance on writing high performance code. I can't seem to find it though, mostly I remember the bits about what can and can't be open coded and how to give enough basic type hints to help the optimizer out (and using DISASSEMBLE to check that you really did). In fact I think you could even ask for warnings for probably inefficient constructs. Obviously CMUCL was a mess in a lot of other ways though.
    - fiddlerwoaroof 7y ago
      One great thing about sbcl is you can put (declare (optimize (speed 3))) at the top of a function and the compiler will give useful feedback when it can’t optimize something and suggest type hints to improve performance. I’m not a optimization wizard, but I’ve been able to get some very impressive speed ups this way, in combination with some attention to how my code is written.
reikonomusha 7y ago
We use Common Lisp to build compilers and simulators for quantum computers at Rigetti [0,1]. I wouldn’t consider the development stagnant. SBCL makes regular releases, including huge improvements (e.g., ported to risc v) and bug fixes. It’s easy to find commercial support for Common Lisp as well. I love Scheme and Common Lisp both, but CL is quite a workhorse when it comes to difficult, professional work on teams. [0] https://github.com/rigetti/quilc https://github.com/rigetti/quilc [1] https://github.com/rigetti/qvm https://github.com/rigetti/qvm
- agumonkey 7y ago
  Do you write articles on practices at work ? I'd love to see [sb]CL usage in the field for real rather than in books :)
  - reikonomusha 7y ago
    We haven’t so far, though we’d consider if it would be of interest to more than just Lispers. The code is open source though!
dannyobrien 7y ago
There’s some interesting work going on in the Guile ecosystem: the new JIT compiler is just on the horizon, and nicely timed with Guix maturing as a platform. It’s lacking some real basic tooling (including an officially blessed package manager), but that gives its small community a chance to learn from the experience of earlier Lisps (including the first few years of Guile) and build something worthy of being the GNU projects’ language of choice.
- bjoli 7y ago
  As someone who's using guile every day, I am very happy about my language of choice. The problem is that I program for fun and rarely have a deadline to meet. Guix is amazing, and I will try to run it on my next laptop
fulafel 7y ago
You aren't tied to JVM with Clojure, you can target JS too. Outside browsers people are using ClojureScript for mobile apps, web app backends (eg with serverless), and local scripting. There's also the CLR version that some people are using with Unity for game dev. But I think JVM has really good prospects, even if the trend is currently favouring JS. Straddling both JS and JVM platforms is a pretty good position for Clojure. There are great benefits to being able to leverage the JVM and NPM libraries. A lot of it happens indirectly, many libs are available that provide integrations to JVM/JS libs under the hood but present you with a Clojurey interface.
xvilka 7y ago
You can monitor ultralisp[1] repository for interesting packages to jump in. [1] https://ultralisp.org/ https://ultralisp.org/
sriharis 7y ago
Clojure for the Erlang VM: https://github.com/clojerl/clojerl https://github.com/clojerl/clojerl
taeric 7y ago
Odds are high that any will be a fun investment. Common Lisp is interesting for just how much it already has. In particular, I'm finding many of the things that supposedly aren't great about it, to be quite productive if you embrace it. LOOP and FORMAT, in particular.
User23 7y ago
You pretty much answered your own question. Common Lisp is the big one. Scheme has more of a niche as an extension language, but Racket is a completely decent development environment and language family. Clojure is a JVM language with some neat persistent data structures. Personally I find it to be one of the least interesting Lisps, but that's like saying it's not my favorite pizza. It's still quite tasty. Furthermore, I can easily get paid to write it, which is a little harder for the others.
gekkonier 7y ago
It depends heavenly on what you want to do. All of them SBCL, Racket and Clojure work platform independent, and have different strengths. I'd choose it based on type of application.
iLemming 7y ago
I've never used Common Lisp, I know some Clojure, used emacs-lisp, tried Racket, Fennel. I love Lisps. But I always wondered: What happened to Common Lisp? Some of the opinions I heard: - CL is too big (compared to Racket and Clojure) - Lisp-1 vs Lisp-2 - recursion discouraged (is that even true?) - There is a thing called "Lisp Curse" And then seemingly language's popularity decreased. Let's ignore the fact that I really like Lisps, aside that, are there any compelling reasons for an average Joe programmer like me to start learning Common Lisp in 2019? Honest question.
- ohyes 7y ago
  None of these seem legitimate to me. Language is not big compared to python or something. Technically it is a lisp-n not a lisp 2, doesn’t matter in a practical sense. Optimization of tail recursion isn’t in the spec but is done in some compilers. Loops are encouraged, as is mutation, objects. It’s truly multi-paradigm. It is very powerful, so in some ways it ruins you when you have to go back to writing python code, adhering to ‘PEP 8’ Standards, and people looking over your shoulder at code reviews. Common Lisp has the potential to be freewheeling and exploratory in a way that other languages still do not. I think of something, therefore I write it and it exists. There isn’t a lot of hemming and hawing about ceremony and rigor. I like that feature of Common Lisp... it is my own patch of the Wild West, to some extent. A lot of people think that if something isn’t difficult and tedious, it isn’t really software engineering. They may be right, but I prefer whatever this non-engineering discipline is to what I’m doing now.
- pfdietz 7y ago
  CL might have been considered big, decades ago, but it's positively lean and mean today. I can build SBCL from scratch on my desktop in 90 seconds. Clang takes much longer to build.
- heisig 7y ago
  > What happened to Common Lisp? Common Lisp is probably in its best shape ever. There is finally a good package manager (https://www.quicklisp.org/ https://www.quicklisp.org/), plenty of documentation (https://common-lisp.net/documentation https://common-lisp.net/documentation), and active communities on reddit, #lisp and elsewhere (http://planet.lisp.org/ http://planet.lisp.org/). There is and has always been a lot of FUD around Lisp, and Common Lisp in particular. You even mentioned a few examples. My explanation on why this is the case is that learning Common Lisp really takes some time and dedication, but our lazy brains try hard to avoid that and find silly excuses instead (Too many parentheses!). > are there any compelling reasons for an average Joe programmer like me to start learning Common Lisp in 2019? If you manage to use Common Lisp in a project, you get an enormous boost to productivity. It is the best language for 'getting stuff done' that I know of. Even if you cannot use Common Lisp directly, knowing it will stop you from reinventing a lot of wheels. Greenspun's tenth rule is real.
lispm 7y ago
> Common Lisp still has some activity CLASP is a relatively new Common Lisp implementation with deep C++/LLVM integration. https://github.com/clasp-developers/clasp https://github.com/clasp-developers/clasp Quicklisp adds new libraries every month. http://blog.quicklisp.org http://blog.quicklisp.org LispWorks and Allegro CL are commercially available Lisps since 30+ years, running on various platforms and still supported. The LispWorks 7.1 update from 2017 brought native ARM64 support (Linux, iOS), remote debugging of Android and iOS LispWorks, ...
ced 7y ago
Julia? It depends on what you're looking for, but IMO apart from the non-lispy surface syntax (which Dylan also had), it's very much a Lisp with a focus on multiple dispatch.
rauhl 7y ago
> Common Lisp still has some activity, mainly coming from SBCL, but is a bit stagnant. It has a fantastic literature and many mature implementations. There are a number of improvements I’d like to see to the core language, but in general I think Common Lisp is more ‘complete’ than it is ‘stagnant.’ I.e., it enables one to write software which is performant, dynamic, able to handle errors as they occur &c. I recommend it over Scheme in large part because it is so complete, over Racket because it has multiple implementations and over Clojure because I like that it’s multi-paradigm. But tastes differ, and that’s okay. I like that Common Lisp isn’t afflicted with flavour-of-the-month syndrome. There are libraries for Lisp which have been around, essentially untouched, for years and which still work correctly. Done right, the first time — what a concept!
karmakaze 7y ago
For learning definitely DrRacket which includes many dialects. For small fun projects CHICKEN Scheme (or Carp if you like). Larger scale/production use either Clojure or SBCL.

by nextos 7y ago

grzm 7y ago

> ”Clojure has many interesting modern ideas, but I feel being so tied to Java and the JVM has hurt a bit in the long run.” Would you expand on this? From my perspective, it actually opens up Clojure to a lot of opportunities where introducing, say, Common Lisp or Racket, would be a much harder lift. Clojure’s just a library, and immediately has available the entire Java ecosystem. Granted, it’s based only on my experience, but I’ve much more frequently seen first-class (provided by a vendor or otherwise officially sanctioned) Java libraries for services and other tooling than Common Lisp or Racket. Being able to take something like that off the shelf for integration is a big plus in my experience.

fiddlerwoaroof 7y ago
For Common Lisp, there's ABCL ( https://abcl.org https://abcl.org ) which is a CL on the JVM and, otherwise, LispWorks bundles a nice Java FFI. But, additionally, CL makes binding to C libraries really easy via CFFI and things like cl-autowrap ( https://github.com/rpav/cl-autowrap https://github.com/rpav/cl-autowrap ) so, when there isn't a native lisp library, it's often easy enough to just use a C library in your program (or, I suppose, anything that can compile to something compatible with C like `extern C` in C++ and the equivalent constructs in Rust)
- slyrus 7y ago
  It would be nice if ABCL's JDK 11 support were brought into the main repo. Speaking of which, it would be nice if the main repo moved away from SVN to, e.g., gitlab. And, while we're at it, the issue tracker could be brought into the new millennium.
  - fiddlerwoaroof 7y ago
    Yeah, I just noticed this: https://mailman.common-lisp.net/pipermail/armedbear-devel/2019-April/003973.html https://mailman.common-lisp.net/pipermail/armedbear-devel/20... so, perhaps it's coming soon?

jpittis 7y ago

It's interesting that there's so much resistance to Clojure given it's modern / being used in production a fair bit. I've had a number of great experiences working on toy projects using Clojure but nevertheless feel resistance to adopt it fully "because of the JVM". I've pinned my own resistance down to three things: - Slow startup times. (Most of my use cases are not long running servers.) - Not "unixy". (I write programs to run on linux and OSX exclusively and am used to using non-portable APIs maybe?) - I've been lead to believe Java is "gross" and "enterprisy". Really, of those three reasons only the first one has merit. It kind of sounds silly when I put it this way: When I'm hacking on fun projects, I enjoy using a "hacker" language and Clojure doesn't feel like one. One implementation you didn't mention that's pretty neat is Chicken Scheme [1]. [1] https://www.call-cc.org/ https://www.call-cc.org/

logicchains 7y ago
Idiomatic Clojure is also really slow compared to SBCL-compiled Common Lisp or one of the faster scheme implementations. The compiler's fairly basic and it relies on the JVM for optimisations, which isn't great at the kind of optimisations a compiler aware of higher level semantics can do. It is possible to achieve decent performance by using it as basically a Java wrapper, but that's much uglier than idiomatic code, compared to e.g. SBCL Common Lisp where idiomatic code can still be fairly performant.
- User23 7y ago
  Do you happen to know what the present state of SBCL optimization is? The old CMUCL manual had quite a lot of guidance on writing high performance code. I can't seem to find it though, mostly I remember the bits about what can and can't be open coded and how to give enough basic type hints to help the optimizer out (and using DISASSEMBLE to check that you really did). In fact I think you could even ask for warnings for probably inefficient constructs. Obviously CMUCL was a mess in a lot of other ways though.
  - fiddlerwoaroof 7y ago
    One great thing about sbcl is you can put (declare (optimize (speed 3))) at the top of a function and the compiler will give useful feedback when it can’t optimize something and suggest type hints to improve performance. I’m not a optimization wizard, but I’ve been able to get some very impressive speed ups this way, in combination with some attention to how my code is written.

reikonomusha 7y ago

We use Common Lisp to build compilers and simulators for quantum computers at Rigetti [0,1]. I wouldn’t consider the development stagnant. SBCL makes regular releases, including huge improvements (e.g., ported to risc v) and bug fixes. It’s easy to find commercial support for Common Lisp as well. I love Scheme and Common Lisp both, but CL is quite a workhorse when it comes to difficult, professional work on teams. [0] https://github.com/rigetti/quilc https://github.com/rigetti/quilc [1] https://github.com/rigetti/qvm https://github.com/rigetti/qvm

agumonkey 7y ago
Do you write articles on practices at work ? I'd love to see [sb]CL usage in the field for real rather than in books :)
- reikonomusha 7y ago
  We haven’t so far, though we’d consider if it would be of interest to more than just Lispers. The code is open source though!

dannyobrien 7y ago

There’s some interesting work going on in the Guile ecosystem: the new JIT compiler is just on the horizon, and nicely timed with Guix maturing as a platform. It’s lacking some real basic tooling (including an officially blessed package manager), but that gives its small community a chance to learn from the experience of earlier Lisps (including the first few years of Guile) and build something worthy of being the GNU projects’ language of choice.

bjoli 7y ago
As someone who's using guile every day, I am very happy about my language of choice. The problem is that I program for fun and rarely have a deadline to meet. Guix is amazing, and I will try to run it on my next laptop

fulafel 7y ago

You aren't tied to JVM with Clojure, you can target JS too. Outside browsers people are using ClojureScript for mobile apps, web app backends (eg with serverless), and local scripting. There's also the CLR version that some people are using with Unity for game dev. But I think JVM has really good prospects, even if the trend is currently favouring JS. Straddling both JS and JVM platforms is a pretty good position for Clojure. There are great benefits to being able to leverage the JVM and NPM libraries. A lot of it happens indirectly, many libs are available that provide integrations to JVM/JS libs under the hood but present you with a Clojurey interface.

xvilka 7y ago

You can monitor ultralisp[1] repository for interesting packages to jump in. [1] https://ultralisp.org/ https://ultralisp.org/

sriharis 7y ago

Clojure for the Erlang VM: https://github.com/clojerl/clojerl https://github.com/clojerl/clojerl

taeric 7y ago

Odds are high that any will be a fun investment. Common Lisp is interesting for just how much it already has. In particular, I'm finding many of the things that supposedly aren't great about it, to be quite productive if you embrace it. LOOP and FORMAT, in particular.

User23 7y ago

You pretty much answered your own question. Common Lisp is the big one. Scheme has more of a niche as an extension language, but Racket is a completely decent development environment and language family. Clojure is a JVM language with some neat persistent data structures. Personally I find it to be one of the least interesting Lisps, but that's like saying it's not my favorite pizza. It's still quite tasty. Furthermore, I can easily get paid to write it, which is a little harder for the others.

gekkonier 7y ago

It depends heavenly on what you want to do. All of them SBCL, Racket and Clojure work platform independent, and have different strengths. I'd choose it based on type of application.

iLemming 7y ago

I've never used Common Lisp, I know some Clojure, used emacs-lisp, tried Racket, Fennel. I love Lisps. But I always wondered: What happened to Common Lisp? Some of the opinions I heard: - CL is too big (compared to Racket and Clojure) - Lisp-1 vs Lisp-2 - recursion discouraged (is that even true?) - There is a thing called "Lisp Curse" And then seemingly language's popularity decreased. Let's ignore the fact that I really like Lisps, aside that, are there any compelling reasons for an average Joe programmer like me to start learning Common Lisp in 2019? Honest question.

ohyes 7y ago
None of these seem legitimate to me. Language is not big compared to python or something. Technically it is a lisp-n not a lisp 2, doesn’t matter in a practical sense. Optimization of tail recursion isn’t in the spec but is done in some compilers. Loops are encouraged, as is mutation, objects. It’s truly multi-paradigm. It is very powerful, so in some ways it ruins you when you have to go back to writing python code, adhering to ‘PEP 8’ Standards, and people looking over your shoulder at code reviews. Common Lisp has the potential to be freewheeling and exploratory in a way that other languages still do not. I think of something, therefore I write it and it exists. There isn’t a lot of hemming and hawing about ceremony and rigor. I like that feature of Common Lisp... it is my own patch of the Wild West, to some extent. A lot of people think that if something isn’t difficult and tedious, it isn’t really software engineering. They may be right, but I prefer whatever this non-engineering discipline is to what I’m doing now.
pfdietz 7y ago
CL might have been considered big, decades ago, but it's positively lean and mean today. I can build SBCL from scratch on my desktop in 90 seconds. Clang takes much longer to build.
heisig 7y ago
> What happened to Common Lisp? Common Lisp is probably in its best shape ever. There is finally a good package manager (https://www.quicklisp.org/ https://www.quicklisp.org/), plenty of documentation (https://common-lisp.net/documentation https://common-lisp.net/documentation), and active communities on reddit, #lisp and elsewhere (http://planet.lisp.org/ http://planet.lisp.org/). There is and has always been a lot of FUD around Lisp, and Common Lisp in particular. You even mentioned a few examples. My explanation on why this is the case is that learning Common Lisp really takes some time and dedication, but our lazy brains try hard to avoid that and find silly excuses instead (Too many parentheses!). > are there any compelling reasons for an average Joe programmer like me to start learning Common Lisp in 2019? If you manage to use Common Lisp in a project, you get an enormous boost to productivity. It is the best language for 'getting stuff done' that I know of. Even if you cannot use Common Lisp directly, knowing it will stop you from reinventing a lot of wheels. Greenspun's tenth rule is real.

lispm 7y ago

> Common Lisp still has some activity CLASP is a relatively new Common Lisp implementation with deep C++/LLVM integration. https://github.com/clasp-developers/clasp https://github.com/clasp-developers/clasp Quicklisp adds new libraries every month. http://blog.quicklisp.org http://blog.quicklisp.org LispWorks and Allegro CL are commercially available Lisps since 30+ years, running on various platforms and still supported. The LispWorks 7.1 update from 2017 brought native ARM64 support (Linux, iOS), remote debugging of Android and iOS LispWorks, ...

ced 7y ago

Julia? It depends on what you're looking for, but IMO apart from the non-lispy surface syntax (which Dylan also had), it's very much a Lisp with a focus on multiple dispatch.

rauhl 7y ago

> Common Lisp still has some activity, mainly coming from SBCL, but is a bit stagnant. It has a fantastic literature and many mature implementations. There are a number of improvements I’d like to see to the core language, but in general I think Common Lisp is more ‘complete’ than it is ‘stagnant.’ I.e., it enables one to write software which is performant, dynamic, able to handle errors as they occur &c. I recommend it over Scheme in large part because it is so complete, over Racket because it has multiple implementations and over Clojure because I like that it’s multi-paradigm. But tastes differ, and that’s okay. I like that Common Lisp isn’t afflicted with flavour-of-the-month syndrome. There are libraries for Lisp which have been around, essentially untouched, for years and which still work correctly. Done right, the first time — what a concept!

karmakaze 7y ago

For learning definitely DrRacket which includes many dialects. For small fun projects CHICKEN Scheme (or Carp if you like). Larger scale/production use either Clojure or SBCL.