In CLOS, instance remorphing considered useless in practice?

[Hans Hübner]

Am Mi., 9. Dez. 2020 um 11:03 Uhr schrieb Jean-Claude Beaudoin <
jean.claude.beaudoin at gmail.com>:

> On Wed, Dec 9, 2020 at 4:36 AM Hans Hübner <hans.huebner at gmail.com> wrote:
>
>> I like using CL when I know that I don't need scalability and when I know
>> that I'll be the only developer of the program that I'm writing.  Under
>> these circumstances, I enjoy it very much because it caters for this
>> setting.
>>
> And I'd like it with scalability too, how about that?  The "only
> developer" part I simply do not get. What is the deal with the solitary
> state here?
>

My personal conclusion, having used Lisp for many years, is that it caters
very well for the individual.  After all, REPL based, exploratory
programming is all about the interaction of an individual with the
machine.  This nature of Lisp goes far, and then Lisp itself wants to be
explored.  As an individual programmer, Lisp provides me not only with a
set of tooling that I know how to use, it also provides me with its own
exploratory space:  There is this set of Lisp features that I have not
found a good use in the past, but that I would like to try out in the
future.  Now, this might not be that far from other large languages, yet
due to the fact that Lisp carries a lot of baggage from older Lisp
dialects, a lot of these seldom-used features would not have made it into a
new language, had it not been to appease different parts of the language
committee who had their own baggage to carry over into the new, unified
Common Lisp dialect.

As an example, I would like to point at symbol plists, which were integral
to earlier LISPs lacking better, dictionary-like data structures.  They
sleep dormant in the spec, but rest assured:  If Common Lisp is your
community, you will eventually run into someone who insists that symbol
plists are great and uses them all over.  Looking at you, Ken.

Now, this is all good and fine for the solitary experience of having a tool
that you can both use to create solutions and that is in itself something
that you can endlessly explore.  It is less useful in the world of
industrial software development, where maintainability of systems written
by other people is one of the key properties that should be supported by
the implementation language.  While this usually makes languages boring and
often causes features that "one" would "like" to to have be missing, it
also is a property that makes one language successful and the other
language less so.

This is also where scalability comes into play, and that word certainly
needs to be qualified before it can be discussed.  If scalability simply
describes the raw size of the problem that can be addressed with a tool,
then there are limits to what a given language can do based on its inherent
support for threads that execute in parallel.  Parallelism is something
that requires proper abstractions.  Some say that these can be just on the
library level, but my experience tells me a different story.  I find it
difficult to create robust parallel solutions in languages like Lisp, as
the language itself assumes a single thread of control in how it makes
variable bindings accessible and how information is passed between
invocations of functions by reference.

If scalability is about the number of people that one can bring into a team
that develops a single system, Common Lisp is not a particular nice
environment either.  Due to its size, age and heritage, every program that
is written in it basically subsets the language and, worse, often also
extends it because the subset was found to be insufficient and extending
the language is easy.  The result is that unless a new person has already
mastered a lot of Common Lisp, they will usually have a hard time finding
their way around in a new system.

This is not to say that the Common Lisp is the only language with that
problem - It is a property of many old languages.  I would still argue that
CL is particularly affected because it was an amalgam of several languages
to begin with, because it had very strict performance goals in the
beginning and because the model of development that it always catered for
is not that of a team, but that of a person interacting with a long-running
program.

-Hans

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/pro/attachments/20201209/2783d15a/attachment.html>