4 ms·
In my experience, the biggest obstructions to modularity are the "unknown unknowns". I can't tell you how many times I've been trying to set up some software w
by Xcelerate 10y ago
In my experience, the biggest obstructions to modularity are the "unknown unknowns". I can't tell you how many times I've been trying to set up some software where it turns out the installation was looking for file ABC in directory XYZ even though the documentation wasn't up to date and listed directory EFG (or nothing at all). Also, environment variables (i.e., global variables) are a pain and should be eliminated altogether. What would replace them? I'm not sure, but any random idea has got to be an improvement of some sort over the current system.
Docker alleviates the environment hell problem somewhat, so it's easy to set up a bunch of contained microservices that aren't going to fall apart when the global environment changes.
We need more research into the complexity of programming patterns. The same patterns and anti-patterns keep popping up under different names in slightly different forms.
- Nomentatus 10y agoSpeaking of random ideas: dump the globals into functions (one function per global) - that's right a dumb single-variable function. You can't monitor or pop an assert on a variable, but you can put slap asserts inside a stub function, etc. Plus you know a function ain't local. Globals are such poison that the minor inefficiency created by converting a few globals to functions is usually meaningless. I begin to think that we need a richer vocabulary to address "complexity." To analyse it into various forms, (some of which are likely to be beneficial.) Separating code into lumps means more lumps; but fewer dependencies, more known absence of dependency... We keep using one word "complexity" to point to various things. Distinguishing between Complex(opposite of 'simple') and 'complicated' (opposite of 'easy') is a start I suppose, but I can't help thinking there are more careful distinctions that could be made.