4 ms·

I love Lisp and Scheme and all their relatives (Clojure, Logo, Racket, etc.). However, the fact of the matter is, Common Lisp has not kept up with modern develo

by bmitc 5y ago

I love Lisp and Scheme and all their relatives (Clojure, Logo, Racket, etc.). However, the fact of the matter is, Common Lisp has not kept up with modern developments in terms of presenting a cohesive ecosystem with forward momentum. Everybody is off on their own doing their own thing with no shared goals or cohesion. Clojure seems to have this (I have not used Clojure much, so I don't really know). Elixir definitely has this. I think Elixir is the language ecosystem to look at in terms of having a solidified core language that is essentially done, and now the goal is to continue to flesh out the ecosystem with things like Nx, Axon, Livebook, Liveview, Mix improvements, Phoenix, etc. Elixir is pretty similar to Lisp/Scheme anyway given its macros, ability to live update, dynamically typed programming, but it goes well beyond any Lisp/Scheme (and many modern languages) in terms of having a practical but expansive ecosystem with a strong set of idiomatic conventions.

lukego 5y ago
There was one cohesive tribe in the 00s centered around the quasi-annual European Common Lisp Meeting. I miss that and wish I could find the same thing again now. Maybe it exists somewhere online? The ELS community is still going strong. They have done a great job with continuity and moving forwards. That's a related but different tribe though.
brabel 5y ago
> ... it goes well beyond any Lisp/Scheme (and many modern languages) in terms of having a practical but expansive ecosystem with a strong set of idiomatic conventions. Does it, really?? Common Lisp is an ANSI Standard, I don't know how you get a more "strong set of idiomatic conventions" than that. And it's been "done" for 20 years now! People continue to use it just as it is, and there's very little pressure to change it because it simply works! You're trying to justify a new wave of "modern" languages with a very weak argument... just call it for what it is: you want "cool", hyped languages to succeed despite the fact they offer nothing that the CL standard did not 20 years ago.
- tho23u4i23o4 5y ago
  In fairness, the CL spec being quite old, has a fairly dated type system. Obviously, CL is still blazing fast compared to Python, but it can't easily do the kind of things that Julia or even C++ can when it comes to numerical programming. You can write a lot of macrology to get around it, but there's a point where you want actual compiler writers to be doing this.
  - medo-bear 5y ago
    > You can write a lot of macrology to get around it, but there's a point where you want actual compiler writers to be doing this this is not the job of compiler writers (although writing macros is akin to writing a compiler but i do not think that this is what you mean). in julia the numerical programming packages are not part of the standard library and a lot of it is wrappers around C++ code especially when the drivers to the underlining hardware are closed-source [0]. also here is the similar library in common lisp [1] [0] https://github.com/JuliaGPU/CUDA.jl https://github.com/JuliaGPU/CUDA.jl [1] https://github.com/takagi/cl-cuda https://github.com/takagi/cl-cuda
    - eigenspace 5y ago
      > this is not the job of compiler writers Presumably what the GP means is that you can use macros to hack around limitations of CL's type system, such as lack of parametric types, or whatever (very important for good multidimensional generic array code), but they'd rather that the CLOS was just built to be more expressive in the first place, because their local hacks will not be as good as what a language development team can produce while working together. > in julia the numerical programming packages are not part of the standard library and a lot of it is wrappers around C++ code especially when the drivers to the underlining hardware are closed-source [0]. This is mostly false. First of all, there's a huge amount of numerical programming infrastructure in Base julia and it's standard library. There is even more outside of the base/stdlib, but the stuff inside is quite diverse and robust. Second of all, CUDA.jl is a very weird thing to point to for your example. CUDA.jl is essentially a compiler plugin for julia that hijacks it's normal compilation pipeline for specified code and then causes it to emit GPU specialized instructions to LLVM which then compiles a binary. If compiling to LLVM is a 'wrapper around C++ code' then all julia code is that (but note, this is a rather dumb definition of 'wrapping').
creamytaco 5y ago
I'm not exactly a Lisp fan (I'm firmly in the statically typed camp), but this is a weak argument. Common Lisp specifically is one of the most cohesive experiences one can find out there, the language has had a long time to mature, it's ANSI standardized and the ecosystem is largely built on top of that cohesive base.
medo-bear 5y ago
can you write compilers in elixir ? how does its interactive programming compare to that of Lisp ?
- bmitc 5y ago
  I don't claim that Elixir is the language to end all languages. My comment was more about the holistic ecosystem that keeps improving. There's one common development and project management tool (Mix). There's one package manager (Hex). There's OTP, Ecto, Phoenix, Liveview, etc. There's the Elixir Forum for questions. I'd use F# for writing compilers. Interactive programming is probably better in Common Lisp and also Smalltalk descendants like Pharo. But Elixir has some great interactive tooling. I think this is an excellent presentation that summarizes the capability (not necessarily saying other languages don't) in terms of real world applications: https://www.youtube.com/watch?v=JvBT4XBdoUE https://www.youtube.com/watch?v=JvBT4XBdoUE
  - medo-bear 5y ago
    > I don't claim that Elixir is the language to end all languages. i don't know much elixir. i was asking because those things interest me and they are what drove me to common lisp. for my purposes i need an industrial fast interactive language that is self hosted and well tested in the wild. i want a fast language that is well suited to make custom symbolic computer algebra procedures, custom differential algorithms, custom probabilistic programs, and custom data processing solutions. i think that common lisp best fits the criteria for my use case
vindarel 5y ago
mmh Elixir definitely has its gems and I need to try it for real. Where I can see it's lacking: no compile-time type warnings (unless you're using a new language on top or using a third-party library, but then we should compare more thoroughly), no compilation with a keystroke function per function. No static executable (even though deployment options are getting better in Elixir (we had to wait though)). Some compilation times, when you change one file and Elixir needs to compile a dozen. We are not inside a live image. I tried Alchemist mode for Emacs: no function signature? No "eval this expression"? Can you switch projects from inside a REPL, or you have to start a new one? No cross-reference capacities built-in? (who calls this function, this macro, who sets, etc) No inspect? No trace? No interactive debugger and no stepper? If only available with LSP and VSCode, then it's strictly inferior. Elixir is less performant in crunching numbers. Less to no GUI framework choice (WxWidgets). No industry-grade theorem prover? (ACL2) Unfit for quantum computing? Unable to program Intel chips? (Barefoot Networks) No computer algebra system? No music composition suite (Opus Modus)? CL's ecosystem might be better than one thinks: https://github.com/CodyReichert/awesome-cl https://github.com/CodyReichert/awesome-cl & https://lisp-journey.gitlab.io/blog/state-of-the-common-lisp-ecosystem-2020/ https://lisp-journey.gitlab.io/blog/state-of-the-common-lisp...
daniel-cussen 5y ago
The thing about Common Lisp is, code doesn't rot. It doesn't matter if CL code is 5 years old or 30, it runs. I have yet to see even one ounce of bit rot. CL code is as eternal as solid gold, honestly. And sometimes, yes, there's a few ways your code will fail to run, mostly because you're shooting yourself in the foot (eg starting slime in a different directory than what you're meant to). Versus Python, I didn't even get to use Python 2 before I started getting nagged and harangued by various exceptions in the terminal about how I had to migrate to Python 3. And it depends what you're doing with CL, how well it works for you. As an algorithm designer, I use literally no libraries. I don't glue anything to anything. I just use the batteries that come included with Common Lisp (SBCL is great), forget about connecting to the internet, forget I/O, forget graphics and GUIs and OOP, and just focus on coming up with as many ideas as I can per minute, until I crack the algorithmic problem. Just with the austere tools that come included in SBCL: xor (#'logxor), popcount (#'logcount), #'sort, #'svref, #'pop, #'push, #'make-array, #'dotimes, 'lambda, 'labels, 'let, 'do, the basics.
- tmm84 5y ago
  I can't think of any code rot either. As long as it is built against the standard it tends to just work. I also find the idea of using no libraries a big thing in more advanced users of CL. The more advanced of a user the more it makes sense that you can just implement it yourself (with only the functionality required) and know it works without having to leverage a library. Then again, the idea of CL is that things that tend to be bigger/harder to solve problems in other languages can be done simpler in CL because you can break the problem up different and have an easier to understand or implement solution.

by bmitc 5y ago

lukego 5y ago

There was one cohesive tribe in the 00s centered around the quasi-annual European Common Lisp Meeting. I miss that and wish I could find the same thing again now. Maybe it exists somewhere online? The ELS community is still going strong. They have done a great job with continuity and moving forwards. That's a related but different tribe though.

brabel 5y ago

> ... it goes well beyond any Lisp/Scheme (and many modern languages) in terms of having a practical but expansive ecosystem with a strong set of idiomatic conventions. Does it, really?? Common Lisp is an ANSI Standard, I don't know how you get a more "strong set of idiomatic conventions" than that. And it's been "done" for 20 years now! People continue to use it just as it is, and there's very little pressure to change it because it simply works! You're trying to justify a new wave of "modern" languages with a very weak argument... just call it for what it is: you want "cool", hyped languages to succeed despite the fact they offer nothing that the CL standard did not 20 years ago.

tho23u4i23o4 5y ago
In fairness, the CL spec being quite old, has a fairly dated type system. Obviously, CL is still blazing fast compared to Python, but it can't easily do the kind of things that Julia or even C++ can when it comes to numerical programming. You can write a lot of macrology to get around it, but there's a point where you want actual compiler writers to be doing this.
- medo-bear 5y ago
  > You can write a lot of macrology to get around it, but there's a point where you want actual compiler writers to be doing this this is not the job of compiler writers (although writing macros is akin to writing a compiler but i do not think that this is what you mean). in julia the numerical programming packages are not part of the standard library and a lot of it is wrappers around C++ code especially when the drivers to the underlining hardware are closed-source [0]. also here is the similar library in common lisp [1] [0] https://github.com/JuliaGPU/CUDA.jl https://github.com/JuliaGPU/CUDA.jl [1] https://github.com/takagi/cl-cuda https://github.com/takagi/cl-cuda
  - eigenspace 5y ago
    > this is not the job of compiler writers Presumably what the GP means is that you can use macros to hack around limitations of CL's type system, such as lack of parametric types, or whatever (very important for good multidimensional generic array code), but they'd rather that the CLOS was just built to be more expressive in the first place, because their local hacks will not be as good as what a language development team can produce while working together. > in julia the numerical programming packages are not part of the standard library and a lot of it is wrappers around C++ code especially when the drivers to the underlining hardware are closed-source [0]. This is mostly false. First of all, there's a huge amount of numerical programming infrastructure in Base julia and it's standard library. There is even more outside of the base/stdlib, but the stuff inside is quite diverse and robust. Second of all, CUDA.jl is a very weird thing to point to for your example. CUDA.jl is essentially a compiler plugin for julia that hijacks it's normal compilation pipeline for specified code and then causes it to emit GPU specialized instructions to LLVM which then compiles a binary. If compiling to LLVM is a 'wrapper around C++ code' then all julia code is that (but note, this is a rather dumb definition of 'wrapping').

creamytaco 5y ago

I'm not exactly a Lisp fan (I'm firmly in the statically typed camp), but this is a weak argument. Common Lisp specifically is one of the most cohesive experiences one can find out there, the language has had a long time to mature, it's ANSI standardized and the ecosystem is largely built on top of that cohesive base.

medo-bear 5y ago

can you write compilers in elixir ? how does its interactive programming compare to that of Lisp ?

bmitc 5y ago
I don't claim that Elixir is the language to end all languages. My comment was more about the holistic ecosystem that keeps improving. There's one common development and project management tool (Mix). There's one package manager (Hex). There's OTP, Ecto, Phoenix, Liveview, etc. There's the Elixir Forum for questions. I'd use F# for writing compilers. Interactive programming is probably better in Common Lisp and also Smalltalk descendants like Pharo. But Elixir has some great interactive tooling. I think this is an excellent presentation that summarizes the capability (not necessarily saying other languages don't) in terms of real world applications: https://www.youtube.com/watch?v=JvBT4XBdoUE https://www.youtube.com/watch?v=JvBT4XBdoUE
- medo-bear 5y ago
  > I don't claim that Elixir is the language to end all languages. i don't know much elixir. i was asking because those things interest me and they are what drove me to common lisp. for my purposes i need an industrial fast interactive language that is self hosted and well tested in the wild. i want a fast language that is well suited to make custom symbolic computer algebra procedures, custom differential algorithms, custom probabilistic programs, and custom data processing solutions. i think that common lisp best fits the criteria for my use case

vindarel 5y ago

mmh Elixir definitely has its gems and I need to try it for real. Where I can see it's lacking: no compile-time type warnings (unless you're using a new language on top or using a third-party library, but then we should compare more thoroughly), no compilation with a keystroke function per function. No static executable (even though deployment options are getting better in Elixir (we had to wait though)). Some compilation times, when you change one file and Elixir needs to compile a dozen. We are not inside a live image. I tried Alchemist mode for Emacs: no function signature? No "eval this expression"? Can you switch projects from inside a REPL, or you have to start a new one? No cross-reference capacities built-in? (who calls this function, this macro, who sets, etc) No inspect? No trace? No interactive debugger and no stepper? If only available with LSP and VSCode, then it's strictly inferior. Elixir is less performant in crunching numbers. Less to no GUI framework choice (WxWidgets). No industry-grade theorem prover? (ACL2) Unfit for quantum computing? Unable to program Intel chips? (Barefoot Networks) No computer algebra system? No music composition suite (Opus Modus)? CL's ecosystem might be better than one thinks: https://github.com/CodyReichert/awesome-cl https://github.com/CodyReichert/awesome-cl & https://lisp-journey.gitlab.io/blog/state-of-the-common-lisp-ecosystem-2020/ https://lisp-journey.gitlab.io/blog/state-of-the-common-lisp...

daniel-cussen 5y ago

The thing about Common Lisp is, code doesn't rot. It doesn't matter if CL code is 5 years old or 30, it runs. I have yet to see even one ounce of bit rot. CL code is as eternal as solid gold, honestly. And sometimes, yes, there's a few ways your code will fail to run, mostly because you're shooting yourself in the foot (eg starting slime in a different directory than what you're meant to). Versus Python, I didn't even get to use Python 2 before I started getting nagged and harangued by various exceptions in the terminal about how I had to migrate to Python 3. And it depends what you're doing with CL, how well it works for you. As an algorithm designer, I use literally no libraries. I don't glue anything to anything. I just use the batteries that come included with Common Lisp (SBCL is great), forget about connecting to the internet, forget I/O, forget graphics and GUIs and OOP, and just focus on coming up with as many ideas as I can per minute, until I crack the algorithmic problem. Just with the austere tools that come included in SBCL: xor (#'logxor), popcount (#'logcount), #'sort, #'svref, #'pop, #'push, #'make-array, #'dotimes, 'lambda, 'labels, 'let, 'do, the basics.

tmm84 5y ago
I can't think of any code rot either. As long as it is built against the standard it tends to just work. I also find the idea of using no libraries a big thing in more advanced users of CL. The more advanced of a user the more it makes sense that you can just implement it yourself (with only the functionality required) and know it works without having to leverage a library. Then again, the idea of CL is that things that tend to be bigger/harder to solve problems in other languages can be done simpler in CL because you can break the problem up different and have an easier to understand or implement solution.