Dependencies

Every standard library of any decent language, designed by competent academics, includes everything what one might need.

It is well-understood that the basic building blocks are just values, sequences, trees and tables (in principle) and high-level, file-based IO and networking, so almost 40 years of research went into well-designed and polished standard libraries of LISP and ML famlilies of languages.

Just build your small modules on top of the standard library and if something isn’t there you most likely do not need it. Really.

Unnecessary, redundant abstractions is the root of all evil.

Reduction to the essence - to a just right, minimal set of concepts, when there is nothing more to remove, is where the real effort goes. Without this it is just a low-effort crap. A junk-food of programming.

Restricting oneself to just a few core universal data abstractions is how to retain control over complexity.

No, you don’t need that fancy module by an amateur literally who from github which has 100500 even more crappy dependencies. No, you really don’t.

When you see more than 5 dependencies in a dependency graphs beware of the low-effort crap trap.

Know when vendoring is the right thing to do.

Well, I definitely don’t want to re-implement things like Numerical libraries for scientific computing, or Mesa or OpenSSL. I want to re-use such great efforts.

Notice that there is a big difference between, say, Mesa, and some amateur crap on NPM or some low-effort Rust crate.

What one especially must avoid, like a plague, is some fancy abstract Haskell modules which implement unnecessary, redundant category-theoretic abstractions.

Yes, I have studied the theory and I know it is mostly irrelevant.

• Erlang
• Standard ML
• Haskell (what comes with GHC)
• Ocaml (base, not Core)
• Common Lisp (the CLtL2)
• MIT Scheme
• Clojure (he is right about being data-centric)
• Go (the stdlib has been ported from Plan9)
• Scala 3 (they rewrote everything)
• Python (before the async madness)