I wouldn’t even call this an article, it’s just a bunch of random quotes and a list of things someone doesn’t like for some pretty non-obvious reasons we can only guess at (in some of the cases, anyway).
Completely agree. I was hoping someone could shine some light on some of the choices. Obviously, this comes from someone involved with Plan 9. But if there were no Plan 9, how would this list look like?
It’d likely be something like suckless. Here’s a rant about POSIX locales that might be relevant. These are easy to find if you search. I’d propose you do so.
I think cat-v can be summarized as striving for mathematical-like simplicity and solving the problems in right place. I find this simplicity invaluable because it reduces noise a lot.
The distinction here (the only one I can see, as the author doesn’t deign to explain another) is features, as a proxy for complexity. I don’t know about him, but I’d rather continue to use SVGs and PDF over PS, GUIs over textual interfaces, IMAP over SMAP, nano over ed… I mean some of these are just silly. Why are man pages any better than GNU info? This reads a bit like ‘old man yells at cloud’.
The line seems to be that features are bad. All software should be simple, and it a certain feature necessitates solving an actual complex problem one should simply bury their head in the sand and refuse to implement that feature, regardless of its usefulness.
cat-v is seemingly just a group of people that fetishize aesthetic “simplicity” without any true technical arguments or practical reasoning. I don’t see any value to arbitrarily dividing pieces of software into “harmful” and not.
Curious about why C is considered less harmful than D. My experiences with D were all pretty pleasant. In another thread someone mentioned how D takes a “kitchen sink” approach to programming, which I could see. Then there’s also the fact that it’s unsafe by default. So being a larger unsafe language, maybe one could argue that it’s like C but it gives you more rope?
It is just unsubstantiated nonsense, it doesn’t even try to provide justifications and has a lot of very iffy items.
But if I wanted to defend that position for argument’s sake, I might say C is more of a known quantity than D. Less rope perhaps, but also many of the problems of C are known to a lot of people and there’s processes to mitigate its risk whereas D has more uncertainty, especially in some areas where C has a lot of history like kernel development. (I know Linux Torvalds prefers plain C and I think it is because he finds it easier to follow what is going on; less syntax sugar, less potential for runtime surprises.) The hint at the end of the link saying “complexity” is the problem could just say since D is more complex, it is worse.
I don’t believe that myself but it is the most reasonable argument I can think of. (The counter I like to the complexity thing is much of that is inherent to the problem. Simple languages attacking a complex problem still lead to complex code… it isn’t eliminated, it is just shifted.)
I swear I thought you guys were talking about options A and B which are really C and D but had little to do with programming languages until I hit Torvalds.
There is accidental complexity in D, things that didn’t worked out and complicate the language, but honestly it’s not too bad and all fits in a few blog articles.
I think the author has a small point because (as seen with C++) using a complex tool puts you in the mood to write complex things :) but all in all software exists to make things possible.
You can’t separate software into “Harmful” and “Not”. Things are nuanced, the world is complicated and trying to make arbitrary categories is the truly harmful thing going on.
Lots to digest and think about. Ignore the temptation to become reactionary and consider the note posted on the page:
Note: At the moment a detailed rationale is not provided for most of this, so figuring out why some things are considered more or less harmful than others is left as an exercise for the reader. Here is a hint: complexity is the bane of all software, simplicity is the most important quality. See also: Worse is Better by Richard Gabriel.
Becoming a reactionary is really tempting because “not providing a rationale” only works if we trust the writer’s judgment, and they’ve not provided any justification to trust them.
Harmful things that are so superfluous and useless that require no alternative:
PoSix locales.
I can sort of get not liking POSIX locales. POSIX locales specify encoding, while nowadays you really should only be specifying language and measurements, and just use UTF-8 as the encoding. They also affect the behaviour of functions that are used in software<->software interfaces, which can break stuff*.
But “superfluous”? Why would you bother with UTF8, so much hassle to support multiple languages, just to turn around and not actually support translating the interface? Do they have some sort of alternative method in mind for how to specify one’s preferred, default natural language?
* classic “UNIX Hater’s Handbook” talking point; UNIX design is to have one interface that serves double-duty as a UI and an API, resulting in an interface that’s subpar for both
POSIX locales as harmful is a nice piece of cultural imperialism from lazy programmers:
As a native of a non-anglo culture I can see several nuances my native culture is better suited for daily use in localized form than the POSIX default American-English culture (eg. date format is yyyy.mm.dd not the… stuff used in the USA mm/dd/yyyy).
Also having support for my own culture is convenient for me. Users should have the right to good things, even if some Plan9 wankers think “oh no, it is inconvenient for the sw author: it needs work to be done!”. Guess the appeal of this attitude is a factor in the success of their toy.
I don’t think people opposed to POSIX locales are opposed to the idea of localisations, but rather to the way POSIX locales implements it. In fact, the arguments I’ve seen against POSIX locales is that it makes correct localisations much harder than they need to be.
I never worked much with this so I don’t really have an opinion one way or the other, but I don’t think your comment is a fair portrayal of people’s actual arguments.
I’ve got some experience with .Net localizations and web solutions for localizations, and some 15 year old memories of POSIX localization.
I think it cannot be done in an elegant way without making everyday tasks overly verbose and cumbersome, as it is a cross-cutting concern to pretty much the whole system, not only business logic (it has its effect there: in Hungary week starts with Monday, in other places it starts with Sunday, and we are still in the western calendaring system…), and also the underlying system/framework.
Its effect on frontend/visualization is trivial, that is the only place where I think it is not considered a cross-cutting concern, rather a clear dependency (translations for presentation strings)
Having character encoding in the locale is a dirty hack though. For me that is the only part POSIX locales is clearly bad.
Pretty sure people aren’t arguing against localization, just that doing it as low level as the libc is not the way to go about it. It also doesn’t help that the API is poorly designed.
Note: At the moment a detailed rationale is not provided for most of this, so figuring out why some things are considered more or less harmful than others is left as an exercise for the reader.
There are some quality papers on this site but this is a cop out.
It’s easy (and useless) to complain about something on the Internet.
It’s much harder (and useful) to explain your viewpoint and give a rationale for your opinions.
Here are some of the reasons I ignore critiques without a rationale:
Some people are fanatics.
If the other party believes that $system is morally wrong then it’s a waste of time to discuss it with them.
Some people can’t explain themselves or giving a rationale.
The other person may have formed their viewpoint years ago and circumstances have changed.
Technologies get better or worse over time, either of your viewpoints could be out of date.
All highly biased articles that fail to explain their inflammatory titles suck.
I wouldn’t even call this an article, it’s just a bunch of random quotes and a list of things someone doesn’t like for some pretty non-obvious reasons we can only guess at (in some of the cases, anyway).
Completely agree. I was hoping someone could shine some light on some of the choices. Obviously, this comes from someone involved with Plan 9. But if there were no Plan 9, how would this list look like?
It’d likely be something like suckless. Here’s a rant about POSIX locales that might be relevant. These are easy to find if you search. I’d propose you do so.
I think cat-v can be summarized as striving for mathematical-like simplicity and solving the problems in right place. I find this simplicity invaluable because it reduces noise a lot.
The distinction here (the only one I can see, as the author doesn’t deign to explain another) is features, as a proxy for complexity. I don’t know about him, but I’d rather continue to use SVGs and PDF over PS, GUIs over textual interfaces, IMAP over SMAP, nano over ed… I mean some of these are just silly. Why are man pages any better than GNU info? This reads a bit like ‘old man yells at cloud’.
The line seems to be that features are bad. All software should be simple, and it a certain feature necessitates solving an actual complex problem one should simply bury their head in the sand and refuse to implement that feature, regardless of its usefulness.
“I don’t need this feature, therefore no one needs it”
I think if you consider that the implicit metric is “Works with Plan 9”, most of these decisions make more sense.
cat-v is seemingly just a group of people that fetishize aesthetic “simplicity” without any true technical arguments or practical reasoning. I don’t see any value to arbitrarily dividing pieces of software into “harmful” and not.
Curious about why C is considered less harmful than D. My experiences with D were all pretty pleasant. In another thread someone mentioned how D takes a “kitchen sink” approach to programming, which I could see. Then there’s also the fact that it’s unsafe by default. So being a larger unsafe language, maybe one could argue that it’s like C but it gives you more rope?
It is just unsubstantiated nonsense, it doesn’t even try to provide justifications and has a lot of very iffy items.
But if I wanted to defend that position for argument’s sake, I might say C is more of a known quantity than D. Less rope perhaps, but also many of the problems of C are known to a lot of people and there’s processes to mitigate its risk whereas D has more uncertainty, especially in some areas where C has a lot of history like kernel development. (I know Linux Torvalds prefers plain C and I think it is because he finds it easier to follow what is going on; less syntax sugar, less potential for runtime surprises.) The hint at the end of the link saying “complexity” is the problem could just say since D is more complex, it is worse.
I don’t believe that myself but it is the most reasonable argument I can think of. (The counter I like to the complexity thing is much of that is inherent to the problem. Simple languages attacking a complex problem still lead to complex code… it isn’t eliminated, it is just shifted.)
I swear I thought you guys were talking about options A and B which are really C and D but had little to do with programming languages until I hit Torvalds.
I think it’s because Pike designed Go and the author of the article was a big fan of Pike.
The point of view of Walter Bright (D creator) has always been: https://forum.dlang.org/post/m19mc6$1798$1@digitalmars.com and that investment in a langage is a one-time investment (vs reading code).
There is accidental complexity in D, things that didn’t worked out and complicate the language, but honestly it’s not too bad and all fits in a few blog articles.
I think the author has a small point because (as seen with C++) using a complex tool puts you in the mood to write complex things :) but all in all software exists to make things possible.
You can’t separate software into “Harmful” and “Not”. Things are nuanced, the world is complicated and trying to make arbitrary categories is the truly harmful thing going on.
But this worked out so well in politics! 🙃
Lots to digest and think about. Ignore the temptation to become reactionary and consider the note posted on the page:
Becoming a reactionary is really tempting because “not providing a rationale” only works if we trust the writer’s judgment, and they’ve not provided any justification to trust them.
Great software can be written just about any language. That is all.
I can sort of get not liking POSIX locales. POSIX locales specify encoding, while nowadays you really should only be specifying language and measurements, and just use UTF-8 as the encoding. They also affect the behaviour of functions that are used in software<->software interfaces, which can break stuff*.
But “superfluous”? Why would you bother with UTF8, so much hassle to support multiple languages, just to turn around and not actually support translating the interface? Do they have some sort of alternative method in mind for how to specify one’s preferred, default natural language?
* classic “UNIX Hater’s Handbook” talking point; UNIX design is to have one interface that serves double-duty as a UI and an API, resulting in an interface that’s subpar for both
POSIX locales as harmful is a nice piece of cultural imperialism from lazy programmers:
As a native of a non-anglo culture I can see several nuances my native culture is better suited for daily use in localized form than the POSIX default American-English culture (eg. date format is yyyy.mm.dd not the… stuff used in the USA mm/dd/yyyy).
Also having support for my own culture is convenient for me. Users should have the right to good things, even if some Plan9 wankers think “oh no, it is inconvenient for the sw author: it needs work to be done!”. Guess the appeal of this attitude is a factor in the success of their toy.
I don’t think people opposed to POSIX locales are opposed to the idea of localisations, but rather to the way POSIX locales implements it. In fact, the arguments I’ve seen against POSIX locales is that it makes correct localisations much harder than they need to be.
I never worked much with this so I don’t really have an opinion one way or the other, but I don’t think your comment is a fair portrayal of people’s actual arguments.
I’ve got some experience with .Net localizations and web solutions for localizations, and some 15 year old memories of POSIX localization.
I think it cannot be done in an elegant way without making everyday tasks overly verbose and cumbersome, as it is a cross-cutting concern to pretty much the whole system, not only business logic (it has its effect there: in Hungary week starts with Monday, in other places it starts with Sunday, and we are still in the western calendaring system…), and also the underlying system/framework.
Its effect on frontend/visualization is trivial, that is the only place where I think it is not considered a cross-cutting concern, rather a clear dependency (translations for presentation strings)
Having character encoding in the locale is a dirty hack though. For me that is the only part POSIX locales is clearly bad.
Pretty sure people aren’t arguing against localization, just that doing it as low level as the libc is not the way to go about it. It also doesn’t help that the API is poorly designed.
Poorly designed APIs are a C/POSIX trademark.
As long as number to text formatting and date to text formatting, date handling is done in the libc, it must handle localization.
There are some quality papers on this site but this is a cop out.
It’s easy (and useless) to complain about something on the Internet.
It’s much harder (and useful) to explain your viewpoint and give a rationale for your opinions.
Here are some of the reasons I ignore critiques without a rationale:
If the other party believes that $system is morally wrong then it’s a waste of time to discuss it with them.
Technologies get better or worse over time, either of your viewpoints could be out of date.