You have yet to see the mess determined individuals can produce with Clojure 🙂

No I don’t 🙂

OTOH working in Clojure has repeatedly let me go back to code I wrote 6+ months ago, and even though I don’t recognize a single paren of it, I can still figure out what it’s trying to do. I can’t say the same for Java, PHP, Perl, VB, C#, C++, etc.

I'm pretty sure that any programming language lets you create a mess, unless it is a toy language that is so restrictive it doesn't let you do useful things.

but I'm also pretty sure that some languages/ecosystems positively encourage varying styles of implementation that make it more difficult to reuse code across those styles, e.g. C++ seems to have so many bells and whistles, that everyone using it in production picks a subset they allow in their code base, but that subset can vary across projects.

@U06CM8C3V you sir get a gold star. i 100% agree that i can return to clojure code after having offloaded it from brain rather entirely and still make sense of it with relative swiftness and ease. other languages, unless i went HAM with the commenting, it's gonna be a bloodbath. i tell younger coders to "stay kind to your future self" and "be kind to your future self" and if they are not using clojure to comment heavily 😉

@U0CMVHBL2 have you seen the beautiful list of banned c++ functions at github (for code used internally at the company) ?

(in making Github itself, if that was confusing / not clear)

https://github.com/git/git/blob/master/banned.h

😄

@sova I had not, but looking at it, it is quite short and mostly seems to include things within the standard C library that are known to be common sources of buffer overrun bugs in C programs, too.

I'm pretty sure when I last worked at Cisco on a big C code base, they had lint tools that flagged occurrences of most or all of that short list.

That has little implication on the differences between the number of bells and whistles that the C and C++ languages have relative to each other.

You can easily return to Clojure you wrote. I have had the misfortune of inheriting a relatively old code base which was written under pressure by people who were sometimes new to the language. Two years and I still find surprises and horrors

The single-dev or small team story for Clojure is excellent, a larger context requires an iron will and a certain degree of tyranny if I'm being honest

Maybe tyranny is too harsh a term, but you need good standards and keep to them

Is there a language where that’s not the case, though? Sincere question — the largest team I’ve ever worked in had three developers, I think.

I’ve seen reports indicating that larger teams is where Clojure’s lack of static types really starts hurting. I can imagine how that might be, but I’m also curious about whether there’s a way to solve that without using another language.

I guess the rigidity of static type systems and interfaces, while a big bummer, allows you to at least create clear boundaries between things which can't be broken. With Clojure, and dynamic languages in general you're freer to make a mess. Also Clojure is very unopinionated when it comes to code and project structure

I think a way to ameliorate the static typing issue may be a CI check that every function is spec-ed, try to finagle your way around that one

Nothing replaces communication between developers on a common project. Static types, while they can provide some level of protection for some kinds of mistakes, can also become a form of "developer molasses" between teams, and/or finding workarounds to jam new information into existing spots in funky ways that aren't what you would do if you were writing the code from scratch, e.g. pass two 16-bit integers in a 32-bit integer.

> I think a way to ameliorate the static typing issue may be a CI check that every function is spec-ed, try to finagle your way around that one For me a good place to draw the line is APIs. APIs should be spec-ed, implementations need not This way one gets 80% of the benefit with 20% of the effort

Yeah, overspecification is a real danger. In one of the projects I work on, almost everything is speced, and it's a real pain in the ass.