> But programmers, as a species, have gotten acculturated to salt mines as a natural habitat. They will think nothing of it.
Hilarious and I wholeheartedly agree with the elitist sentiment.
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 human ingenuity.
I would add that there probably is an economic aspect to it as well here.
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.
React based SPAs, distributed systems with Kubernetes, etc all treasure troves of endless solutions to endless problems which need lots of highly skilled peole.
If you think about it from a worker’s perspective there is actually not much wrong with that.
I usually recommend Smalltalk for similar reasons. When I was running a ST users group every so often we'd get people trying to sell us on various functional languages. My usual response was to (sincerely) say that if they built me as Smalltalk-like development environment in their language, I would definitely try it out. Still waiting.
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.
But the feature might not actually be in the standard library for your actually-powerful language, yet.
The lack of expressivity is a strength. My idea of a good programming language is heavily focused on making it hard to write bugs.
The more flexible the language, the harder it is for the compiler to understand it, and the more you encourage random tinkering over bog standardness.
Great for academic language, but in production, the ideal language tries it's best to keep you from doing anything clever.
Core language features tell me that the designers said "This is common, let's provide this one way to do it and not bother with enabling any other ways".
There's a big assumption underlying this article: that it's even possible 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.
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.
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.
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.
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.
First is the urban myth (well, I don't know if it happened or not) of the student arriving late to class just as homework assignments are being handed out, and the student diligently works at the problems though the last one is very hard, and hands them in. The teacher approaches him later and is shocked that he was able to solve the last question which was actually an unsolved problem in the field. The student arrived after that information was shared with the class, and hence simply thought he had to solve it and so did.
Second the phrase "if you don't know how it breaks, you don't know how it works".
That's... certainly one way to create a community, but not the one I'd go for.
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.
This is exactly what the author is talking about. It reminds me of one of my favorite quotes I like to trot out often at work - "There are two kinds of software: software people complain about, and software nobody uses." You see one way to look at it is "complaints", the other way to look at it is "engagement". Crappiness, for lack of a better word, creates engagement and that engagement can have network effects.
Works far better on my mobile device than the 99% of sites that override ability to zoom out, make the menus take up 2/3rds of the screen and wrap the text every 3 words in a giant font.
[+] [-] musha68k|3 years ago|reply
Hilarious and I wholeheartedly agree with the elitist sentiment.
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 human ingenuity.
I would add that there probably is an economic aspect to it as well here.
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.
React based SPAs, distributed systems with Kubernetes, etc all treasure troves of endless solutions to endless problems which need lots of highly skilled peole.
If you think about it from a worker’s perspective there is actually not much wrong with that.
Indeed, inferior is better for many.
[+] [-] jdougan|3 years ago|reply
[+] [-] ncmncm|3 years ago|reply
But the feature might not actually be in the standard library for your actually-powerful language, yet.
[+] [-] eternityforest|3 years ago|reply
The lack of expressivity is a strength. My idea of a good programming language is heavily focused on making it hard to write bugs.
The more flexible the language, the harder it is for the compiler to understand it, and the more you encourage random tinkering over bog standardness.
Great for academic language, but in production, the ideal language tries it's best to keep you from doing anything clever.
Core language features tell me that the designers said "This is common, let's provide this one way to do it and not bother with enabling any other ways".
[+] [-] kaba0|3 years ago|reply
(Do give it a few minutes if you don’t find it useful in the beginning, it will make sense I promise)
[+] [-] vlmutolo|3 years ago|reply
[+] [-] dusted|3 years ago|reply
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)
[+] [-] jjk166|3 years ago|reply
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.
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.
[+] [-] lioeters|3 years ago|reply
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.
[+] [-] barking_biscuit|3 years ago|reply
First is the urban myth (well, I don't know if it happened or not) of the student arriving late to class just as homework assignments are being handed out, and the student diligently works at the problems though the last one is very hard, and hands them in. The teacher approaches him later and is shocked that he was able to solve the last question which was actually an unsolved problem in the field. The student arrived after that information was shared with the class, and hence simply thought he had to solve it and so did.
Second the phrase "if you don't know how it breaks, you don't know how it works".
[+] [-] eternityforest|3 years ago|reply
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.
[+] [-] jdougan|3 years ago|reply
[+] [-] atemerev|3 years ago|reply
[+] [-] psteitz|3 years ago|reply
[+] [-] xyzzy_plugh|3 years ago|reply
[+] [-] atemerev|3 years ago|reply
[+] [-] Kaze404|3 years ago|reply
[+] [-] barking_biscuit|3 years ago|reply
[+] [-] Schroedingersat|3 years ago|reply
[+] [-] hallway_monitor|3 years ago|reply