> But programmers, as a species, have gotten acculturated to salt mines as a natural habitat. They will think nothing of it.<p>Hilarious and I wholeheartedly agree with the elitist sentiment.<p>Every programmer should treat themselves to some dabbling with a Racket #lang at some point, if only for the great documentation. It’s a beautiful lisp dialect with quite a few weird twists. Wholesome and chock-full of <i>human</i> ingenuity.<p>I would add that there probably is an economic aspect to it as well here.<p>Programmers do generally love to solve problems - doesn’t matter if they are the actual root cause of much incidental complexity themselves - and they also love to get paid well for it.<p>React based SPAs, distributed systems with Kubernetes, etc all treasure troves of endless solutions to endless problems which need lots of highly skilled peole.<p>If you think about it from a worker’s perspective there is actually not much wrong with that.<p>Indeed, inferior is better for many.
There is another way this is true: any directly useful core feature in a language exposes a weakness in the language design. If it could have been coded as a library feature, because the language was expressive enough to enable that, there would have been no need for the finished core language feature.<p>But the feature might not actually be in the standard library for your actually-powerful language, yet.
There's a big assumption underlying this article: that it's even <i>possible</i> to make a language or tool so great that it suffers from success in the way the describes, where there's no need for communities built around the system because it's already perfect. I can't think of a single system that has failed this way. Nothing's perfect, and if the tool is good people will come together around it and form a community.
As someone who both works as a professional dev, and someone who's tried to used Racket to actually make something, I was at first triggered by this.. Then came to the conclusion that it must be, that my inferior mind needs the inferior languages, for in Racket, I did not achieve my goal.<p>The rest of the articles reads a bit like someone being salty because their favorite language is not good enough to achieve widespread adoption and so they must conclude that the fault lies not with their language but with any other language that actually has this side-effect of enabling their users to get things done(tm) (which is of course of no importance to the intellectual programmer, as opposed to us mere grunts xD)
> Every third-party “tool” is actually a weakness: it’s doing something that either didn’t need to have been done at all, or could have been done better in the first place.<p>That's a rather absurd proposition. The number of problems a programming language can be applied to is infinite, and span virtually all domains of knowledge. A core dev team likely isn't even capable of making every necessary tool, the idea that they would always make the optimal implementation is laughable. And of course every user will have a different definition of what is necessary.<p>The key to creating a great community is not to build lots of broken things to fix, but to build a strong foundation that makes building easy. A language can be lacking many important and useful features but so long as it has well thought out standards and a commonly understood vision, the easiest and simplest way to extend its capability is to remain consistent with other language features. These consistent third party tools make the language more widely applicable and easier to further extend.
I remember having a similarly contrarian idea, about presenting partly broken/wrong things to students as an invitation (or unconscious "hook") to participate and solve/fix it. I think it was in the context of learning/teaching electronics, starting with a simple example like a lightbulb that doesn't turn on when you flip the switch.<p>It's like that saying, if you want people to answer your question, first post the wrong answer and they won't be able to help themselves but to point you in the right direction.
That's... certainly one way to create a community, but not the one I'd go for.<p>The other way to make a community is to have things "just work" as much as possible, and become a standard to the point where only masochists commonly use anything else.
In the early days of the Apache Incubator, Stefano Mazocchi pointed out that what works to seed communities is good ideas and bad code - the other three combinations don't work.
Website doesn't really work on mobile, unfortunately. The text doesn't match the screen size and is padded to the right by a bunch of empty space.