I've used ABCL very happily as a high-level way to script the JVM, and also as a good way to explore what's going on in a big Java program, using the REPL.

But for the AI planner I maintain and develop (GitHub.com/shop-planner), ABCL simply won't function: it's wildly too slow compared with SBCL, Allegro, and CCL. I can't get it to run the test suite (ECL can't do it, either).

Also, I suspect that the inability to do tail call optimization means that idiomatic CL code behaves very poorly on ABCL (which is the fault of the JVM, not ABCL itself).

I wouldn't recommend ABCL as other than a tool to work with artifacts that already live on the JVM. As a "primary" CL it just does not perform well enough.

On 3 Dec 2020, at 8:55, Alessio Stalla wrote:

Perhaps this will change with a future JVM with Value Types and with a future ABCL making use of them, but at the moment, that's the sad story.

On Thu, 3 Dec 2020 at 15:51, Pascal Costanza <pc@p-cos.net> wrote:
We tested an implementation in Java, and the memory footprint of the JVM is huge. Where C++, Common Lisp, and Go could comfortably run in below 256 GB RAM, Java needed more like 350-400 GB RAM. That was not a good tradeoff. I don’t expect an implementation in ABCL to solve this (which is not ABCL’s problem, but a problem of the JVM).

Pascal

> On 3 Dec 2020, at 14:47, Manfred Bergmann <manfred.bergmann@me.com> wrote:
>
>> This was primarily for the lack of good parallel, concurrent garbage collectors in Common Lisp implementations.
>
> ABCL on the JVM works pretty good these days.
> It’s not as fast as SBCL, but much more robust from a runtime (and GC) perspective.
>
>
> Manfred
>
>
>> Am 03.12.2020 um 13:57 schrieb Pascal Costanza <pc@p-cos.net>:
>>
>> This was primarily for the lack of good parallel, concurrent garbage collectors in Common Lisp implementations. The CL version of elPrep was actually still a tad faster than any of the C++, Go, or Java versions, but we had to work hard to avoid long GC pauses. elPrep allocates a lot of memory, and the pause time hurts a lot. We solved this by, basically, disabling the garbage collector, and reusing memory manually as much as possible, which turned the program into almost a manually memory-managed affair.
>>
>> Manual memory management became a huge burden because we wanted to add more and more components to the software, and then it becomes almost impossible to predict object lifetimes.
>>
>> We evaluated Go and Java for their concurrent, parallel GCs, and C++ for its reference counting. Interestingly, reference counting is often described as more efficient than GC, but in our case that’s not true: Because there is a huge object graph at some stage that needs to be deallocated, reference counting incurs more or less the same pause that a non-concurrent GC does. That’s why we don’t expect Rust to fare better here either.
>>
>> Again, we’re still prototyping in Common Lisp, which is a huge win, because this makes us much more productive.
>>
>> Pascal
>>
>>> On 3 Dec 2020, at 12:16, Svante Carl v. Erichsen <svante.v.erichsen@web.de> wrote:
>>>
>>> Hi!
>>>
>>> I vaguely remember having read that you do that.  I'm still wondering
>>> why, though.  I guess that you wrote about it, but I can't find it right
>>> now.
>>>
>>> So, if it's not because Common Lisp is not seen as “production ready”,
>>> why rewrite instead of just adding the production parts (I guess
>>> hardening, monitoring, logging, documentation etc.)?
>>>
>>> Yours aye
>>>
>>> Svante
>>>
>>>
>>> Pascal Costanza writes:
>>>
>>>> In my opinion, prototyping in Common Lisp, and then translating to a
>>>> different programming language for creating the final product, is a
>>>> perfectly valid professional use of Common Lisp. It’s useful to know
>>>> which programming languages may be good targets for such an approach.
>>>>
>>>> This is, of course, not ideal, because this can easily be
>>>> misunderstood as a statement that Common Lisp is not fit for
>>>> purpose. However, I don’t see it that way, and you cannot control
>>>> people’s perceptions.
>>>>
>>>> In our particular case, our manager is on board with this approach,
>>>> and this allows us to pay for regular licenses for LispWorks. The
>>>> approach works really well for us.
>>>>
>>>> Pascal
>>>>
>>>> Sent from my iPad
>>>>
>>>>> On 3 Dec 2020, at 05:29, Dave Cooper <david.cooper@genworks.com> wrote:
>>>>>
>>>>> 
>>>>>
>>>>>> Where else do Common Lispers go to talk shop, whether CL or something else?
>>>>>
>>>>>
>>>>> To me, Common Lispers "talking shop" by definition means talking about CL or related topics, not an open-ended "something else." I would turn that question around and ask "where else do Common Lispers go for unapologetic mutual support for their chosen or imposed computing platform, which is Common Lisp?"  If groups such as this mailing list become diluted with hand wringing, naysaying, and negativity, then you tell me Tim, where do actual Common Lispers go?
>>>>>
>>>>>
>>>>>> CL is very good but it is not perfect.  Debating the relative merits of
>>>>>> various languages can lead to cross-pollination of ideas.  It appears that
>>>>>> most innovation is happening elsewhere, and I hope this community can
>>>>>> bring the best of CL into a worthy successor, whatever it may be called.
>>>>>>
>>>>>
>>>>> If "most innovation is happening elsewhere" then those of us who have the propensity to look into other languages can serve the community here by reporting back the cool things they find and discussing how we may or may not be able to co-opt such things into CL. If such is the perspective and purpose of "debating the merits of various languages," then indeed, such debate can result in productive cross-pollination, and this is needed and wanted.
>>>>>
>>>>> If the intention and focus is instead to sing the praises of other environments in order to seek fellow converts or validation for converting, and doing this while specifically targeting a group set up to support "professional common lispers," then I consider such efforts to be unhelpful in the context of this group and I would invite you to take such discussions into the forums of those other environments or into some general language discussion forums.
>>>>>
>>>>> Understand that not all of us have the "luxury" on the one hand, nor the desire on the other hand, to chase the dragon of the latest cool thing, and we look to groups such as this one specifically to support our crusty old entrenched mentality -- and to improve our environment as best we can, understanding the inherent limitations that exist. This is the life we have chosen.
>>>>>
>>>>>
>>>
>>>
>>
>> --
>> Pascal Costanza
>>
>>
>>
>
>

--
Pascal Costanza





Robert P. Goldman
Research Fellow
Smart Information Flow Technologies (d/b/a SIFT, LLC)

319 N. First Ave., Suite 400
Minneapolis, MN 55401

Voice: (612) 326-3934
Email: rpgoldman@SIFT.net