[upghost]

It's actually more like "just use Haskell".

Having written one of these[1] a decade ago and inflicting it (with the best of intentions) upon production code in anger, I can tell you this often leads to completely unmaintainable code. It is impossible to predict the effect of changing a method, tracing a method, debugging a method (where do I put the breakpoint??).

The code reads beautifully though. Pray you never have to change it.

The reason I say "just use haskell" instead of lisp is bc lisp generics suffer from this same problem.

Btw if anyone has a solution to this "generic/multidispatch maintainability in a dynamically typed language" problem I would love to hear it.

[1]: https://github.com/jjtolton/naga/blob/master/naga/tools.py

[Fr0styMatt88]

I’ve been doing the once-every-few-years deep dive into Smalltalk that I tend to do out of curiosity and this kind of question is one that always comes up for me. The answer there seems to be “the whole environment and philosophy is geared to work that way”; a dynamic language needs a lot of tooling support and interactivity.

[igouy]

> this kind of question

Which kind-of question? "where do I put the breakpoint??"

[Fr0styMatt88]

No specifically the question of how do you write maintainable code with generic multi-dispatch and highly dynamic languages.

I like Python, but I like static typing too because there’s just less to think about and when I have to learn a new codebase there’s a lot of assumptions I can lean on about how things work; this saves time.

I like the idea of Smalltalk and when you watch Alan Kay or Dan Ingalls talk about it, they make total sense and you have Pharo and Squeak to back it up as in “yes, you can build large systems with this idea”.

But I don’t think you could program Smalltalk and have it be maintainable without everything else the environment brings. Being inside the environment with your objects. The total different approach of sending a message an object doesn’t understand, then having the debugger pop up and then you just implementing that message right there. That’s just an utterly different workflow.

I like the idea in ‘late binding of all things’ and I think the approach of writing a DSL for your problem and then having to write far less code to solve your problem is great. But the objection is then always “okay but what about when someone else has to work with that code”.

I guess what I’m trying to say is, the more dynamic your language is, the more support you need from your tooling to ease the cognitive load while you program, simply because the state-space of things you can do is bigger and not being restricted by types, etc.

[igouy]

Tangentially, you might find the abandoned Nice programming language interesting.

https://gallium.inria.fr/~remy/poly/mot/10/nice/web/language...

    ----

> … but what about when someone else has to work with that code.

Someone else has had to work with that code since before Smalltalk escaped Xerox PARC.

1984 "Smalltalk-80 The Interactive Programming Environment" page 500

"At the outset of a project involving two or more programmers: Do assign a member of the team to be the version manager. … The responsibilities of the version manager consist of collecting and cataloging code files submitted by all members of the team, periodically building a new system image incorporating all submitted code files, and releasing the image for use by the team. The version manager stores the current release and all code files for that release in a central place, allowing team members read access, and disallowing write access for anyone except the version manager."

https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr...

Later "ENVY/Developer":

https://archive.esug.org/HistoricalDocuments/TheSmalltalkRep...