4 ms·

I wonder why do developers use CCL. I haven't work with SBCL and Lisp in general for years, but Emacs + Slime + SBCL worked very good.

jonathankoren 5y ago
I’d like to get back into lisp, but I haven’t found an environment that is as good as the AllegroCL one I used use. Everything seems to fall apart when using the debugger, or doesn’t quite have eval-just this-selection. What’s been your experience with the debugger and integrated repl?
reikonomusha 5y ago
CCL was a hugely popular implementation for a long time. One of its main strengths was extremely fast compile times, and very predictable performance/assembly. The runtime also had a lot of nice configuration options. I think its usage has declined a bit since development of CCL has slowed down.
blihp 5y ago
In addition to it being a historically popular implementation, from the MCL days, there was a period of time when SBCL was still pretty rough while CCL was mature and performant. They've swapped places IMO in the past decade or so partially due to the excellent work by the SBCL developers while CCL has been less active over the same timeframe.
TurboHaskal 5y ago
I switched from SBCL to CCL for some web services due to issues with the former's GC. Seeing how some developers greatly preferred the native Hemlock environment over Emacs, I made the switch globally without many issues. These days I use LispWorks, although I tend to separate GUI code from back-end code and make sure the latter is portable across implementations. Running tests on SBCL also catches some bugs at compile time which is nice.
thorondor83 5y ago
I used CCL recently at work. I needed to create a binary, copy it to a different machine and execute. SBCL binaries depend on a version of glibc that is not available in every Linux. Clozure CL binaries do not have that dependency, they are portable out of the box. Also, I think Clozure CL is more memory efficient than SBCL. I was running it on a low-memory cheap hosting.
pfdietz 5y ago
It can be useful to use multiple implementations just to catch lingering portability issues (with things the standard does not specify.)

jonathankoren 5y ago

I’d like to get back into lisp, but I haven’t found an environment that is as good as the AllegroCL one I used use. Everything seems to fall apart when using the debugger, or doesn’t quite have eval-just this-selection. What’s been your experience with the debugger and integrated repl?

reikonomusha 5y ago

CCL was a hugely popular implementation for a long time. One of its main strengths was extremely fast compile times, and very predictable performance/assembly. The runtime also had a lot of nice configuration options. I think its usage has declined a bit since development of CCL has slowed down.

blihp 5y ago

In addition to it being a historically popular implementation, from the MCL days, there was a period of time when SBCL was still pretty rough while CCL was mature and performant. They've swapped places IMO in the past decade or so partially due to the excellent work by the SBCL developers while CCL has been less active over the same timeframe.

TurboHaskal 5y ago

I switched from SBCL to CCL for some web services due to issues with the former's GC. Seeing how some developers greatly preferred the native Hemlock environment over Emacs, I made the switch globally without many issues. These days I use LispWorks, although I tend to separate GUI code from back-end code and make sure the latter is portable across implementations. Running tests on SBCL also catches some bugs at compile time which is nice.

thorondor83 5y ago

I used CCL recently at work. I needed to create a binary, copy it to a different machine and execute. SBCL binaries depend on a version of glibc that is not available in every Linux. Clozure CL binaries do not have that dependency, they are portable out of the box. Also, I think Clozure CL is more memory efficient than SBCL. I was running it on a low-memory cheap hosting.

pfdietz 5y ago

It can be useful to use multiple implementations just to catch lingering portability issues (with things the standard does not specify.)