3 ms·

One of the tragedies of Common Lisp programming: good Lisp hackers seem more interested in writing yet another Common Lisp than extending the capabilities of ex

One of the tragedies of Common Lisp programming: good Lisp hackers seem more interested in writing yet another Common Lisp than extending the capabilities of existing ones. It's not like there isn't work to be done: writing decent native array and higher order mathematical primitives in any lisp would be a huge improvement over the existing state of affairs; we know SBCL and CMU-CL have the compiler for it (Fateman wrote about this in the 80s for pete sake), but ... no such thing exists. A package management system that you don't have to invoke lucifer to use would also help (leiningen for CL). A common threading model that makes sense would also be nice. Yes, yes, you get some half assed threads on some platforms in some lisps; big deal. Make them work everywhere instead of developing ... yet another Common Lisp. For open source, we already have: CLISP, SBCL, CMU-CL, GCL, ECL, ABCL, MKCL, MCL, Movitz, OpenMCL, CLiCC, Kyoto, CCL, Jatha, ThinLisp, UABCL, WCL, XCL. For pay-for Common Lisp, Corman, Allegro, LispWorks and doubtless some others. Obviously, the world cries out for more Common Lisp implementations!

pohl 12y ago
SICL appears to be an effort to alleviate some of that, judging from this: [SICL] is intentionally divided into many implementation-independent modules that are written in a totally or near-totally portable way, so as to allow other implementations to incorporate these modules from SICL, rather than having to maintain their own, perhaps implementation-specific versions.
enupten 12y ago
I would also add parametric types to that list. I've always found it really annoying not to be able to define a type like "array" with element-type, dimensions and things (other than the global variable hack). Did you mean Scientific computing ? FEMLISP is refreshingly well written (and fast), and the new version Matlisp I'm writing should also be as good (if less elegant and MOP-py). See: https://github.com/enupten/matlisp/wiki https://github.com/enupten/matlisp/wiki . The "einstein-sum" macro at the end actually generates code which on SBCL is about 20-40% slower than equivalent C code (but this is all naive cache-friendly loops).
- orbifold 12y ago
  I think a lot of the features Julia julialang.org has, could be implemented just as easily in Common Lisp. Macros in general are much simpler to use to generate domain specific code than templates in C++ are, yet there are tons of very high effort numerical algorithms implemented in C++ and virtually none in Common Lisp.
  - enupten 12y ago
    Did you see the wiki ?
    - orbifold 12y ago
      Yes, maybe it wasn't clear, my comment was meant as a reinforcement of your statement. The einstein-sum example is in line with what some C++ libraries can do, but I expect the common lisp implementation to be much simpler. Even more complex libraries like deal.II for pde-solving would probably benefit immensily from a domain specific language instead of a C++ interface.
      - enupten 12y ago
        Can you elaborate on what you mean by "simpler" ? Drop me a mail if you like.
  - scottlocklin 12y ago
    A CL with useful math facilities and a decent parallel model would be, like, a zillion times better than anything happening in Julia land. It's not like there isn't a market for something like this: the existence of Incanter and the past existence of XLispStat ought to have demonstrated this. Incanter, of course, will never have adequate numerics performance because the JVM is garbage for numerics, and probably always will be. As I said: Fateman demonstrated that this is possible using CMU-CL or Allegro or whatever it was ... decades ago. Sadly, it never happened.
- scottlocklin 12y ago
  FEMLISP is pretty cool. Sadly, when I need to do finite element analysis, I end up doing it in Matlab, because vastly more work has been done there. I guess the next time I have to make my own FTDT solver, I will think about doing something like this. Thanks for working on Matlisp; it's a great idea. Have a close look at Torch7 and how they managed to bake pthreads and CUDA into their "THTensor" class (aka, the descendant of the Lush -idx- array type). I don't know if it's the best that can be done, but I trust what has been done there more than what is happening in other areas, as this ends up being used on serious problems.
sedachv 12y ago
> A package management system that you don't have to invoke lucifer to use would also help (leiningen for CL) What do you think are the biggest problems with ASDF? > A common threading model that makes sense would also be nice. Which memory model should this threading system guarantee? Which concurrency primitives? How is this going to be supported on all the different platforms the different CL implementations are available for? What do you think are the biggest problems with bordeaux-threads? > CLISP, SBCL, CMU-CL, GCL, ECL, ABCL, MKCL, MCL, Movitz, OpenMCL, CLiCC, Kyoto, CCL, Jatha, ThinLisp, UABCL, WCL, XCL CLiCC and ThinLisp are deployment tools and not full-blown implementations. Neither of them have been actively developed in the last decade (I was the last person to touch ThinLisp about 8(?) years ago). WCL is a shared library from the 90s. Kyoto, GCL, ECL, MKCL are forks/descendants of the same implementation (in that chronological order). Corman Common Lisp hasn't been developed in years. > good Lisp hackers seem more interested in writing yet another Common Lisp than extending the capabilities of existing ones. If you actually look, the two sets of people (Lisp library/application hackers and Lisp implementation maintainers) are pretty distinct. If someone wants to make another Common Lisp implementation, that doesn't take resources away from Common Lisp libraries, and it doesn't fracture the community (that's why standards are a good thing). It would be great to have better array libraries and package managers and thread libraries. Saying that having less Common Lisp implementations will make those things happen is a false dichotomy.
- TeMPOraL 12y ago
  >> A package management system that you don't have to invoke lucifer to use would also help (leiningen for CL) > What do you think are the biggest problems with ASDF? Especially when backed up by QuickLisp? Together they seem to be extremely good and quite easy to use.
- scottlocklin 12y ago
  I never said having fewer CL implementations will make these things happen. Obviously, nothing will make these things happen. I simply wonder why people want to build yet another common lisp, rather than fixing one or more of the vastly too many we have already. The world really doesn't require any more beige common lisp implementations no matter how much fun it is to write one.
aidenn0 12y ago
See the issue is you and I have very different ideas of what work needs to be done: I don't use higher-order mathematical primitives in my work, so that's out. I avoid threading like the plauge (even in non-lisp code), and I've never had to sacrifice a single goat to get quicklisp to work.

pohl 12y ago

SICL appears to be an effort to alleviate some of that, judging from this: [SICL] is intentionally divided into many implementation-independent modules that are written in a totally or near-totally portable way, so as to allow other implementations to incorporate these modules from SICL, rather than having to maintain their own, perhaps implementation-specific versions.

enupten 12y ago

I would also add parametric types to that list. I've always found it really annoying not to be able to define a type like "array" with element-type, dimensions and things (other than the global variable hack). Did you mean Scientific computing ? FEMLISP is refreshingly well written (and fast), and the new version Matlisp I'm writing should also be as good (if less elegant and MOP-py). See: https://github.com/enupten/matlisp/wiki https://github.com/enupten/matlisp/wiki . The "einstein-sum" macro at the end actually generates code which on SBCL is about 20-40% slower than equivalent C code (but this is all naive cache-friendly loops).

orbifold 12y ago
I think a lot of the features Julia julialang.org has, could be implemented just as easily in Common Lisp. Macros in general are much simpler to use to generate domain specific code than templates in C++ are, yet there are tons of very high effort numerical algorithms implemented in C++ and virtually none in Common Lisp.
- enupten 12y ago
  Did you see the wiki ?
  - orbifold 12y ago
    Yes, maybe it wasn't clear, my comment was meant as a reinforcement of your statement. The einstein-sum example is in line with what some C++ libraries can do, but I expect the common lisp implementation to be much simpler. Even more complex libraries like deal.II for pde-solving would probably benefit immensily from a domain specific language instead of a C++ interface.
    - enupten 12y ago
      Can you elaborate on what you mean by "simpler" ? Drop me a mail if you like.
- scottlocklin 12y ago
  A CL with useful math facilities and a decent parallel model would be, like, a zillion times better than anything happening in Julia land. It's not like there isn't a market for something like this: the existence of Incanter and the past existence of XLispStat ought to have demonstrated this. Incanter, of course, will never have adequate numerics performance because the JVM is garbage for numerics, and probably always will be. As I said: Fateman demonstrated that this is possible using CMU-CL or Allegro or whatever it was ... decades ago. Sadly, it never happened.
scottlocklin 12y ago
FEMLISP is pretty cool. Sadly, when I need to do finite element analysis, I end up doing it in Matlab, because vastly more work has been done there. I guess the next time I have to make my own FTDT solver, I will think about doing something like this. Thanks for working on Matlisp; it's a great idea. Have a close look at Torch7 and how they managed to bake pthreads and CUDA into their "THTensor" class (aka, the descendant of the Lush -idx- array type). I don't know if it's the best that can be done, but I trust what has been done there more than what is happening in other areas, as this ends up being used on serious problems.

sedachv 12y ago

> A package management system that you don't have to invoke lucifer to use would also help (leiningen for CL) What do you think are the biggest problems with ASDF? > A common threading model that makes sense would also be nice. Which memory model should this threading system guarantee? Which concurrency primitives? How is this going to be supported on all the different platforms the different CL implementations are available for? What do you think are the biggest problems with bordeaux-threads? > CLISP, SBCL, CMU-CL, GCL, ECL, ABCL, MKCL, MCL, Movitz, OpenMCL, CLiCC, Kyoto, CCL, Jatha, ThinLisp, UABCL, WCL, XCL CLiCC and ThinLisp are deployment tools and not full-blown implementations. Neither of them have been actively developed in the last decade (I was the last person to touch ThinLisp about 8(?) years ago). WCL is a shared library from the 90s. Kyoto, GCL, ECL, MKCL are forks/descendants of the same implementation (in that chronological order). Corman Common Lisp hasn't been developed in years. > good Lisp hackers seem more interested in writing yet another Common Lisp than extending the capabilities of existing ones. If you actually look, the two sets of people (Lisp library/application hackers and Lisp implementation maintainers) are pretty distinct. If someone wants to make another Common Lisp implementation, that doesn't take resources away from Common Lisp libraries, and it doesn't fracture the community (that's why standards are a good thing). It would be great to have better array libraries and package managers and thread libraries. Saying that having less Common Lisp implementations will make those things happen is a false dichotomy.

TeMPOraL 12y ago
>> A package management system that you don't have to invoke lucifer to use would also help (leiningen for CL) > What do you think are the biggest problems with ASDF? Especially when backed up by QuickLisp? Together they seem to be extremely good and quite easy to use.
scottlocklin 12y ago
I never said having fewer CL implementations will make these things happen. Obviously, nothing will make these things happen. I simply wonder why people want to build yet another common lisp, rather than fixing one or more of the vastly too many we have already. The world really doesn't require any more beige common lisp implementations no matter how much fun it is to write one.

aidenn0 12y ago

See the issue is you and I have very different ideas of what work needs to be done: I don't use higher-order mathematical primitives in my work, so that's out. I avoid threading like the plauge (even in non-lisp code), and I've never had to sacrifice a single goat to get quicklisp to work.