In CLOS, instance remorphing considered useless in practice?

[Jean-Claude Beaudoin]

On Wed, Dec 9, 2020 at 7:13 AM Hans Hübner <hans.huebner at gmail.com> wrote:

> 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
>

Much to think about, thank you Hans
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/pro/attachments/20201209/63a40cfc/attachment.html>