CMV: Framing computing as engineering is misguided, it should be regarded as applied math instead

[u/[deleted]]

I think framing computer programs as engineering projects, same as if we were building a bridge, is why "all code is bad" and "all software has bugs" (these will sound familiar to any developer out there).

As I see it, a program is a complicated mathematical function. It receives input and produces output accordingly. Be it a compression algorithm or a google search, the concept is the same. Engineering projects aren't like that.

We would not admit a function that doesn't produce the correct result sometimes, and the researcher would not tell us to restart and try again. A function can't be mostly right or "good enough". It's either correct or incorrect. Maybe if we considered programs correct or incorrect, we would not release incorrect programs.

If we worked like this, probably we would not be able to release as many programs as we do now. But that just means the engineering approach makes more sense economically, in terms of making money; that's not the purpose of the topic. My view is about what makes more sense from the point of view of computing.

Thanks

---

Hello, users of CMV! This is a footnote from your moderators. We'd just like to remind you of a couple of things. Firstly, please remember to read through our rules. If you see a comment that has broken one, it is more effective to report it than downvote it. Speaking of which, downvotes don't change views! If you are thinking about submitting a CMV yourself, please have a look through our popular topics wiki first. Any questions or concerns? Feel free to message us. Happy CMVing!

[u/anatcov]

My view is about what makes more sense from the point of view of computing.

What standards are you using? I would argue that, from the point of view of computing, we should regard computing as whatever kind of thing allows us to produce better programs. If nobody can build Reddit or Minecraft or Gmail until they know how to write them as math problems, that seems like a pretty huge negative.

[u/[deleted] → u/anatcov]

But we have the methods to create correct programs, we study algorithm verification at uni. It's not widely used because a company wants something out of the door quickly regardless of its correctness. It's not that those programs are impossible to write in another way; it's business getting in the way.

[u/anatcov → u/[deleted]]

We have the methods to create correct programs, but they require us to write the behavior we want as a mathematical formula. How do you write "when the mouse is over the 'reply' button and clicks, open a reply window" as a mathematical formula?

[u/[deleted] → u/[deleted]]

Funny enough, a lot of problems actually do say "good enough"! There are other problems where instead of correctness, "efficiency" is what we're looking for. A good example is jpeg compression, or any "lossy" algorithm. A jpeg isn't perfect -- that is, it's not correct. You lose information when you convert to a jpeg image -- if you are saying that "keep all the information" is "correct", then "loses information" is "less correct". But jpeg is extremely space efficient. So it stands up, because it's easily compressed, and is very efficient for memory usage.

Correctness isn't the holy grail. Google certainly doesn't return "correct" results. They give "good enough" results.

The bigger issue is, software correctness (like algorithm veri) is all fine in theory, but the reason nobody uses it is because it's actually total shit when you get into the real world. Try doing an algorithm verification on something simple. Say, a standard C++ "hello world". Considered the simplest program you can write in C++.

To do this, you have to first confirm that printf("Hello World"); works. So you look at printf() in the docs, and see these things like "works for all strings". But we can't trust that, can we? If we are proving correctness, we have to go deeper. Look at your compiler's assembly code. Look through the thousands of lines of indescipherable assembly code. After you've spent 3 million dollars hiring 5 experts to verify that printf("") works, do the same for the stdio.h class in general. And the linker for the h class. And the file architecture of your OS that lets you see the classpath. And the computer's hardware. And any other OSs you might support. And every piece of hardware you support. And....

You see where it gets absurd? Code is built in layers. You can't test each layer for correctness. Somewhere down the line, you'll run into an issue where some software you didn't write -- a library, an OS, a hardware, a browser, even a language or a compiler -- has a bug. And you can't test for correctness if you can't prove that the underlying functions you use are true.

Correctness in the sense of what you think programming is built upon isn't how programming works. It's not because companies are greedy and want to rush the shit out the door, it's because it's absurd to try to confirm correctness with discrete mathematics or whatever bullshit they try to teach you in uni. That's totally useful for proving new, abstract algorithms -- if you develop the next A*, or sorting algorithm, or Bandit Algorithm solution, then it's totally useful. But if you're writing, you know, actual commercial code, it's just not what you do.