4 ms·

Thank you! And yes, I admit you were partly right. Questions often have some component of rhetorical quality. It's not always yes/no on whether it's a rhetorica

Thank you! And yes, I admit you were partly right. Questions often have some component of rhetorical quality. It's not always yes/no on whether it's a rhetorical question or not. But either way, I find (based on experience teaching) that the best way to answer a question is just by treating it as genuine. Past a point if I decide someone's acting in bad faith I just disengage. Anyways, back to the original question, I do believe that a lot of programmers (I don't buy OP's separation between GNU and non-GNU) over-engineer things without regard to the costs created by over-engineered code. My default assumption is that that's happening in yes. If it's happening in such a small program where it's so obvious, the same tendencies are likely to be at work in more complex programs like cat and awk and cc. Happy to debate that :)

marcodiego 5y ago
Debating that... I think https://news.ycombinator.com/item?id=14543640 https://news.ycombinator.com/item?id=14543640 is more plausible.
- akkartik 5y ago
  Thanks! Glad you didn't think I was in bad faith after the semi-rhetorical question and disengage. That whole thread makes me sad. Another, more subtle way IP is ruining the world. But that's neither here nor there on this debate. Just to flesh out my current thinking a bit more: * I'd really like a study to understand how much complexity old GNU tools have gained in the past 2 decades. Because that would not be due to copyright concerns. But I'm not sure I have the necessary skills. (I'd like this study for non-GNU as well, but I assume copyright is not a concern there so the study doesn't have to set crisp time bounds.) * I share some of Drew DeVault's frustration in https://drewdevault.com/2020/09/25/A-story-of-two-libcs.html https://drewdevault.com/2020/09/25/A-story-of-two-libcs.html. I've viscerally felt the immediate sense of disempowerment he describes when cracking open an open source package. _However_ I vehemently oppose his cavalier lack of concern for locales. Internationalization is important. ASCII is just as effective at disempowering others.
  - marcodiego 5y ago
    > Thanks! Glad you didn't think I was in bad faith after the semi-rhetorical question and disengage. You are welcome! Considering the karma I got from that answer, I don't think I'm the only one who misread you. If you want a piece of advice: starting a question like that with "Genuinely curious: ..." is my strategy to prevent this kind of misunderstanding. > * I share some of Drew DeVault's frustration in https://drewdevault.com/2020/09/25/A-story-of-two-libcs.html https://drewdevault.com/2020/09/25/A-story-of-two-libcs.html. I've viscerally felt the immediate sense of disempowerment he describes when cracking open an open source package. _However_ I vehemently oppose his cavalier lack of concern for locales. Internationalization is important. ASCII is just as effective at disempowering others. As Drew DeVault's says, it was his code which was broken. I know glic code is complex, but it is battle tested, mature and highly robust. I'd bet there are good reasons for that complexity. If I was really curious as to why, I'd try asking devs directly to avoid making them look bad by making public statements about it. Now, I looked in scdoc code. The solution was to cast the parameters to "unsigned char". Considering the code uint32_t ch; isalnum(ch); compiles without warning (even with -Wall -Wextra) on my machine, I'd consider this a potential vulnerability for programs using this function. I can't see why glibc developers don't turn isalnum into a macro that automatically casts its parameter (when its address is not taken). I'll consider asking them this weekend. EDIT: possible nice finding: https://news.ycombinator.com/item?id=24597461 https://news.ycombinator.com/item?id=24597461 EDIT2: part of the reason: "unsigned char" can't hold EOF.
    - akkartik 5y ago
      Regarding "genuinely curious": I've seen some real passive-aggressive comments that say that :) Regarding "asking devs directly": I often find it challenging even to figure out where to ask. Going from a program to its package, dealing with interactions between packages, etc. All of which goes back to simplicity as a core goal. "Good reasons for complexity" isn't sufficient, IMO. Complexity requires having a place to explain the reasons, and making it easy for people to find the place. Considering that we're all volunteers when it comes to open source and this sort of documentation is difficult, I'd often rather err on the side of not having a feature rather than having a more complex feature. On the other hand, there are fields like internationalization or power management on laptops that are irreducibly complex. Not sure where I'm going with all this. Open source today serves businesses more than people, IMO. But it also serves people indirectly through businesses. This is a difficult topic. Your comment made it seem like there's an easy thing Drew or I could do. I'm not sure that's the case.
- akkartik 5y ago
  I couldn't stop thinking about this link. Here's a stronger statement of the problems I see with the GNU guidelines: https://merveilles.town/@akkartik/107022123346940723 https://merveilles.town/@akkartik/107022123346940723

marcodiego 5y ago

Debating that... I think https://news.ycombinator.com/item?id=14543640 https://news.ycombinator.com/item?id=14543640 is more plausible.

akkartik 5y ago
Thanks! Glad you didn't think I was in bad faith after the semi-rhetorical question and disengage. That whole thread makes me sad. Another, more subtle way IP is ruining the world. But that's neither here nor there on this debate. Just to flesh out my current thinking a bit more: * I'd really like a study to understand how much complexity old GNU tools have gained in the past 2 decades. Because that would not be due to copyright concerns. But I'm not sure I have the necessary skills. (I'd like this study for non-GNU as well, but I assume copyright is not a concern there so the study doesn't have to set crisp time bounds.) * I share some of Drew DeVault's frustration in https://drewdevault.com/2020/09/25/A-story-of-two-libcs.html https://drewdevault.com/2020/09/25/A-story-of-two-libcs.html. I've viscerally felt the immediate sense of disempowerment he describes when cracking open an open source package. _However_ I vehemently oppose his cavalier lack of concern for locales. Internationalization is important. ASCII is just as effective at disempowering others.
- marcodiego 5y ago
  > Thanks! Glad you didn't think I was in bad faith after the semi-rhetorical question and disengage. You are welcome! Considering the karma I got from that answer, I don't think I'm the only one who misread you. If you want a piece of advice: starting a question like that with "Genuinely curious: ..." is my strategy to prevent this kind of misunderstanding. > * I share some of Drew DeVault's frustration in https://drewdevault.com/2020/09/25/A-story-of-two-libcs.html https://drewdevault.com/2020/09/25/A-story-of-two-libcs.html. I've viscerally felt the immediate sense of disempowerment he describes when cracking open an open source package. _However_ I vehemently oppose his cavalier lack of concern for locales. Internationalization is important. ASCII is just as effective at disempowering others. As Drew DeVault's says, it was his code which was broken. I know glic code is complex, but it is battle tested, mature and highly robust. I'd bet there are good reasons for that complexity. If I was really curious as to why, I'd try asking devs directly to avoid making them look bad by making public statements about it. Now, I looked in scdoc code. The solution was to cast the parameters to "unsigned char". Considering the code uint32_t ch; isalnum(ch); compiles without warning (even with -Wall -Wextra) on my machine, I'd consider this a potential vulnerability for programs using this function. I can't see why glibc developers don't turn isalnum into a macro that automatically casts its parameter (when its address is not taken). I'll consider asking them this weekend. EDIT: possible nice finding: https://news.ycombinator.com/item?id=24597461 https://news.ycombinator.com/item?id=24597461 EDIT2: part of the reason: "unsigned char" can't hold EOF.
  - akkartik 5y ago
    Regarding "genuinely curious": I've seen some real passive-aggressive comments that say that :) Regarding "asking devs directly": I often find it challenging even to figure out where to ask. Going from a program to its package, dealing with interactions between packages, etc. All of which goes back to simplicity as a core goal. "Good reasons for complexity" isn't sufficient, IMO. Complexity requires having a place to explain the reasons, and making it easy for people to find the place. Considering that we're all volunteers when it comes to open source and this sort of documentation is difficult, I'd often rather err on the side of not having a feature rather than having a more complex feature. On the other hand, there are fields like internationalization or power management on laptops that are irreducibly complex. Not sure where I'm going with all this. Open source today serves businesses more than people, IMO. But it also serves people indirectly through businesses. This is a difficult topic. Your comment made it seem like there's an easy thing Drew or I could do. I'm not sure that's the case.
akkartik 5y ago
I couldn't stop thinking about this link. Here's a stronger statement of the problems I see with the GNU guidelines: https://merveilles.town/@akkartik/107022123346940723 https://merveilles.town/@akkartik/107022123346940723