Hacker News Reader

Comment by cdogl | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

In 20 years with growing display sizes and resolutions, I’d have hoped 100 or 120 columns replaced 80

I thought the column recommendation of 80 was about eye movement and reading speed, not display width.

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.

Apple OS programming beats name length for Java anyday but it never gets a bad rep thanks to apple's reality distortion field.

CMMetadataFormatDescriptionCreateWithMetadataFormatDescriptionAndMetadataSpecifications

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.

No, we were talking about how compilers came in at least two disks (one for compiler and one for linker) when this came up.

He started these things with punched cards, and worked at the prominent companies of the time (like IBM and HP), and seen tons of bizarre computer architectures on the way like registerless processors.

He might be recalling a very specific example, or about a very slow system, but I remember the conversation well.

That thing has been probably sorted out by the mid of 90s, but I was just starting programming back then.

Oh, I'm a proud member of "descriptive variable name mafia", but not affiliated with the Java branch. They're a different breed. On the other hand, being written real math in C++ (differential equations), having three letter variable names for everything is equally painful. :)

> 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.

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.

except when it is.

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.

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?

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.

> 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.

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.

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.

But if these machines are so isolated, and given they've been running with the "if it ain't broken" mindset: why, and more importantly how do they even get updated? If they aren't being updated, why discuss constraints on updating them?

I bet they don't get updated, ever.

> You're not going to find a 30 years old machine that controls the pumps of nuclear reactor on the internet.

Stuxnet would like to have a word with you. Airgap isn't enough to prevent malware from spreading.

I don't buy into that here. If it's that mission critical and hard to replace, I wouldn't touch something as essential as coreutils without a gun to my head. In the very best case, the new version would work exactly like the old one so that the 40-year-old shell scripts holding the thing together would continue working as before.

Coreutils might be everywhere, but uutils will only be wherever LLVM targets, because Rust isn't as portable as C. It's much easier to declare yourself cross-platform when you're not actually competing with real cross-platform software (like coreutils).

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*

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.

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

Reply on news.ycombinator.com