Comment by ryandrake | Hacker News Reader

Comment by ryandrake | Hacker News Reader

Parent Full thread

> It saddens me to say but if I were starting over today I might not enter the field professionally. Most modern development is gluing components together and wrangling packages. It's so far removed from the machine and the distance is only growing.

I don't know what's sadder: That this kind of programming is becoming a lost art, or that nobody seems to care. I got my first job out of college partially because in the interview when I was asked to implement some algorithm XYZ in "any language I choose" I went with X86 assembly and nailed it. Well-performing code was highly valued at that company. Knowing how to ensure your code fit into the cache and your memory accesses stayed on one page were considered critical programming skills.

Now, outside of a few rare embedded or game engine jobs, nobody seems to give a shit about any of this. It's just "glue these APIs and libraries together and ship the resulting crap as soon as it barely runs." Nobody cares about the size of the resulting executable. Nobody cares about or even knows their code's runtime heap footprint. Nobody cares or even measures how many cache misses they're encountering. I feel like an old grandpa even typing this stuff out.

The worst part is that end users are the ones that end up losing. It's their system resources that are ultimately being wasted.

There's a bit of a renaissance here in Rust, or perhaps this is just my bias. Many people are drawn to the lack of a garbage collector and efficiency of the runtime code. Lots of packages optimize algorithms that are unlikely to be strictly necessary for the task at hand.

I think it will remain niche to care deeply about these things but they aren't forgotten. In my late 30s and finding this type of thing more and more fascinating despite working for companies building criminally inefficient software using Ruby and Python and dozens of microservices.

> That this kind of programming is becoming a lost art, or that nobody seems to care.

I think there are real costs if the level of incompetence adds up over a stack/system. But as a general rule, I don't think this is a sad phenomenon at all. Well, actually, it's fair to feel sad about it, but it should be understood as a form of growth for our society. (Growth is often painful.)

Writing low-level code should be viewed like blacksmithing or any other technology. At one time, it was the cutting edge that enabled new tools to exist. But over time, it's become well understood and abstracted and it's possible for us to build factories that automatically output many of the steel products we need. And now we can mass-produce steel components for more advanced machines that would have been impossible if they had to be forged by hand.

I have known programmers who don't know how a float is represented in memory. I just can't comprehend how they can gloss over basics like that.

And why is that necessary knowledge?

Don't get me wrong, once you go down to embedded you sometimes do need to know and sometimes it just improves your understanding (and it's kinda cool anyway), but if you do high-level work, perhaps web work, all you need to know is the abstract interface of floats as a data type. What operations you can do, what is guaranteed about the result of those operations (loss of precision etc). In other words, why would a Haskell programmer need to know the IEEE FP standard?

Maybe not everyone needs to know, but for example it's important to know about it in ML. You can have overflow, underflow, non-deterministic addition when parallelised, or just need to speed up your network.

Right. You can know these abstract properties though without knowing how a float is actually represented in memory.

because you would know not to represent money as a float in any sort of serious system

or any other value where you have repeated calculations that would introduce errors

You have to understand that float are negative powers of 2 and that conversion from decimal is not as straightforward as for integer: conversion from decimal often leads to loss of precision contrary to what happens for integers.

You don't need to know anything about how they're represented to know they can't represent all decimal values.

Because not caring how FP values are stored and what the implications are (or even not realising that you favorite programming language uses FP by default) is a particularly fast way to become the "minus 10 times programmer".

Storing monetary values as FP is one thing, but I've seen phone numbers and other numeric identifiers (long time ago before PCI-DSS even credit card numbers) stored as FP values, with predictable results.

As long as you know the implications, you don't need to know how the values are stored.

You may say it's easier to know how they are stored, then you can derive the implications anytime you need them. Maybe that works for you, but most people who I know that got this wrong do actually know how FP values are stored, they are just drawing the wrong conclusions. So better focus on the implications, cause it's those that matter.

I already expressed this in the GP comment, and it's a little shocking to see all the replies that didn't actually pick up on that.

Knowing how the values are stored provides you the "why" behind the practical implications. Another example: Half of the range of all values that "float" can store lie between -1.0 and 1.0. Knowing how those values are encoded in memory tells you why.

> Because not caring how FP values are stored and what the implications are (or even not realising that you favorite programming language uses FP by default) is a particularly fast way to become the "minus 10 times programmer".

I don't think that's true at all. You're merely looking at a symptom of someone who is intrinsically a negative performer. But that's rather like assuming that someone with a cough has tuberculosis.

Debugging. If you don't know how your code is translated into CPU ops, you won't be able to recognize the clues that malfunctions almost always provide when code misbehaves. Translators, compilers, libraries, and new code routinely have bugs. Depending on a google search to pin down the source of your troubles often fails, and of course is of no help at all diagnosing your own bugs.

It also depends on your philosophy. I want to master my machine not be its servant.

Guilty. I'm pretty good at my job, but I never learned CS fundamentals and don't work in a context where this matters (I currently work in front-end JS/TS).

I don't think it's worthless knowledge to me, but I think you're a bit blinded by your own context. I have seen many comments on HN bemoaning "Developers who don't even know X", and X is always something different.

I don't think there's a smoking gun for bad developers and it's weird to me when programmers think there is one, tbh. Everyone has gaps in their knowledge, and with something so arcane as programming, it's very easy to have no idea that you're missing some important or "fundamental" piece of knowledge

Here's one take: good developers learn fast, bad developers learn slow. Software is one of the fastest moving fields, so it takes a quick mind to keep up. Clearly, everyone needs some basic knowledge to program, and equally clearly, there will be gaps in every developer's knowledge. When needed, we fill the gaps as quickly as possible. If someone can learn 10x as fast, maybe they only need 1/10th the knowledge base.

That's a good metric, but by smoking gun I was referring to individual concepts.

I generally agree, in other languages it suffices to just tell juniors "don't use floating point if you can avoid it". And integer types are less messy to reason with (just need to learn the 32-bit and 64-bit ranges).

But in your specific case (of JS/TS), _all_ the normal numeric variables are in IEEE 754 floating point...

Absolutely correct.

Not to mention most of my time as a "Developer" is spent managing busted CI/CD pipelines, container crap, whatever cloud-yaml things, fighting broken dependencies/build issues, cargo-culting test suites.

I program way more on weekends/nights on toy/tutorial stuff than I do at work, ironically.

Reply on news.ycombinator.com