|
|
|
|
|
by wonderzombie
5021 days ago
|
|
It's worth reading http://commandcenter.blogspot.com/2012/06/less-is-exponentia... to get some idea of the motivation behind including less. If you believe that our software systems are increasingly complex and that some aspect of the problems we're solving are essentially complex, then the strongest path towards simplicity lies in minimizing complexity incidental to the problems we're solving. One facet of programming which routinely introduces complexity is our tools, particularly our programming languages. I believe both Rob Pike (and the Go authors) and Rich Hickey are both motivated in part by this impulse or a variation on it. They chose very different ways of addressing the problem, but Clojure and Go are a lot more similar than you'd think. |
|
That is true, but I'm not sure the correlation you seem to be suggesting here — that complex tools breed complex programs — is realistic.
A lot of the time, complexity can either live in your tools or in your program. For example, garbage collection requires a more complicated toolset than manual memory management, but in return it removes the complexity of memory management from your code. Similarly, ASM is simpler than C, and Whitespace is simpler than Python, but most people will agree that a program written in the latter tends to be simpler than the same program written in the former.