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 <p...@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.bergm...@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 <p...@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.erich...@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.coo...@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: rpgold...@sift.net