3 ms·

This is a weird phenomenon. There seems to be two conflicting philosophies in regards to reducing accidental complexity in software. The "less is more" crowd a

by dgb23 6y ago

This is a weird phenomenon. There seems to be two conflicting philosophies in regards to reducing accidental complexity in software. The "less is more" crowd adheres to avoiding and reducing feature bloat and writes lower level, often efficient, very consistent code that is easy to grok. And the "correctness by concept" crowd, with many variants thereof. Expressive type systems, functional programming, abstraction and general "higher order-ness" are dominating themes here. Languages and paradigms often land on the spectrum of these two. I wonder if these concepts can be married in some way and what we would have to give up to do so.

mumblemumble 6y ago
I'm not sure that they're all that different in the first place. At the one "less is more" place I worked, they also relied pretty heavily on abstraction and general higher-order-ness. They just had a different way of doing it: Service boundaries and protocols. Arguably the Unix philosophy is similar: A bunch of small programs that do one thing and do it well, which you can chain together with pipes. The CTO's official reason for the "less is more" philosophy was not that he didn't think that more powerful language features weren't useful, it was that sticking to less powerful features discouraged the growth of individual modules into large complicated tangles, by making it actively painful to do that. My one, somewhat guarded, criticism of that approach is that I think it may have depended critically on the company being in a position to maintain some very selective hiring practices. When you limit yourself to only hiring people who can really appreciate Chuck Moore's style, well, you've limited your hiring quite a bit. I could be convinced that the "correctness by concept" approach is less fragile and dependent on having a rigid corporate monoculture in order to work out properly.

by dgb23 6y ago

mumblemumble 6y ago

I'm not sure that they're all that different in the first place. At the one "less is more" place I worked, they also relied pretty heavily on abstraction and general higher-order-ness. They just had a different way of doing it: Service boundaries and protocols. Arguably the Unix philosophy is similar: A bunch of small programs that do one thing and do it well, which you can chain together with pipes. The CTO's official reason for the "less is more" philosophy was not that he didn't think that more powerful language features weren't useful, it was that sticking to less powerful features discouraged the growth of individual modules into large complicated tangles, by making it actively painful to do that. My one, somewhat guarded, criticism of that approach is that I think it may have depended critically on the company being in a position to maintain some very selective hiring practices. When you limit yourself to only hiring people who can really appreciate Chuck Moore's style, well, you've limited your hiring quite a bit. I could be convinced that the "correctness by concept" approach is less fragile and dependent on having a rigid corporate monoculture in order to work out properly.