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".
I do agree with making it easy to constrain what you write. But I don't think having lots of core language features is a good way of doing that. A core language feature is generally an ad-hoc special case that breaks the rules of the language, almost by definition. Which means it probably interacts poorly with other language features. (For example, if you use a language which has keywords for async and keywords for exceptions, they will probably interact badly; if you use a language that encourages ordinary functions for async and error handling, they will probably play nice together).
This starts off very strange and quirky and the moment it clicks was a very magical one for me the first time I watched it many years ago. It's one of my all time favorite talks.
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.
> 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.
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.
There really are... which is why projects should decide up front who the target audience is, and not try to please the suckless crowd if that's not the target.
The downside is of course, the suckless crowd can get totally left out when the whole world switches to the new standard(see The Init System That Starts Flame Wars), which is almost unsolvable since there's no product that can please both minimalists and those who want things to just work with zero tinkering, and not much reason for mainstream users to pay attention to anything but the popular standard.
Not quite, more of a Rust admirer. I'd love to use it but I don't have any use case for something that is both that low level and not an embedded platform where you still need C++.
Sometimes I look into using it for personal projects, but always wind up using some Python/JS/Dart instead, since whatever it was I thought about doing in Rust usually already exists as a library.
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".
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.
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.
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.
33 comments
[ 3.7 ms ] story [ 92.5 ms ] threadBut 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".
This is why sufficiently modern C++ programs have no memory usage errors. It would be extra work to code them.
(Do give it a few minutes if you don’t find it useful in the beginning, it will make sense I promise)
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.
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.
The downside is of course, the suckless crowd can get totally left out when the whole world switches to the new standard(see The Init System That Starts Flame Wars), which is almost unsolvable since there's no product that can please both minimalists and those who want things to just work with zero tinkering, and not much reason for mainstream users to pay attention to anything but the popular standard.
Sometimes I look into using it for personal projects, but always wind up using some Python/JS/Dart instead, since whatever it was I thought about doing in Rust usually already exists as a library.
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".
It did. https://en.wikipedia.org/wiki/George_Dantzig
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)
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.