• Wednesday, 03/15/2023 ** 23:10 Coming back around to having a lot of trouble with javascript and build systems.

I’m learning more about the social aspects of ecosystems. In javascript’s case, a single technical decision - to assume that transitive dependencies can be compiled in the same way that dependencies are, and to stay off of a clear decision to standardize a build process or module configuration for a long time.

Maybe staying away from administering standards is good, but this happens time and time again; I have personal experience with Nix flakes friction, Rust’s erorr type / nighlies, Haskell’s mess of a ‘language extensions’ idea, and so forth.

When do you want to institute a standard? How do you know where to start? Where?

Friction happens when interfaces are expected to be opaque, but aren’t (or, conversely, are transparent). Build system errors are akin to internal compiler errors - they aren’t problems in your code or even that of the upstream library, but somewhere in the processing pipeline to assemble everything. Build systems in javascript leak abstraction boundaries.

Library programmers have to build for every build system that end users could use down the line - and if I’m contributing in 2010, I have no way to conceive what people will want in 2020 something or how those standards might change!

The nix problem is one of a standard with a lack of appropriate tooling. The proposal was made and accepted by a minority of the community, then immediately implemented in ‘production’ by major Nix characters - making it industrial for some, but without the practice, backing or documentation to make this stuff broadly adoptable. Nix should be experimental - but instead of making it an external, experimental feature, it should have been implemented outside of the core - not strongarmed into the internals. Sure, flakes were hidden behind a flag - but half of the nix guides werre recommending flipping that flag without elaboration beyond pointing to the Tweag blog posts. Flakes are good; the launch was not and the community is still fragmented today.

Rust? They chose not to administer a standard that they knew they would need. The right decision for the Error trait was to provide a default, easily extensible error system that functions generically. A concrete Error was a bad move, and fragmented the ecosystem around all of these specific errors that people wanted but weren’t supported by Error. Special casing would have been fine here - unnecessary but fine. The community deserved to be able to modify their system in ways that Rust’s opaqueness doesn’t tolerate.

Common Lisp runs the other way. Everything is explicitly modifiable, and that means you don’t know what system you’re working with. You can start from a tight core, but the core is a mess of hacks that have been accumulated, and none of them were built for the 21st century. Haskell’s the same way - I dare you to walk into a production codebase, obfuscate the language extensions, and try to figure out what’s going on. Too much could be going on on the other side of the interface, and the process of finding out is a mess. This is reasonable - Haskell was built for language experimentation, and Common Lisp was built to be a modifiable foundation - and fast.

I’ve had trouble with all of these because I’ve expected software systems that ‘just work’ and follow the same rules - heterogenous systems assembled with lots of simple, opinionated tools that serve their roles well. Type systems reach if not managed correctly. My current interface take is that users should be able to express ideas however they’d like within the rules of the system, but they shouldn’t have to worry about a ‘meta level’ like a type system right away; types are useful to help document and solidify information across interfaces. I don’t want to think about types; I want to think about values and data that will never be properly represented. Most Haskellers and Rustaceans will admit that over-perscription of representation - narrowing types of strings and numbers to minutiae - is a sin because it prevents iteration entirely. Maybe for system services, types are good glue - but for anything with a UI, your feedback is primarily delivered with visuals - not through any sort of type system. We don’t need stronger types - we need better data visualizations - because when answers will inevitably occur, we want the best tools imaginable for navigating the system to track them down.