7 ms·

I would feel significantly more comfortable calling programming an art rather than science or Engineering. I was an engineer before switching to programming an

I would feel significantly more comfortable calling programming an art rather than science or Engineering. I was an engineer before switching to programming and despite throwing the word Software Engineer in my title, there is no Engineering. There is developing only. 'best practices' come from Authority, not science(note at bottom). This is a stark contrast to Engineering where everything is proven with math. (Note)We don't write in logic gates anymore, efficiency is obscure at modern coding levels.

MaxBarraclough 6y ago
> This is a stark contrast to Engineering where everything is proven with math. You've just described the field of formal methods. For software with strict requirements of correctness, correctness is sometimes proven mathematically. It's not that a rigorous approach to software development is impossible, it's more a question of when it's really worth doing. At present, formal methods are very costly to use. I don't think it's always necessary to go all the way to full formal verification for software development to count as rigorous, though. Related reading: They Write the Right Stuff, from 1996. [0] > efficiency is obscure at modern coding levels Depends on the domain. There are plenty of domains where efficiency doesn't much matter, on modern hardware. Game engines are still tuned for efficiency, and will continue to be. [0] https://www.fastcompany.com/28121/they-write-right-stuff https://www.fastcompany.com/28121/they-write-right-stuff
- marketingPro 6y ago
  To clarify, you cant know what is the most efficient path in Programming. You can modify and time, but you can't know ahead of time.
  - MaxBarraclough 6y ago
    I don't see the point here. It's quite possible to assess the performance of a game-engine.
    - marketingPro 6y ago
      Okay I'll explain one more time, maybe a second write will clarify. In Engineering, everything is defined with specifications and based on specifications you can calculate if something will work. If you need something to work at 100 degrees C but it will never get to 110C, you don't buy a material that works at 110C, you find the cheapest material that works at 101C. (Factor of safety aside) You can prove in math your design will work In Programming, unless you are working at switch levels, how could you prove your code is most optimized? It's not going to be. Abstraction has removed the possibility of doing that. The closest thing I've seen to Engineering in the Programming world is Industrial Engineering. This is the way Engineers optimize production environments. You can see this in Programming in various time/load aspects. But industrial engineering is an "After the fact", and as much as I like optimization, it has a reputation of not being Engineering. Hope that makes sense. Science and math vs optimization.
      - MaxBarraclough 6y ago
        > You can prove in math your design will work It's possible, but extremely labour-intensive, to mathematically prove the correctness of a program. I mentioned this in my previous comment. > In Programming, unless you are working at switch levels, how could you prove your code is most optimized? 'Most optimised' is an entirely different problem than 'your design will work'. Complexity theory lets us do something like this, but at a more abstract level, rather than at the level of real-world performance on a particular machine. As you say, real-world code is almost guaranteed not to be perfectly optimal in terms of performance. We really never need to aim for this though. Market forces push for high correctness and performance, to varying degrees across different different problem domains. Performance matters in game-engines and for high-frequency trading, and in those applications, the software engineers put in great effort to optimise their systems, using fewer abstractions. Sometimes the software engineering challenge may be a life-critical hard-real-time system, such as in medicine or aviation. Software engineers are able to deliver such systems. It's not of great concern that these systems aren't perfectly optimal in terms of their performance, provided the programs give the right outputs and always meet their deadlines. The generation of perfectly optimised code has been researched, branded superoptimisation, [0] but it's little more than an academic curiosity. I doubt it will ever be possible to scale it up to be practical for large programs. (I'm not sure if/how they deal with the way most modern processors are terribly complex and don't have easily predictable performance.) > Abstraction has removed the possibility of doing that. It's very often a sound decision to trade off on performance in order to gain on some other dimension, such as development velocity, or maintainability, or indeed correctness, given the project's resource constraints. As tools improve, the Pareto frontier advances, and we get a little closer to being able to 'have it all'. An example of this might be the use of Rust for web development work, which can apparently greatly improve performance (or greatly reduce the computational resources needed). It can bring the performance of C++, while retaining many of the advantages of safer, higher-level languages like Java and C#. Whether it does this well enough to really grain traction, we'll have to wait and see, but I think it's a good example. > The closest thing I've seen to Engineering in the Programming world is Industrial Engineering. Industrial engineering is an entirely different discipline than software engineering. For examples of 'proper software engineering', the obvious candidates are avionics (as discussed in the article I linked above), and development methodologies involving formal methods, such as with the Tokeneer project. [1][2] [0] https://en.wikipedia.org/wiki/Superoptimization https://en.wikipedia.org/wiki/Superoptimization [1] https://blog.adacore.com/tokeneer-fully-verifed-with-spark-2014 https://blog.adacore.com/tokeneer-fully-verifed-with-spark-2... [2] [Huge PDF] http://www.adacore.com/uploads/downloads/Tokeneer_Report.pdf http://www.adacore.com/uploads/downloads/Tokeneer_Report.pdf
  - IggleSniggle 6y ago
    If you are writing in an assembly language ie for a specific hardware architecture, why couldn’t you know the most efficient path ahead of time?

MaxBarraclough 6y ago

> This is a stark contrast to Engineering where everything is proven with math. You've just described the field of formal methods. For software with strict requirements of correctness, correctness is sometimes proven mathematically. It's not that a rigorous approach to software development is impossible, it's more a question of when it's really worth doing. At present, formal methods are very costly to use. I don't think it's always necessary to go all the way to full formal verification for software development to count as rigorous, though. Related reading: They Write the Right Stuff, from 1996. [0] > efficiency is obscure at modern coding levels Depends on the domain. There are plenty of domains where efficiency doesn't much matter, on modern hardware. Game engines are still tuned for efficiency, and will continue to be. [0] https://www.fastcompany.com/28121/they-write-right-stuff https://www.fastcompany.com/28121/they-write-right-stuff

marketingPro 6y ago
To clarify, you cant know what is the most efficient path in Programming. You can modify and time, but you can't know ahead of time.
- MaxBarraclough 6y ago
  I don't see the point here. It's quite possible to assess the performance of a game-engine.
  - marketingPro 6y ago
    Okay I'll explain one more time, maybe a second write will clarify. In Engineering, everything is defined with specifications and based on specifications you can calculate if something will work. If you need something to work at 100 degrees C but it will never get to 110C, you don't buy a material that works at 110C, you find the cheapest material that works at 101C. (Factor of safety aside) You can prove in math your design will work In Programming, unless you are working at switch levels, how could you prove your code is most optimized? It's not going to be. Abstraction has removed the possibility of doing that. The closest thing I've seen to Engineering in the Programming world is Industrial Engineering. This is the way Engineers optimize production environments. You can see this in Programming in various time/load aspects. But industrial engineering is an "After the fact", and as much as I like optimization, it has a reputation of not being Engineering. Hope that makes sense. Science and math vs optimization.
    - MaxBarraclough 6y ago
      > You can prove in math your design will work It's possible, but extremely labour-intensive, to mathematically prove the correctness of a program. I mentioned this in my previous comment. > In Programming, unless you are working at switch levels, how could you prove your code is most optimized? 'Most optimised' is an entirely different problem than 'your design will work'. Complexity theory lets us do something like this, but at a more abstract level, rather than at the level of real-world performance on a particular machine. As you say, real-world code is almost guaranteed not to be perfectly optimal in terms of performance. We really never need to aim for this though. Market forces push for high correctness and performance, to varying degrees across different different problem domains. Performance matters in game-engines and for high-frequency trading, and in those applications, the software engineers put in great effort to optimise their systems, using fewer abstractions. Sometimes the software engineering challenge may be a life-critical hard-real-time system, such as in medicine or aviation. Software engineers are able to deliver such systems. It's not of great concern that these systems aren't perfectly optimal in terms of their performance, provided the programs give the right outputs and always meet their deadlines. The generation of perfectly optimised code has been researched, branded superoptimisation, [0] but it's little more than an academic curiosity. I doubt it will ever be possible to scale it up to be practical for large programs. (I'm not sure if/how they deal with the way most modern processors are terribly complex and don't have easily predictable performance.) > Abstraction has removed the possibility of doing that. It's very often a sound decision to trade off on performance in order to gain on some other dimension, such as development velocity, or maintainability, or indeed correctness, given the project's resource constraints. As tools improve, the Pareto frontier advances, and we get a little closer to being able to 'have it all'. An example of this might be the use of Rust for web development work, which can apparently greatly improve performance (or greatly reduce the computational resources needed). It can bring the performance of C++, while retaining many of the advantages of safer, higher-level languages like Java and C#. Whether it does this well enough to really grain traction, we'll have to wait and see, but I think it's a good example. > The closest thing I've seen to Engineering in the Programming world is Industrial Engineering. Industrial engineering is an entirely different discipline than software engineering. For examples of 'proper software engineering', the obvious candidates are avionics (as discussed in the article I linked above), and development methodologies involving formal methods, such as with the Tokeneer project. [1][2] [0] https://en.wikipedia.org/wiki/Superoptimization https://en.wikipedia.org/wiki/Superoptimization [1] https://blog.adacore.com/tokeneer-fully-verifed-with-spark-2014 https://blog.adacore.com/tokeneer-fully-verifed-with-spark-2... [2] [Huge PDF] http://www.adacore.com/uploads/downloads/Tokeneer_Report.pdf http://www.adacore.com/uploads/downloads/Tokeneer_Report.pdf
- IggleSniggle 6y ago
  If you are writing in an assembly language ie for a specific hardware architecture, why couldn’t you know the most efficient path ahead of time?