https://discord.com/channels/297478281278652417/297478350145060875/1018545388929691729
janet user: I think since common lisp is designed from the perspective of an individual programmer
I don't think that it was explicitly "designed from the perspective of an individual programmer". I think the goal of making a standard was to make it easier to have portable code. Now, did each individual on the committee tried to build the standard while keeping in mind the perspective of lone dev or that of a teams... I don't know.
The only thing that makes me think that it was "from the perspective of an individual programmer" is that nothing prevents you from screwing another person's work if you're both working on the same image at the same time. (Maybe there was something in old lisp machines, but there's nothing in the CL standard AFAIK).
janet user: reinvention is just baked into the culture to a degree outside of implementations which i dont think count; collaboration is kinda limited
I might agree, maybe, if we first agree on what we meant by "culture", but I won't get into that territory.
Also, I think we don't see much collaboration because there's a missing "critical mass" of CL developers. If you compare to node/npm, we see a lot of collaboration because there are a lot more people to collaborate together. I think it's a kind of survival bias: we are often made aware of the popular libraries, but I would bet that there are even more (unpopular) libraries that are just "reinvention" (still talking about npm here).
Do I make sense?
janet user: most projects are an individual making something and then sharing it with the world
I think it's true for all programming languages.
i dont think the lack of tools to manage 3rd party libraries properly helps
Here we're not talking about the CL language anymore, we're talking about the whole ecosystem of tools.
janet user: but reinvention is bound to happen in this context imo
Which context? The context of not having great tooling for dependency management?
...
janet user: well there's lots of other things that i think make it harder to grok someone's code
ein: hmm idk, i don't really see the difference to e.g. cpp or rust or w/ever
janet user: cpp this is also true imo
...
janet user: honestly i think people can overcome those hurdles
ein: <@fstamour> i'd actually be interested to hear what makes you think CL takes care of large teams working on a single piece of code if you wanna elaborate on that without like, the obvious "you can simply metaprogramm your way to large team coherence", that i agree with but isn't i think meant here
Ok, I don't actually think that CL "takes care of large teams working on a single piece of code". But I don't think that any language does either. What enables large teams (or any size of teams), IMHO, is good communication. Automated tests, conventions, docstrings, pair programming, continuous integration, code reviews, etc. are all tools that helps communication.
I think that on any project, the hardest part is always understanding the problem, the domain, the jargon. Unless you're using something stupid like brainfuck, it's never the language per se that takes the most time to understand well.