[please refute, not just downvote] Just because something can be done doesn't mean it should be done (maybe it should be done, but for some other reason). I'm

[please refute, not just downvote] Just because something can be done doesn't mean it should be done (maybe it should be done, but for some other reason). I'm suggesting that barriers to modifying systems have had an accidental benefit of favouring standardization. The basic problem is that it's hard to create systems (APIs, generalization, documentation, test-cases, integration with everything else). Brooks claims it's 9 times as much effort as making something that "works for me". If you can't amortise that over many users, it's usually not worth doing the job properly. But if it's just for you, you don't need all that polish, right? Well, no. If you are standing on the shoulders of giants, it's really helpful if those giants are stable, function as you expect, interact correctly with other tools, and have clear documentation for when you've forgotten the details (writing it yourself doesn't make your memory perfect). SOTSOG is really important for building complex systems, because it enables you to push down details to a lower level of abstraction, so you have less clutter to deal with. It's getting the abstractions right that is so difficult (we've all seen it done wrong). There are huge advantages to using standardized systems, that have been improved, tested, documented etc by others. If you want to do something different, it's very helpful if you can start with standardized components around the new part, so you can just concentrate on the interesting stuff, and not need to build the whole world from scratch. Of course, the existing stuff is not perfect - the question is whether it's worth it for you to spend the time needed to make something better. Some issues in assessing this argument: These are ideas have been around for a long time, but haven't taken off. Highly modifiable systems like lisp, despite having clever and devoted users, lack the standardized libraries of less flexible languages like Java. But there is one kind of area where such systems are absolutely brilliant - exploration at the systems level. Many (most?) programming language ideas have been developed in lisp, even though did not become popular in that form, because lisp is great for language exploration, but not for standardization. Similarly, an OS that can be modified on the fly, is great for exploring OS ideas. You can iterate quickly, see the results and so on. Of course, it seems possible that one could have it both ways - a highly flexible system that also had standardized components. But that doesn't seem to happen. Flexibility and standardization are natural enemies, both in differences in the tools that support them... and the kinds of people who use those tools. BTW: There's a middle way. Create tools that can be standardized on. i.e. libraries, frameworks, engines, DSLs. Light table could be perfect for that... but people who use it may want to make tools that are just as flexible as light table, and so don't support standardization.