3 ms·

These kind of nonsense would not fly on other engineering disciplines. I often feel ashamed of software engineering

segfaultbuserr 6y ago
It's not nonsense. The reason of saying "You are not expected to understand this" is not because the developer is arrogant or the code is unmaintainable, but simply because it was a temporary and PDP-11 specific hack, which relied on an implementation detail the compiler - one doesn't learn much trying to understand it, the article says "[...] On the PDP that was true, but on other systems it was not. So they fixed it to work and removed the famous comment". Also, recall that Unix, at this stage, is still largely an experimental operating system, these hacks are totally normal. > I often feel ashamed of software engineering Agree. There are many examples of how software development is unable to constantly deliver predictable results, and how software development has yet to become "engineering". But this is not one of them.
ThrowawayR2 6y ago
There's lots of things to be ashamed of in software engineering but the early UNIX isn't one of them. That's not just vacuous cheerleading; what they built on the tiny machines of that era was nothing short of amazing and they valued efficiency and elegance in a way that very few developers do (or even know how to do) today.
InitialLastName 6y ago
Dare I say, that's because the other engineering disciplines have a rigorous pedagogy that all practitioners are trained in, and follow a standardized development process, with well defined responsibilities (and liabilities for errors). Further, learning how to function within the standardized development process is inherent to the standardized pedagogy. Much engineering work also has better defined interfaces than in software development, at least where working with others is concerned. If I'm designing a PCB to fit into a die-cast enclosure, I don't need to know why the mechanical designer chose the draft angle they did to enable tool release. My consideration of mechanical issues can focus on a) satisfying the mechanical interface to the enclosure, b) meeting the static and dynamic physical constraints and c) enabling efficient and reliable assembly.
bigger_cheese 6y ago
There's plenty of low level details engineers in other disciplines aren't expected to understand. A lot of Engineering is built around models of the world that describe physical behavior. Usually the equations we use are simplified and contain a lot of subtleties when you dig into them. In fluid dynamics for example the Navier–Stokes equations are infamous because we don't understand all the theory behind why they work. They are used all the time despite not being fully understood. Semiconductor behavior is another area, the Band Gap models used to describe them incorporates a lot of quantum physics nuances involving Fermi–Dirac Statistics and wave functions and the like. At some point when you do work in Engineering you are "high enough" up in the stack you can use simplified abstractions and trust that what is underneath is acceptable. From what I've seen software engineer has these abstractions as well, process switching sounds like one of these cases.
- tonyarkles 6y ago
  Re: semiconductor behaviour, I’m having flashbacks to my mandatory Semiconductor Physics class in EE. First day of class: “To understand semiconductors, you first have to understand solid-state physics. To understand solid-state physics, you have to understand quantum mechanics. Settle down now, we’ve got a lot to cover. Let’s begin...”
TomVDB 6y ago
In other engineering disciplines such as electrical engineering/digital design, nobody would ever have state machines that force the reset of a major functional block if said state machine has concluded that the system is hanging. Is that what you mean? You're right. Such a thing would never happen. Never!

It's not nonsense. The reason of saying "You are not expected to understand this" is not because the developer is arrogant or the code is unmaintainable, but simply because it was a temporary and PDP-11 specific hack, which relied on an implementation detail the compiler - one doesn't learn much trying to understand it, the article says "[...] On the PDP that was true, but on other systems it was not. So they fixed it to work and removed the famous comment". Also, recall that Unix, at this stage, is still largely an experimental operating system, these hacks are totally normal. > I often feel ashamed of software engineering Agree. There are many examples of how software development is unable to constantly deliver predictable results, and how software development has yet to become "engineering". But this is not one of them.

ThrowawayR2 6y ago

There's lots of things to be ashamed of in software engineering but the early UNIX isn't one of them. That's not just vacuous cheerleading; what they built on the tiny machines of that era was nothing short of amazing and they valued efficiency and elegance in a way that very few developers do (or even know how to do) today.

InitialLastName 6y ago

Dare I say, that's because the other engineering disciplines have a rigorous pedagogy that all practitioners are trained in, and follow a standardized development process, with well defined responsibilities (and liabilities for errors). Further, learning how to function within the standardized development process is inherent to the standardized pedagogy. Much engineering work also has better defined interfaces than in software development, at least where working with others is concerned. If I'm designing a PCB to fit into a die-cast enclosure, I don't need to know why the mechanical designer chose the draft angle they did to enable tool release. My consideration of mechanical issues can focus on a) satisfying the mechanical interface to the enclosure, b) meeting the static and dynamic physical constraints and c) enabling efficient and reliable assembly.

bigger_cheese 6y ago

There's plenty of low level details engineers in other disciplines aren't expected to understand. A lot of Engineering is built around models of the world that describe physical behavior. Usually the equations we use are simplified and contain a lot of subtleties when you dig into them. In fluid dynamics for example the Navier–Stokes equations are infamous because we don't understand all the theory behind why they work. They are used all the time despite not being fully understood. Semiconductor behavior is another area, the Band Gap models used to describe them incorporates a lot of quantum physics nuances involving Fermi–Dirac Statistics and wave functions and the like. At some point when you do work in Engineering you are "high enough" up in the stack you can use simplified abstractions and trust that what is underneath is acceptable. From what I've seen software engineer has these abstractions as well, process switching sounds like one of these cases.

tonyarkles 6y ago
Re: semiconductor behaviour, I’m having flashbacks to my mandatory Semiconductor Physics class in EE. First day of class: “To understand semiconductors, you first have to understand solid-state physics. To understand solid-state physics, you have to understand quantum mechanics. Settle down now, we’ve got a lot to cover. Let’s begin...”

TomVDB 6y ago

In other engineering disciplines such as electrical engineering/digital design, nobody would ever have state machines that force the reset of a major functional block if said state machine has concluded that the system is hanging. Is that what you mean? You're right. Such a thing would never happen. Never!