mutability is the very wrong default

[Raoul Duke]

because you are unlikely to claw your way back to sanity and instead will defensively have bar = foo.copy() everywhere from what i see in the real world. 

languages that cannot help enforce deep immutability kind of suck in this day and age. or, alternatively, at least good static borrow checking. 

[David Barbour]

I prefer immutable data for most use-cases. Though, I recognize that performance continues to be an issue for its wide adoption (even with structure sharing). 

A related point that continuously annoys me is the mess of sequential data structures - lists, arrays, tuples, etc.. I'd prefer an immutable default that is reasonable for almost every use-case (double-ended queue, random access, split, append, sparse arrays, etc.), such as finger-tree ropes. Then perhaps use some form of annotation to tell the compiler to specialize the representation for certain use-cases.

On Thu, Sep 8, 2022 at 5:55 PM Raoul Duke <rao...@gmail.com> wrote:

because you are unlikely to claw your way back to sanity and instead will defensively have bar = foo.copy() everywhere from what i see in the real world. 

languages that cannot help enforce deep immutability kind of suck in this day and age. or, alternatively, at least good static borrow checking. 

--
You received this message because you are subscribed to the Google Groups "PiLuD" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pilud+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pilud/CAJ7XQb52cKuOs6eHE4cmXYY7ZTC4KjA1dawB68X5L5H_E%2BrPRw%40mail.gmail.com.

[Raoul Duke]

very much agreed re data structure. more from laziness or frustration with refactoring. there's lots of times i start with some standard collection then realize i need other features then have to have multiple collections all trying to keep in sync, etc... software engineering is intellectually bankrupt.