I had a dream last night that Java came out with a new packaging spec that involved encoding your metadata as a crystal that you then dissolved in a liquid, and somehow my first thought was, “That seems convoluted, but who are we (Pythonistas) to judge?”
@pganssle funny that ‘crystal’ and ‘liquid’ are also languages
🧵👇 @pganssle @faassen This may make you chuckle:
🙶To Over or Under Engineer?🙷 https://www.bahmanm.com/2016/07/to-over-or-under-engineer.html
1/3
@pganssle @faassen I've years of experience w/ #Java /#Scala & am often baffled by the complexity of solutions to simple problems.
IMO b/c those languages' approach to modelling is creating/extending more and more abstractions both veritcally (deep hierarchies) and horizontally (too granular units.)
And that's why you frequently see pretty complicated/bloated solutions written in those languages.
2/3
@pganssle @faassen Contrast that w/ #Lisp, #Python, #Ruby & #Perl which offer different ways of managing abstractions, namely macros & meta-programming.
They let you shrink the depth of the hierarchies by using those means.
And b/c of that the culture is generally against too granular abstractions.
―
⚠ In recent years, I've seen Python code bases inclining towards the Java approach (a la #Zope) and that is quite frightening 😑
3/3
Zope is now ancient history, but I will note the original Zope from 1998 had a lot of subclasses in its design, whereas the newer Zope 3 project from the early 2000s massively favored composition over inheritance. Glued together by XML config file.
Whether that was more or less like Java is left as an exercise for the reader. I will just say these things are full of subtleties.
I like a lot about Django REST framework but the subclass based design is decidedly not one of them. You can override
behavior, yes, but readoning about it is too hard.
In Rust I don't have subclasses at all and I rarely miss them. Even wanting dynamic dispatch is uncommon, though I think that's also due to less experience with the feature.
@faassen @pganssle
RE subclasss:
Agreed. Though I've worked w/ talented people whose handles the cognitive load of a code base better if it is organised in that way.
―
There are many (infinite?) ways to solve the modeling problem and each language represents just one (sometimes more, like Scala or Python.)
That's why there are many languages out there: to cater to different brains and different ways of thinking.
My 2¢
@bahmanm @faassen @pganssle Corollary: #programming languages that fit the lowest common denominator of brains “win” via network effect
@mjgardner @bahmanm @pganssle but programming languages that attract creative, curious minds may benefit more from their contributions.
...and many of those contribs find their way back into the more popular langs.
―
Take #Lisp for example.
Though never a popular one, it inspired many & coined *concepts* that are nowadays widely used:
▸ Dynamic typing
▸ Garbage collection
▸ Meta-programming
▸ Macros
▸ Multi-paradigm lang
▸ Bottom-to-top programing
▸ REPL
...
―
Bottom line is, diversity of the lang landscape leads to the inclusion of more brains which eventually leads to "better" langs.
Lisp is also one of the first programming languages, so that may also help explain its influence.
If a language grows complexity by adding more features it may lose traction.
The web of influence is complex. In all of it we have to explain not just the popularity of languages that fit your brain but also the popularity of C++.
> grows complexity
💯 There's a fine line between being feature-rich & overflowing the programmer's brain w/ cognitive load
> the popularity of C++
IMHO
▸ No real rivals until recent years: #dlang, #nimlang, #ziglang & #rustlang
▸ Sameness: a C programmer can hit the ground running & learn C++ only as they go
▸ Massive existing C codebases which could be gradually ported to C++
Rivals like Rust also have significant complexity. What I'm trying to get it that programmers are willing to put up with more complexity if there's a pay-off.
TypeScript has gotten popular, even though people could have stuck to JS and avoided a significant increase in complexity. People use it because they get other benefits.
Coming next year:
PEP 818: Biphasic physical storage of package metadata
Replaces: 517