4 ms·
The other side of the coin for something like Clojure (lisps, really) allow tiny teams to manage large domains - so the team can't scale to a large number of pr
by roenxi 3y ago
The other side of the coin for something like Clojure (lisps, really) allow tiny teams to manage large domains - so the team can't scale to a large number of programmers, but a 5-man army is viable because that is a small enough team to curate the individuals members for quality and they get a lot done.
But the author's rankings look extremely reasonable. All companies have management problems and some languages cope better with that than others. Another way of interpreting this is "What costs does the language impose on programmers doing something novel" - usually novel is a bad sign for long term success.
- rodrigobellusci 3y ago> allow tiny teams to manage large domains Is that a virtue of the language (Clojure/lisp/any other) or a virtue of the 5 experienced programmers? I ask because I’ve never delved deep into any language of the lisp family but I have seen that small experienced teams tend to produce good work regardless of the stack they choose. My guess is the recipe for good outcomes is: experience with the chosen stack + experience working together + small-ish team.
- roenxi 3y agoThe technical influences of language are, theoretically, very small. As far as I can tell anything can be built in anything (evidenced by the remarkable number of great applications written in JavaScript of all languages). But Clojure is a language that supports [0] that sort of team better than Java or Python (I won't say Rust or Go because it isn't really a first choice for systems programming). The Clojure community also has a cultural expectation that teams will be small and highly skilled, for obvious reasons. [0] I don't see how this sort of statement could ever be anything other than opinion, so I won't try to justify the assertion.