<div dir="ltr"><div>It would be nice to see CCL kept alive, but personally, I've settled on ABCL.  The JVM's GC technology is unmatched, the Java interop is occasionally useful, and it's completely future-proof.</div><div><br></div><div>-- Scott</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 22, 2023 at 11:35 AM Ron Garret <<a href="mailto:ron@flownet.com">ron@flownet.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Tim McNerny and I had a long discussion on the future of CCL this morning and I wanted to write up some of the things we talked about and solicit feedback from the community.<br>
<br>
I have been using CCL since the first C stood for Coral.  My first CCL ran on a Mac Plus with 1 MB of RAM and an 800k floppy drive.  That was nearly 30 years ago, and I've been using it more or less continuously ever since, both in professional setting and for my personal projects.  I have a lot invested in it.<br>
<br>
For me personally, there are three main sources of value in CCL:<br>
<br>
1.  The IDE and MacOS integration.  When it first came out, CCL blew everything else out of the water, and IMHO it's still the best available.  I really like having an editor that is well integrated into the Mac UI/UX that I can customize in CL rather than elisp, and I really like being able to develop native Mac applications interactively using the ObjC bridge and Cocoa integration.<br>
<br>
2.  Seamless and reliable migration to production environments.  I can run the exact same code in a Linux production environment as on my Mac development machine.  That allows me to have very high confidence that things will Just Work when I push production code.  CCL is also rock-solid.  I run server processes in CCL that run for months without needing any attention.<br>
<br>
3.  The compiler is blazingly fast, and the code it produces is plenty fast enough for my needs.  On the rare occasions when I need peak performance, I'll write some C code and call it via the FFI.  And on very, very rare occasions I can actually tweak the compiler if I really need to.<br>
<br>
The problem, of course, is that the Mac environment is and always has been a moving target.  CCL successfully made the transition from MC68k to PPC to x86 to x86-64, and now we're facing ARM64.  Unfortunately, the processor architecture is not the only thing that is moving this time.  The MacOS architecture is also undergoing significant changes away from its unix roots and becoming more like iOS.  AFAICT the writing is on the wall for Objective C.  Swift is the future on Macs.  And more generally, Apple as a company just doesn't value stability, and never has.<br>
<br>
This is not necessarily a bad thing.  Apple's willingness to jettison old standards is one of the things that allows them to stay at the cutting edge.  I really like my M1 Macbook Air.  More importantly, my wife likes her M1 Macbook Air.  I can't see her switching over to Linux, and being on the same environment as she is on has significant advantages when it comes time to put on my domestic tech support hat.<br>
<br>
So on the one hand, I would really love to see CCL continue to be a viable development environment for me.  On the other hand, I'm really starting to wonder whether it's really worth the effort.  Even if we manage to port the compiler and kernel to the M1, the ObjC bridge and IDE will probably need some significant additional work, and some day we will probably need a Swift bridge.  And God only knows what will happen in ten years.  For a system that has been useful for 30 years, that is a time horizon that matters.<br>
<br>
All of which has led to wonder if a better long-term solution for me might be to go to a different CL implementation.  I've tried SBCL and ECL on the M1 and both seem to work quite well, though I have not leaned very hard on either one.  ECL is particularly attractive because it generates C code, so porting it to a new processor architecture is a lot easier than a native compiler.  That is potentially a big win if one's goal is long-term stability.<br>
<br>
I'm putting this out there because CCL is still at a crossroads.  Is it really worth trying to keep it alive?  Is there a bit enough user community to make it worthwhile?  What does that community want?  I would love to see CCL continue, but it's far from clear that porting it is the path of least resistance to my own personal goals.  It might be better for me to use ECL or SBCL and Emacs/Slime, or maybe try to port Hemlock directly to one of those implementations, maybe work on an ECL/Swift bridge, or something like that.<br>
<br>
I'm very much hoping that the answer will turn out to be that yes, it's worth keeping CCL alive.  But at the moment it is not clear to me, and it's particularly unclear whether just porting the compiler will be useful by itself without bringing the rest of the system along as well.<br>
<br>
Thoughts?<br>
<br>
rg<br>
<br>
</blockquote></div>