5 ms·

I mostly agree with your comment, but the source code of of many GNU coreutils is quite gnarly. It's ancient code (from my reference point as a 35yo) developed

by cdogl 3y ago

I mostly agree with your comment, but the source code of of many GNU coreutils is quite gnarly. It's ancient code (from my reference point as a 35yo) developed at a time when coding style was different and a much smaller community maintained it. I think it's important for free software that people coming into the community are enthusiastic to maintain it. It took the wind out of my sails a little when I realised the GNU code base, while it produces critical tools I use every day, is written in a way that I found extremely (unnecessarily) terse and "clever". Tracing how different combinations of flags are handled is not much fun. Documentation is helpful for the user, less so for the tinkerer who is trying to understand the stack. If this project manages to hit parity with GNU coreutils, and my distro(s) provide support, I'll switch to it purely on that basis.

Throw839 3y ago
This! I am horrified to touch anything old from GNU!
viraptor 3y ago
This is true. I've tried to read some gnu code in the past (tar) and patch another (df) and... ran away instead. It's doable, but so messy I'd rather write my own very specific command, than try improving one of the old-style gnu ones.
dmd 3y ago
I've interacted quite a bit with some of the authors, and when I've asked "why on earth did you do it this way" the answer is generally some form of "well, it saves nearly 6 bytes on disk in the source code! disk isn't free, son". It's a different mindset and one that is no longer useful.
- bayindirh 3y ago
  When I asked a graybeard why the variable names were so short, he said that "longer names affected compile duration very severely in the past, so this is why we used the shortest name possible". While user facing programs are not faster by any means, computers got faster in some aspects after all.
  - johnisgood 3y ago
    I think it is important to strike a balance here, see Java codebases for the other extreme end of the spectrum where the variable name may not fit within 80 column width.
    - bayindirh 3y ago
      Of course. I name things as "configuration_storage", but not "configuration_factory_singleton_configuration_stub_constructor". I've been there, seen the horror. Never again.
    - acchow 3y ago
      In 20 years with growing display sizes and resolutions, I’d have hoped 100 or 120 columns replaced 80
      - spencerchubb 3y ago
        I thought the column recommendation of 80 was about eye movement and reading speed, not display width.
        ncallaway 3y ago
        I think it was both, and has become more the former now. My preferred line-width for code would be 80 characters, not including indentation for the line, with a maximum of 120 characters including indentation.
    - lenkite 3y ago
      Apple OS programming beats name length for Java anyday but it never gets a bad rep thanks to apple's reality distortion field. CMMetadataFormatDescriptionCreateWithMetadataFormatDescriptionAndMetadataSpecifications
  - dboreham 3y ago
    This is mostly wrong. Longer variable names never significantly affected the time to run a compiler. Back in the day the run time for compilers was mostly determined by the overhead to load in each overlay (the whole compiler didn't fit in memory). That said, often there was a hard limit on the length of identifiers that wasn't terribly long (e.g. 8 characters), so very verbose names were not possible. The more obvious reasons for preferring short variable names are: 1. It's more like math, and for simple code looks nicer, and the descriptive variable name mafia were still in diapers and 2. typing was slow and painful, so was editing (use an ASR-33 with 'ed' to find out how painful). What your greybeard might have been talking about was to do with interpreted languages where the interpreter had to parse through the code in some situations when performing a jump/goto. This meant that the more characters there were between the jump origin and destination, the slower execution was. I remember this being a factor in early 8-bit BASIC implementations, leading to a desire to make programs as terse as possible to achieve fast execution. Later implementations tokenized the source before execution, avoiding that problem.
- amluto 3y ago
  > It's a different mindset and one that is no longer useful. I disagree. Sure, 6 bytes is approximately free in most contexts, but 100MB is not free, and 5GB is even less free. But more importantly, writing code under constraints can force good behavior. For example, BIOS is a legacy mess but it’s a small, self-contained legacy mess that fits in a few kB. Compare to UEFI, which is unbelievably complicated and bug-ridden. A mess like UEFI could not have fit within the constraints of BIOS. This is not to say that writing obscure code to save a couple bytes of source file size is at all worthwhile any more, but the idea that one should constrain bloat (design bloat, code bloat, executable bloat, network bloat, etc) is very much still valuable.
  - remus 3y ago
    I don't think it is so black and white. The original authors made trade offs that made sense at the time, but in the intervening period the context has changed and those trade offs don't necessarily make sense. The parents point is obviously exaggerated, but currently disk is cheap and the cost of inscrutable code, especially code that is run by millions or even billions of people, is extremely high: bugs are harder to spot and harder to fix, the barrier to entry for new maintainers is high, new features are harder to add etc.
- 9659 3y ago
  except when it is.
- dig1 3y ago
  The thing is that coreutils is used everywhere - servers, desktops, and embedded devices, including 30-40 years old machines. You want to update coreutils on old SPARC or some even older mainframe? Every byte counts. So, saving as many bytes as possible is still very relevant.
  - kstrauser 3y ago
    How often are we updating coreutils on 40 year old machines today? Are there more than a couple of hobby machines that old and still regularly updated with new packages?
    - dig1 3y ago
      You'd be surprised how many banks, electrical grids, oil rigs, and large ships run on old hardware. If ain't broken, you don't replace it. But keeping the system up-to-date is always a benefit.
      - mschuster91 3y ago
        > You'd be surprised how many banks, electrical grids, oil rigs, and large ships run on old hardware. If ain't broken, you don't replace it. That attitude has got to die in an age of everything being exploited by bad actors. Anything that has any form of networking should have regular replacement at least of the control plane components budgeted in from the start.
        lbhdc 3y ago
        On the otherhand, I think you could argue that it is something to strive for in more systems. The longer our devices can last the less ewaste we generate. It may not be the easiest to secure, but it isn't impossible.
        elzbardico 3y ago
        Most of those really old devices are usually air-gaped from the internet for incidental reasons. Either they run on closed networks or have no networking at all. You're not going to find a 30 years old machine that controls the pumps of nuclear reactor on the internet.
- stevehawk 3y ago
  You say that, but I recently ran out of disk space on my iPhone.. and the more I looked at the apps the more I realized "I bet these are all framework based apps and not native apps, and no one is tree-shaking their code or doing /any/ of the things you're supposed to in order to minimize disk usage.".. *shakes fist at clouds*

by cdogl 3y ago

Throw839 3y ago

This! I am horrified to touch anything old from GNU!

viraptor 3y ago

This is true. I've tried to read some gnu code in the past (tar) and patch another (df) and... ran away instead. It's doable, but so messy I'd rather write my own very specific command, than try improving one of the old-style gnu ones.

dmd 3y ago

I've interacted quite a bit with some of the authors, and when I've asked "why on earth did you do it this way" the answer is generally some form of "well, it saves nearly 6 bytes on disk in the source code! disk isn't free, son". It's a different mindset and one that is no longer useful.

bayindirh 3y ago
When I asked a graybeard why the variable names were so short, he said that "longer names affected compile duration very severely in the past, so this is why we used the shortest name possible". While user facing programs are not faster by any means, computers got faster in some aspects after all.
- johnisgood 3y ago
  I think it is important to strike a balance here, see Java codebases for the other extreme end of the spectrum where the variable name may not fit within 80 column width.
  - bayindirh 3y ago
    Of course. I name things as "configuration_storage", but not "configuration_factory_singleton_configuration_stub_constructor". I've been there, seen the horror. Never again.
  - acchow 3y ago
    In 20 years with growing display sizes and resolutions, I’d have hoped 100 or 120 columns replaced 80
    - spencerchubb 3y ago
      I thought the column recommendation of 80 was about eye movement and reading speed, not display width.
      - ncallaway 3y ago
        I think it was both, and has become more the former now. My preferred line-width for code would be 80 characters, not including indentation for the line, with a maximum of 120 characters including indentation.
  - lenkite 3y ago
    Apple OS programming beats name length for Java anyday but it never gets a bad rep thanks to apple's reality distortion field. CMMetadataFormatDescriptionCreateWithMetadataFormatDescriptionAndMetadataSpecifications
- dboreham 3y ago
  This is mostly wrong. Longer variable names never significantly affected the time to run a compiler. Back in the day the run time for compilers was mostly determined by the overhead to load in each overlay (the whole compiler didn't fit in memory). That said, often there was a hard limit on the length of identifiers that wasn't terribly long (e.g. 8 characters), so very verbose names were not possible. The more obvious reasons for preferring short variable names are: 1. It's more like math, and for simple code looks nicer, and the descriptive variable name mafia were still in diapers and 2. typing was slow and painful, so was editing (use an ASR-33 with 'ed' to find out how painful). What your greybeard might have been talking about was to do with interpreted languages where the interpreter had to parse through the code in some situations when performing a jump/goto. This meant that the more characters there were between the jump origin and destination, the slower execution was. I remember this being a factor in early 8-bit BASIC implementations, leading to a desire to make programs as terse as possible to achieve fast execution. Later implementations tokenized the source before execution, avoiding that problem.
amluto 3y ago
> It's a different mindset and one that is no longer useful. I disagree. Sure, 6 bytes is approximately free in most contexts, but 100MB is not free, and 5GB is even less free. But more importantly, writing code under constraints can force good behavior. For example, BIOS is a legacy mess but it’s a small, self-contained legacy mess that fits in a few kB. Compare to UEFI, which is unbelievably complicated and bug-ridden. A mess like UEFI could not have fit within the constraints of BIOS. This is not to say that writing obscure code to save a couple bytes of source file size is at all worthwhile any more, but the idea that one should constrain bloat (design bloat, code bloat, executable bloat, network bloat, etc) is very much still valuable.
- remus 3y ago
  I don't think it is so black and white. The original authors made trade offs that made sense at the time, but in the intervening period the context has changed and those trade offs don't necessarily make sense. The parents point is obviously exaggerated, but currently disk is cheap and the cost of inscrutable code, especially code that is run by millions or even billions of people, is extremely high: bugs are harder to spot and harder to fix, the barrier to entry for new maintainers is high, new features are harder to add etc.
9659 3y ago
except when it is.
dig1 3y ago
The thing is that coreutils is used everywhere - servers, desktops, and embedded devices, including 30-40 years old machines. You want to update coreutils on old SPARC or some even older mainframe? Every byte counts. So, saving as many bytes as possible is still very relevant.
- kstrauser 3y ago
  How often are we updating coreutils on 40 year old machines today? Are there more than a couple of hobby machines that old and still regularly updated with new packages?
  - dig1 3y ago
    You'd be surprised how many banks, electrical grids, oil rigs, and large ships run on old hardware. If ain't broken, you don't replace it. But keeping the system up-to-date is always a benefit.
    - mschuster91 3y ago
      > You'd be surprised how many banks, electrical grids, oil rigs, and large ships run on old hardware. If ain't broken, you don't replace it. That attitude has got to die in an age of everything being exploited by bad actors. Anything that has any form of networking should have regular replacement at least of the control plane components budgeted in from the start.
      - lbhdc 3y ago
        On the otherhand, I think you could argue that it is something to strive for in more systems. The longer our devices can last the less ewaste we generate. It may not be the easiest to secure, but it isn't impossible.
      - elzbardico 3y ago
        Most of those really old devices are usually air-gaped from the internet for incidental reasons. Either they run on closed networks or have no networking at all. You're not going to find a 30 years old machine that controls the pumps of nuclear reactor on the internet.
stevehawk 3y ago
You say that, but I recently ran out of disk space on my iPhone.. and the more I looked at the apps the more I realized "I bet these are all framework based apps and not native apps, and no one is tree-shaking their code or doing /any/ of the things you're supposed to in order to minimize disk usage.".. *shakes fist at clouds*