[Openmcl-devel] The M1 port and the future of CCL

[J Klein]

I agree with Robert that ECL and ABCL are too sluggish to be practical replacements for CCL or SBCL.   I had to port a scheduling program from ABCL to SBCL for this reason.

I think that CCL is the ideal Lisp for small platforms like the Raspberry Pi (and maybe phones and tablets, if the ecosystem owners permit it), given its mix of speed and light weight.   I formerly used it on the RPi until the failure of threading on multiple cores drove me to 64 bit Raspian and SBCL, which is a tad too heavyweight.    ECL was just too slow to run and compile, and broke too many packages.

Given that arm64 is likely to be the dominant platform for small-device computing, it seems that porting CCL to it would be a huge benefit, whether or not the Macintosh IDE is supported.

I'd certainly be willing to contribute a modest amount of money, enough to pay for a day or two of work, to achieve a stable arm64 port.  Some documentation of the internals would be great too, as I learned from my efforts to tackle the thread bug in arm32.









> 
> I use CL for computationally challenging processes (see, e.g., https://github.com/shop-planner/shop3).  ECL's compiler generates code that is simply too sluggish to be usable for such problems.  I would warn you away from that. TBH, I think pushing CL code through a C compiler is a losing proposition -- the development environment is also unpleasant and sluggish to work with.  For that matter, although I have used ABCL to script Java applications happily, its code is also way too sluggish for practical use as a "main" programming language (as opposed to a scripting shell).
> 
> If CCL goes away (I hope it does not, but I agree it will be very challenging to keep it alive), then unless you are willing to pay for LispWorks or Allegro, SBCL is the only game in town.
> 
> Of course this is all my personal opinion and YMMV and YUCMV (Your Use Case May Vary).
> 
> Best,
> R