I have never heard of Rich Hickey before this article but certainly, know of his language and therefore the respect he is due. I believe it is important as a language designer to have very strong opinions on very tiny aspects of being a professional software developer, but I think it would be a mistake to follow anyone into such rabbit holes. I would want a software developer to learn how to design complex systems at a high level, encounter real-world problems during implementation, and then-and-only-then examine the options available for addressing low-level code concerns. The inverse approach will most likely lead to feelings of being overwhelmed and confused, and most likely missing the point inventors such as Hicky make.
That makes a lot of sense - from what I've read form him, Clojure seems like it was almost a knee-jerk reaction from a career Java engineer who was losing his mind, and wanted something that addresses his own perceived shortcomings.
I have not yet written enough of anything to lose my mind about it. Context is important.
Maybe this isn't what you meant, but to check, I looked up the dictionary of "knee-jerk" to find it defined as "automatic and unthinking". I think Rich Hickey's approach to Clojure has been anything but that. Deliberate, careful, nuanced, yes. Always fully explained in an instant to everyone who goes looking for answer to why Clojure is the way it is? Definitely not.
I see a theme in all of his work as how to avoid complexity, especially unnecessary complexity that many aspects of software development create.
Absolutely, you're completely right. I more meant as a reaction borne from desperation to make what he felt was an unworkable environment into a workable one, but you're right, it was a poorly chosen phrase for the resultant product.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.