Hacker News Reader

Comment by alangibson | Hacker News Reader

"While hardware folks study and learn from the successes and failures of past hardware, software folks do not." Couldn't be further from the truth. Software folks are obsessed with copying what has been shown to work to the point that any advance quickly becomes a cargo cult (see microservices for example).

Once you've worked in both hardware and software engineering you quickly realize that they only superficially similar. Software is fundamentally philosophy, not physics.

Hardware is constrained by real world limitations. Software isn't except in the most extreme cases. Result is that there is not a 'right' way to do any one thing that everyone can converge on. The first airplane wing looks a whole lot like a wing made today, not because the people that designed it are "real engineers" or any such BS, but because that's what nature allows you to do.

View on HN

Software doesn't operate in some magical realm outside of the physical world. It very much is constrained by real world limitations. It runs on the hardware that itself is limited. I wonder if some failures are a result of thinking it doesn't have these limitations?

> It very much is constrained by real world limitations. It runs on the hardware that itself is limited

And yet we scale the shit out of it, shifting limitations further and further. On that scale different problems emerge and there is no single person or even single team that could comprehend this complexity in isolation. You start to encounter problems that have never been solved before.

You can scale it within the bounds of the physical hardware it is running on. And as you scale it you start running into all the problems brought about by distributed systems, problems which very much stem from physics.

As the great Joe Armstrong used to say, “a lot of systems actually break the laws of physics”[1] — don’t program against the laws of physics.

> In distributed systems there is no real shared state (imagine one machine in the USA another in Sweden) where is the shared state? In the middle of the Atlantic? - shared state breaks laws of physics. State changes are propagated at the speed of light - we always know how things were at a remote site not how they are now. What we know is what they last told us. If you make a software abstraction that ignores this fact you’ll be in trouble.[2]

[1]: “The Mess We’re In”, 2014 https://www.youtube.com/watch?v=lKXe3HUG2l4

[2]: https://news.ycombinator.com/item?id=19708900

Except that it kind of does. I can horizontally scale a distributed storage system until we run out of silicon. I cannot do the same with a cargo airplane.

I'm puzzled by your reply because it starts out by refuting that software is constrained by physics "Except it kind of does" and then immediately gives an example of it being constrained by physics "until we run out of silicon".

You can horizontally scale cargo transport by running more cargo planes until you're constrained in some way.

> Software folks are obsessed with copying what has been shown to work to the point that any advance quickly becomes a cargo cult

Seems more accurate to say they are obsessed with copying "what sounds good". Software industry doesn't seem to copy what works, rather what sounds like it'd work, or what sounds cool.

If they copied what works software would just be faster by default, because very often big established tools are replaced by something that offers similar featurage, but offers it at a higher FPS.

I disagree. At least at the RTL level they're very similar. You don't really deal with physics there, except for timing (which is fairly analogous with software performance things like hard real-time constraints).

> Result is that there is not a 'right' way to do any one thing that everyone can converge on.

Are you trying to say there is in hardware? That must be why we have exactly one branch predictor design, lol

> The first airplane wing looks a whole lot like a wing made today, not because the people that designed it are "real engineers" or any such BS, but because that's what nature allows you to do.

"The first function call looks a whole lot like a function call today..."

> That must be why we have exactly one branch predictor design, lol

I'll be that 'well akshually' guy. IIRC the AMD and intel implementations are different enough that spectre/meltdown exploits were slightly different on each manufacturers.

Source: wrote exploits.

It was sarcasm. There are loads of branch predictor designs.

Sorry, I had missed that. I'll go back to my cave.

> "The first function call looks a whole lot like a function call today..."

Only superficially. What's actually happening varies radically by language. See for instance tail call optimization.

What you and the GP said are not mutually exclusive. Software engineers are quick to drink every new Kool-Aid out there, which is exactly why we’re so damned blind to history and lessons learned before.

Reply on news.ycombinator.com