5 ms·

Software is different. All other engineering disciplines are ultimately limited to building things in (at most) 3 euclidean dimensions. There is only so much j

Software is different. All other engineering disciplines are ultimately limited to building things in (at most) 3 euclidean dimensions. There is only so much junk you can hide in a finite volume of space. Code by comparison lives in hyperbolic space [0] and you can hide _anything_ in such a space without it being obvious. This is exemplified by the unpleasant discovery all of us have had of a supposedly peripheral folder holding source code called all over the code base and the near impossibility of moving it in a location that makes sense for it without having to refactor the whole code base. People, including myself, have a seriously bad intuition just how much volume there is in a space which grows at least exponentially. The closest discipline to software engineering is mathematics and that has an even worse track record. There's the folklore about half of all math papers giving the wrong proof for the right conclusion. By comparison software engineering only gets catastrophic bugs less than every other time a program is run. [0] All trees are natively embedded in some hyperbolic space of whatever curvature matches the average number of children per node, and all code can be ultimately represented as a tree.

tkahnoski 2y ago
I think maybe this misses the mark. Yes software can lead to unbounded complexity unlikely many physics based engineering disciplines. However, at the end of the day, there is an input and output and compute and memory needed to run the thing and if we look at that we realize, we never actually left the bounded physical realm and we can still engineer software systems against real world constraints. We can judge its efficiency and breaking points. What's very different is the cost to change the system to do something new and that's where this unbounded complexity blows up in our face.
- noosphr 2y ago
  >However, at the end of the day, there is an input and output and compute and memory needed to run the thing and if we look at that we realize, we never actually left the bounded physical realm and we can still engineer software systems against real world constraints. We can judge its efficiency and breaking points. This is a common sense view of computation that's unfortunately wrong. The simplest counter example is the busy beaver program: with as little as 12 states we have saturated the computational capabilities of the universe, but it looks completely safe and sane for the first few states you would be testing against. You may call it pathological, and you'd be right, but the point is that you never know under which rug a function that takes more computation than the universe can supply is hiding. By comparison power electronics engineers don't have to formally prove that they didn't accidentally include a nuclear power plant in their e-scooter design.
  - magicalist 2y ago
    And then you quickly find out that the turing machine on your lap doesn't actually have infinite tape. Do you honestly believe that there's no other human endeavor where you can DoS yourself? If on the other hand you're speaking of the theoretical computational needs of the program you just wrote, then your earlier dismissal of mathematics and its "even worse track record" is all the sillier.
  - tkahnoski 2y ago
    I think you just made my point. If designing an eScooter you'd look at available power needed across the problem space. Even more so you might put in a safety features like a temperature monitor so electronic components don't fail because someone decided to go up a steep 12 mile mountain path and overheat the battery. If I was designing a software system, I could introduce a time constraint. An imagined conversation: "How long will it take to get an answer? Between half a second and the heat death of the universe. OK. Can we just issue a timeout error after 1 second?" This is putting controls in place so the system doesn't exceed its constraints and although hypothetical it might be able to do a job for any input, it can't because we haven't been able to find a more efficient solution for certain known and unknown scenarios.
shafyy 2y ago
I don't know, man. Your comment is neither here nor there.
knowsuchagency 2y ago
Disagree. What makes software unique to other engineering disciplines is that it isn't a discipline at all. What makes software so great is how quick the iteration cycles are. Software sits at a higher abstraction level than physical hardware, so much of our time is spent throwing at the wall and seeing what sticks because that's often (although not always) the best use of time.
- threatofrain 2y ago
  There is a discipline, it's just very fast-growing. Many techniques remain and become classics, it just takes awhile to realize what is fad vs classical.
  - sunrunner 2y ago
    Can you give some examples of things you'd consider fads versus classical in software?
    - TylerE 2y ago
      TDD. Agile.
      - throwaway2037 2y ago
        I would disagree about TDD. I am continuously surprised when I learn that yet another one of my teammates practices TDD. TL;DR: TDD is dead; long live TDD. I think that TDD will remain viable in enterprise programmer for decades, perhaps permanently, thanks to "vibe-coding", where LLMs eventually produce most code for CRUD projects (the vast majority of enterprise programming).
        TylerE 2y ago
        Just to be clear, do you mean full-dogma Rails tutorial write a bunch of trivial tests before writing code TDD?
sroussey 2y ago
The methodology is unconstrained as another way to put it. Which, indeed, is different from engineering where constraints are non-negotiable, and thus the methodology as well. I think a lot of people doing functional programming, as an example, enjoy the constraints and the discipline that it imbues on their craft.
- sunrunner 2y ago
  There is an incredibly large space for decisions and belief systems in software that are not evidence-based but that can all lead to programs (in the general sense) that all function and produce the same results while being internally very different. The _need_ to build higher-level abstractions to manage the complexity or verboseness required to do things from lower level components always seems to be fighting with the _desire_ to build your own higher-level abstractions that fit your own view of how things 'should be', despite many of the decisions going into this being abstract and not easily objectively measurable. On top of that, software components as 'reusable boxes' only seems to work up to a certain level. The idea seems to be that higher-level abstractions and reusable pieces are all nicely shaped square boxes that all perfectly fit inside other boxes, but the reality seems to be more that even the best reusable boxes aren't perfectly square, have weird edges, and themselves have to fit into larger non-square shapes with weird edges. And what are the weird sharp edges? Decisions that had to be made about solving a problem. Every higher-level software component is on some level a set of (mostly arbitrary, sometimes measured) decisions about how to take a set of lower level generic components and make something more specific with them. Libraries might assume a certain structure but leave choices for how they're composed to the user. Applications make many more decisions about how their components are used in order to provide a more specific tool. There is a move from genericity to specificity as you move up layers of components. And finally, software requirements change all the time, but the need to change is itself at odds with the requirement that problems are solved only by making hundreds of decisions that have to work together for a working solution but also may be difficult to undo. > the constraints and the discipline that it imbues on their craft. Perhaps the constraints and discipline here comes from a desire to move towards some kind of standard or expected way of structuring software, knowing from experience that the cognitive cost of making (and sometimes having to read and understand) all the arbitrary decisions mentioned above is actually quite high. (This itself also leads to the notion of 'best practices' which seemingly change too often to ever really be considered best).
jonfromsf 2y ago
You can hide ANYTHING with financial engineering. Like off-books liabilities, systemic risk ... anything.
- throwaway2037 2y ago
  This comment is weird, but typical of HN. Most of the off-balance-sheet shenanigans of pre-2008 world are gone. There is now a global regulator that covers all systemically important financial institutions, that also includes very large insurers. The world of financial engineering is much lower risk and higher transparency than pre-2008.
  - asdff 2y ago
    Must be why every company pays its fair share of taxes right?
    - eru 2y ago
      What do you mean by 'fair'? Different jurisdictions have different tax rates.
      - asdff 2y ago
        You say shenanigans don't really happen, I posit they are routine in business and consultants are paid a lot of money to uncover the next shenanigan every day. The law is always lagging the action it is designed to stymie and we certainly don't have a utopia going on outside the window today.
        eru 2y ago
        > You say shenanigans don't really happen, [...] Where did I say that? There are definitely people who straight up break the relevant laws and don't pay their taxes. Of course, whether someone breaks a law or not, is an issue independent of 'fairness'. But I don't know what you mean by 'fair'.
magicalist 2y ago
> Code by comparison lives in hyperbolic space [0] and you can hide _anything_ in such a space without it being obvious Eh, you can also create a bijection between all programs and the natural numbers, so I don't think this analogy gives much insight. It's also silly to think that structural engineers or whatever only have to worry about where to place indistinguishable cubes in 3d space at a single moment in time and move on to the next job. This honestly comes off as the kind of masturbatory rhetoric the GP seemed to be talking about.
- throw1111221 2y ago
  I personally though it was a very interesting analogy. Let's take a made up example of a structural engineer designing a building. As another comment mentioned, in theory the design space here is enormous. Just the concrete mix can be endlessly optimized. But here there's a large monetary cost tradeoff that's obvious to everyone involved. Say an overenthusiastic junior proposes attempting to rediscover ancient Roman concrete mix for this project. Everyone from the other engineers to management can call that out as absurd. In theory you can make the building out of anything. But in practice the economics of producing real world components only allows for a few choices in each stage of the design. Meanwhile, software components are essentially free, especially if they're open source. Just clone the repo, hook up the code and you're done, right? So surprisingly often, the overenthusiastic junior can convince the whole company to build the new feature with some obscure framework that'll be unsupported in a few years. And no one can reliably call them out, because there's no easy, objective way to measure something like tech debt. (Another compounding problem is the rapid growth of the software field. Juniors are minted faster than they can be trained.) To make the software example more concrete: there's an internal config language "blub" in one of the FAANGs that someone designed in two months. It looked simple, gained a lot of adoption quickly. Fast forward 5 years, and it turns out using blub was a big mistake. It scales terribly, the semantics were badly thought out and cause subtle bugs everywhere. But here's the kicker: there are now millions of lines of blub. Over the next decade, the company makes several very expensive attempts to replace blub and fails. Blub continues to underpin their production infra to this day. So to sum up, I think maybe the core issue is not so much "3d space versus hyperbolic space". If you view the space as the tree of decisions you need to make to reach the goal, all engineers are working in hyperbolic space. However, when designing real world things, economics rapidly culls the design tree. Buying materials requires cash up front. But in software it's often the opposite: you get the libraries "for free", and the unmeasurable tech debt accrues over time.
gerdesj 2y ago
"All other engineering disciplines are ultimately limited to building things in (at most) 3 euclidean dimensions." Trying to diminish engineering disciplines that have existed for millennia by imposing an arbitrary constraint of "3 euclidean" is pretty wank. Let's drop silly constraints. Do you have any idea how complicated concrete is? It's just sand, aggregate, cement and water. Exothermic reaction. Job done. Let's look at wood ... the stuff is a bundle of fibres and stuff and yet we build huge structures out of it. Who on earth knows how or why plywood works? Britain had several all wooden aircraft during WWII - the Mosquito was so good that Herman Goering declared that it was worth two kills. Steel - its just iron with other stuff. Software engineering is growing up gradually but please don't be a dick towards people who practice disciplines that invented things and concepts you rely on and live within. For example the concept of a token that allows you to do something exclusively - " exclusive lock" - was popularised by early railways. A single track should have only one train on it and after a few accidents the idea of an exclusive token was "invented" that could be passed across to the next exclusive user. When you say hyperbolic, you should be aware of how close that is to hyperbole.
- noosphr 2y ago
  Not sure where you're getting that from my post. The point is that all other engineering disciplines don't have enough design space to make a true mess of their projects. Software by comparison hasn't been limited in its design space since the first super computers started having gigabytes of ram memory in the late 1980s. That doesn't mean that either discipline is better or worse, it means they are different. Other than math there is no other field which has as much freedom when it comes to basic design choices as software engineering, and math proofs are even more of a mess than software programs, to the point that pretty much every non-formally verified proof is wrong in some way. Or to put another way: would railways be more or less complex if we allowed them to be embedded in a higher dimensional space instead of being essentially a 2d network on the earth surface? If you don't think so I'd like you to think about what a train schedule would look like on hyper graphs: https://en.wikipedia.org/wiki/Hypergraph https://en.wikipedia.org/wiki/Hypergraph
  - callc 2y ago
asdff 2y ago
Both software and physical engineering can hide junk. It just depends on who is looking. There are plenty of products made that are junk. If you start to understand how products actually come to fruition in the business world, you will see that most of what we buy or sell or see marketed is actually junk. This is because engineering both in software and in the physical world is rarely, if ever, incentivized to seek out a perfectly optimal solution. What is able to generate profit sufficiently over costs, today with today's economic context, is what ends up getting shipped in both cases. That might change tomorrow and suddenly the product is not viable due to the costs of the junk associated with it. We talk about legacy code and how it is junk we are beholden to, go ahead and look at the engineering behind car designs and you will see there are legacy engines, legacy car platforms that people are similarly beholden to no different than legacy code people are afraid to touch. And that is just that one sector. Legacy engineering is present in everything you can conceive of due to the fact no one is paid to go off into the woods and optimize optimize optimize, only to ship by a deadline even if it a stinking pile of you know what. That is for sales to figure out.
AxEy 2y ago
>There's the folklore about half of all math papers giving the wrong proof for the right conclusion. Sorry, what? This is an extraordinary claim.
p_v_doom 2y ago
I do agree that you can hide a lot of shit in code. But I think something often overlooked is that code is simply text, and we have general rules on how to write good text. Code is in the end of the day basically applied philosophy and expression of ideas. If you do not have the experience and skill to express your ideas in text in a clear and concise, you will struggle to write good code (and vice versa tbf).And coders generally are lacking on the more humanities side of their educations.
deadfoxygrandpa 2y ago
actually, if you really think about it, my source code is only laid out in 2 dimensions. thats even fewer than mechanical engineers have to work with!
- beryilma 2y ago
  One might even argue that a Turing Machine (computers) is really one dimensional.
vonneumannstan 2y ago
You'd probably be shocked by the amount of junk hiding in the design of the F-35 for example. Complex Systems in 3-d are still complex.
DrScientist 2y ago
I do agree that software is by far the most complex things humans have created and much of that complexity is hidden. Case in point - more than one Mars mission has failed due to software errors. However you could argue that the best way to deal with that complexity is not to have a brilliant mind that can grok more of that complex space, but by simply taking good engineering practices to minimise and manage it - ultimately the complexity is beyond us all if not managed.
jhanschoo 2y ago
Software is different. Software is ultimately limited to building things in a space that is only countably infinite. There is only so much junk you can hide in a space that is only countably infinite. All other engineering disciplines by comparison deal in a space that is uncountably infinite and you can hide _anything_ in such a space without it being obvious. This is exemplified by the unpleasant discovery all of us have had of a supposedly measurable "collection" of intervals having such weird holes all over the real number line and the near impossibility of shifting it up or down that makes sense for it without having to rethink our whole notion of measure and still end up with something like the counting measure that definitely doesn't make sense. People, including myself, have a seriously bad intuition just how much volume there is in an uncountably infinite space.
never_inline 2y ago
Hyperbolic space indeed.
clownpenis_fart 2y ago
[dead]
boomlinde 2y ago
> All other engineering disciplines are ultimately limited to building things in (at most) 3 euclidean dimensions. There is only so much junk you can hide in a finite volume of space. I think that you have a basic grasp of the word "dimension" but use the word "euclidean" without understanding what it means just because you heard it in conjunction with "dimension". If you think that e.g. building a bridge is a three dimensional problem in the sense that you are actually talking about (which has nothing to do with euclidean geometry), you lack the basic understanding of what you are talking about from which you could draw any conclusion like that with any sense of intellectual honesty.

tkahnoski 2y ago

I think maybe this misses the mark. Yes software can lead to unbounded complexity unlikely many physics based engineering disciplines. However, at the end of the day, there is an input and output and compute and memory needed to run the thing and if we look at that we realize, we never actually left the bounded physical realm and we can still engineer software systems against real world constraints. We can judge its efficiency and breaking points. What's very different is the cost to change the system to do something new and that's where this unbounded complexity blows up in our face.

noosphr 2y ago
>However, at the end of the day, there is an input and output and compute and memory needed to run the thing and if we look at that we realize, we never actually left the bounded physical realm and we can still engineer software systems against real world constraints. We can judge its efficiency and breaking points. This is a common sense view of computation that's unfortunately wrong. The simplest counter example is the busy beaver program: with as little as 12 states we have saturated the computational capabilities of the universe, but it looks completely safe and sane for the first few states you would be testing against. You may call it pathological, and you'd be right, but the point is that you never know under which rug a function that takes more computation than the universe can supply is hiding. By comparison power electronics engineers don't have to formally prove that they didn't accidentally include a nuclear power plant in their e-scooter design.
- magicalist 2y ago
  And then you quickly find out that the turing machine on your lap doesn't actually have infinite tape. Do you honestly believe that there's no other human endeavor where you can DoS yourself? If on the other hand you're speaking of the theoretical computational needs of the program you just wrote, then your earlier dismissal of mathematics and its "even worse track record" is all the sillier.
- tkahnoski 2y ago
  I think you just made my point. If designing an eScooter you'd look at available power needed across the problem space. Even more so you might put in a safety features like a temperature monitor so electronic components don't fail because someone decided to go up a steep 12 mile mountain path and overheat the battery. If I was designing a software system, I could introduce a time constraint. An imagined conversation: "How long will it take to get an answer? Between half a second and the heat death of the universe. OK. Can we just issue a timeout error after 1 second?" This is putting controls in place so the system doesn't exceed its constraints and although hypothetical it might be able to do a job for any input, it can't because we haven't been able to find a more efficient solution for certain known and unknown scenarios.

shafyy 2y ago

I don't know, man. Your comment is neither here nor there.

knowsuchagency 2y ago

Disagree. What makes software unique to other engineering disciplines is that it isn't a discipline at all. What makes software so great is how quick the iteration cycles are. Software sits at a higher abstraction level than physical hardware, so much of our time is spent throwing at the wall and seeing what sticks because that's often (although not always) the best use of time.

threatofrain 2y ago
There is a discipline, it's just very fast-growing. Many techniques remain and become classics, it just takes awhile to realize what is fad vs classical.
- sunrunner 2y ago
  Can you give some examples of things you'd consider fads versus classical in software?
  - TylerE 2y ago
    TDD. Agile.
    - throwaway2037 2y ago
      I would disagree about TDD. I am continuously surprised when I learn that yet another one of my teammates practices TDD. TL;DR: TDD is dead; long live TDD. I think that TDD will remain viable in enterprise programmer for decades, perhaps permanently, thanks to "vibe-coding", where LLMs eventually produce most code for CRUD projects (the vast majority of enterprise programming).
      - TylerE 2y ago
        Just to be clear, do you mean full-dogma Rails tutorial write a bunch of trivial tests before writing code TDD?

sroussey 2y ago

The methodology is unconstrained as another way to put it. Which, indeed, is different from engineering where constraints are non-negotiable, and thus the methodology as well. I think a lot of people doing functional programming, as an example, enjoy the constraints and the discipline that it imbues on their craft.

sunrunner 2y ago
There is an incredibly large space for decisions and belief systems in software that are not evidence-based but that can all lead to programs (in the general sense) that all function and produce the same results while being internally very different. The _need_ to build higher-level abstractions to manage the complexity or verboseness required to do things from lower level components always seems to be fighting with the _desire_ to build your own higher-level abstractions that fit your own view of how things 'should be', despite many of the decisions going into this being abstract and not easily objectively measurable. On top of that, software components as 'reusable boxes' only seems to work up to a certain level. The idea seems to be that higher-level abstractions and reusable pieces are all nicely shaped square boxes that all perfectly fit inside other boxes, but the reality seems to be more that even the best reusable boxes aren't perfectly square, have weird edges, and themselves have to fit into larger non-square shapes with weird edges. And what are the weird sharp edges? Decisions that had to be made about solving a problem. Every higher-level software component is on some level a set of (mostly arbitrary, sometimes measured) decisions about how to take a set of lower level generic components and make something more specific with them. Libraries might assume a certain structure but leave choices for how they're composed to the user. Applications make many more decisions about how their components are used in order to provide a more specific tool. There is a move from genericity to specificity as you move up layers of components. And finally, software requirements change all the time, but the need to change is itself at odds with the requirement that problems are solved only by making hundreds of decisions that have to work together for a working solution but also may be difficult to undo. > the constraints and the discipline that it imbues on their craft. Perhaps the constraints and discipline here comes from a desire to move towards some kind of standard or expected way of structuring software, knowing from experience that the cognitive cost of making (and sometimes having to read and understand) all the arbitrary decisions mentioned above is actually quite high. (This itself also leads to the notion of 'best practices' which seemingly change too often to ever really be considered best).

jonfromsf 2y ago

You can hide ANYTHING with financial engineering. Like off-books liabilities, systemic risk ... anything.

throwaway2037 2y ago
This comment is weird, but typical of HN. Most of the off-balance-sheet shenanigans of pre-2008 world are gone. There is now a global regulator that covers all systemically important financial institutions, that also includes very large insurers. The world of financial engineering is much lower risk and higher transparency than pre-2008.
- asdff 2y ago
  Must be why every company pays its fair share of taxes right?
  - eru 2y ago
    What do you mean by 'fair'? Different jurisdictions have different tax rates.
    - asdff 2y ago
      You say shenanigans don't really happen, I posit they are routine in business and consultants are paid a lot of money to uncover the next shenanigan every day. The law is always lagging the action it is designed to stymie and we certainly don't have a utopia going on outside the window today.
      - eru 2y ago
        > You say shenanigans don't really happen, [...] Where did I say that? There are definitely people who straight up break the relevant laws and don't pay their taxes. Of course, whether someone breaks a law or not, is an issue independent of 'fairness'. But I don't know what you mean by 'fair'.

magicalist 2y ago

> Code by comparison lives in hyperbolic space [0] and you can hide _anything_ in such a space without it being obvious Eh, you can also create a bijection between all programs and the natural numbers, so I don't think this analogy gives much insight. It's also silly to think that structural engineers or whatever only have to worry about where to place indistinguishable cubes in 3d space at a single moment in time and move on to the next job. This honestly comes off as the kind of masturbatory rhetoric the GP seemed to be talking about.

throw1111221 2y ago
I personally though it was a very interesting analogy. Let's take a made up example of a structural engineer designing a building. As another comment mentioned, in theory the design space here is enormous. Just the concrete mix can be endlessly optimized. But here there's a large monetary cost tradeoff that's obvious to everyone involved. Say an overenthusiastic junior proposes attempting to rediscover ancient Roman concrete mix for this project. Everyone from the other engineers to management can call that out as absurd. In theory you can make the building out of anything. But in practice the economics of producing real world components only allows for a few choices in each stage of the design. Meanwhile, software components are essentially free, especially if they're open source. Just clone the repo, hook up the code and you're done, right? So surprisingly often, the overenthusiastic junior can convince the whole company to build the new feature with some obscure framework that'll be unsupported in a few years. And no one can reliably call them out, because there's no easy, objective way to measure something like tech debt. (Another compounding problem is the rapid growth of the software field. Juniors are minted faster than they can be trained.) To make the software example more concrete: there's an internal config language "blub" in one of the FAANGs that someone designed in two months. It looked simple, gained a lot of adoption quickly. Fast forward 5 years, and it turns out using blub was a big mistake. It scales terribly, the semantics were badly thought out and cause subtle bugs everywhere. But here's the kicker: there are now millions of lines of blub. Over the next decade, the company makes several very expensive attempts to replace blub and fails. Blub continues to underpin their production infra to this day. So to sum up, I think maybe the core issue is not so much "3d space versus hyperbolic space". If you view the space as the tree of decisions you need to make to reach the goal, all engineers are working in hyperbolic space. However, when designing real world things, economics rapidly culls the design tree. Buying materials requires cash up front. But in software it's often the opposite: you get the libraries "for free", and the unmeasurable tech debt accrues over time.

gerdesj 2y ago

"All other engineering disciplines are ultimately limited to building things in (at most) 3 euclidean dimensions." Trying to diminish engineering disciplines that have existed for millennia by imposing an arbitrary constraint of "3 euclidean" is pretty wank. Let's drop silly constraints. Do you have any idea how complicated concrete is? It's just sand, aggregate, cement and water. Exothermic reaction. Job done. Let's look at wood ... the stuff is a bundle of fibres and stuff and yet we build huge structures out of it. Who on earth knows how or why plywood works? Britain had several all wooden aircraft during WWII - the Mosquito was so good that Herman Goering declared that it was worth two kills. Steel - its just iron with other stuff. Software engineering is growing up gradually but please don't be a dick towards people who practice disciplines that invented things and concepts you rely on and live within. For example the concept of a token that allows you to do something exclusively - " exclusive lock" - was popularised by early railways. A single track should have only one train on it and after a few accidents the idea of an exclusive token was "invented" that could be passed across to the next exclusive user. When you say hyperbolic, you should be aware of how close that is to hyperbole.

noosphr 2y ago
Not sure where you're getting that from my post. The point is that all other engineering disciplines don't have enough design space to make a true mess of their projects. Software by comparison hasn't been limited in its design space since the first super computers started having gigabytes of ram memory in the late 1980s. That doesn't mean that either discipline is better or worse, it means they are different. Other than math there is no other field which has as much freedom when it comes to basic design choices as software engineering, and math proofs are even more of a mess than software programs, to the point that pretty much every non-formally verified proof is wrong in some way. Or to put another way: would railways be more or less complex if we allowed them to be embedded in a higher dimensional space instead of being essentially a 2d network on the earth surface? If you don't think so I'd like you to think about what a train schedule would look like on hyper graphs: https://en.wikipedia.org/wiki/Hypergraph https://en.wikipedia.org/wiki/Hypergraph
- callc 2y ago

asdff 2y ago

Both software and physical engineering can hide junk. It just depends on who is looking. There are plenty of products made that are junk. If you start to understand how products actually come to fruition in the business world, you will see that most of what we buy or sell or see marketed is actually junk. This is because engineering both in software and in the physical world is rarely, if ever, incentivized to seek out a perfectly optimal solution. What is able to generate profit sufficiently over costs, today with today's economic context, is what ends up getting shipped in both cases. That might change tomorrow and suddenly the product is not viable due to the costs of the junk associated with it. We talk about legacy code and how it is junk we are beholden to, go ahead and look at the engineering behind car designs and you will see there are legacy engines, legacy car platforms that people are similarly beholden to no different than legacy code people are afraid to touch. And that is just that one sector. Legacy engineering is present in everything you can conceive of due to the fact no one is paid to go off into the woods and optimize optimize optimize, only to ship by a deadline even if it a stinking pile of you know what. That is for sales to figure out.

AxEy 2y ago

>There's the folklore about half of all math papers giving the wrong proof for the right conclusion. Sorry, what? This is an extraordinary claim.

p_v_doom 2y ago

I do agree that you can hide a lot of shit in code. But I think something often overlooked is that code is simply text, and we have general rules on how to write good text. Code is in the end of the day basically applied philosophy and expression of ideas. If you do not have the experience and skill to express your ideas in text in a clear and concise, you will struggle to write good code (and vice versa tbf).And coders generally are lacking on the more humanities side of their educations.

deadfoxygrandpa 2y ago

actually, if you really think about it, my source code is only laid out in 2 dimensions. thats even fewer than mechanical engineers have to work with!

beryilma 2y ago
One might even argue that a Turing Machine (computers) is really one dimensional.

vonneumannstan 2y ago

You'd probably be shocked by the amount of junk hiding in the design of the F-35 for example. Complex Systems in 3-d are still complex.

DrScientist 2y ago

I do agree that software is by far the most complex things humans have created and much of that complexity is hidden. Case in point - more than one Mars mission has failed due to software errors. However you could argue that the best way to deal with that complexity is not to have a brilliant mind that can grok more of that complex space, but by simply taking good engineering practices to minimise and manage it - ultimately the complexity is beyond us all if not managed.

jhanschoo 2y ago

Software is different. Software is ultimately limited to building things in a space that is only countably infinite. There is only so much junk you can hide in a space that is only countably infinite. All other engineering disciplines by comparison deal in a space that is uncountably infinite and you can hide _anything_ in such a space without it being obvious. This is exemplified by the unpleasant discovery all of us have had of a supposedly measurable "collection" of intervals having such weird holes all over the real number line and the near impossibility of shifting it up or down that makes sense for it without having to rethink our whole notion of measure and still end up with something like the counting measure that definitely doesn't make sense. People, including myself, have a seriously bad intuition just how much volume there is in an uncountably infinite space.

never_inline 2y ago

Hyperbolic space indeed.

clownpenis_fart 2y ago

[dead]

boomlinde 2y ago

> All other engineering disciplines are ultimately limited to building things in (at most) 3 euclidean dimensions. There is only so much junk you can hide in a finite volume of space. I think that you have a basic grasp of the word "dimension" but use the word "euclidean" without understanding what it means just because you heard it in conjunction with "dimension". If you think that e.g. building a bridge is a three dimensional problem in the sense that you are actually talking about (which has nothing to do with euclidean geometry), you lack the basic understanding of what you are talking about from which you could draw any conclusion like that with any sense of intellectual honesty.