Totally agree. I think the biggest and most important things a language designer chooses is what to disallow. For instance, private/package/public etc is one small example of an imposed restriction which makes it easier to reason about changing a large project because if e.g. something is private then you know it's okay and probably easy to refactor. The self-imposed restrictions save you mental effort later. I also love lisps but am a Clojure fan. This is because in Clojure, 90+% of the code is static functions operating on immutable data. That makes it extremely easy to reason about in the large. Those two restrictions are big and impose a lot of structure, but man I can tear around the codebase with a machete because there are so many things that code /can't do/. Also, testing is boneheaded simple because everything is just parameters in to those static functions and assert on the values coming out. I don't have to do some arduous object construction with all these factories if I need to mock anything, I can use "with-redefs" to statically swap function definitions too, which is clean and very easy to reason about. Choosing the things you mr language disallows is one of the most important things you can do to reduce cognitive load.
When the code needs to do something that it can't do, there is a massive cognitive load associated with figuring out how to do something approximating it. When the language or a framework is associated with lots of "how do I X" questions, the answers to which are all "completely rethink your program", that is evidence that the language/framework is not reducing cognitive load.
I'm optimizing for a large, complex corporate projects, not beginners on toy projects. And I would also add that if you search for "how do you do X in Y language", you'll probably find every combination of a lot of languages so I hardly think that is grounds to dismiss Clojure. More and more languages seem to be embracing immutability and static functions are everywhere. The two are just utilized well and believe me, if you need to refactor something then you are so much more at liberty which is certainly a high bar IMHO.
>I'm optimizing for a large, complex corporate projects, not beginners on toy projects.
There's nothing about large, complex corporate projects that demands that languages impose arbitrary restrictions on code, except the fact that so many corporations insist on hiring incompetent fools as programmers, often to save money in the short run by expanding the potential labor pool. They call them "guardrails", but a better metaphor would be the playpen. If you hire only competent developers, then you don't need to put them in a playpen.
>And I would also add that if you search for "how do you do X in Y language", you'll probably find every combination of a lot of languages so I hardly think that is grounds to dismiss Clojure.
Well yeah, it's pretty much the norm in popular programming languages to make certain things impossible. And programming is driven by fads, so we're going to see more and more of this until it finally goes out of fashion one day and some other fad comes along.
Please elaborate what programming language you think isn't a fad and isn't a playpen and why. Restrictions on languages IMHO clearly narrow what you have to think about other code doing. Whether it's marking a field "const" in C++ or having the borrow checker in Rust or having private fields in Java or immutability in Clojure, all those things make it easier to know what a large system of code /cannot/ do, and that makes it easier to maintain. That has nothing to do with people other than it might be you fighting years of code that you wrote yourself.
