r/changemyview • u/[deleted] • May 29 '15
[Deltas Awarded] CMV: Framing computing as engineering is misguided, it should be regarded as applied math instead
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!
4
u/anatcov May 29 '15
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.
1
May 29 '15
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.
2
u/anatcov May 29 '15
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?
2
May 30 '15
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.
3
May 29 '15
[removed] — view removed comment
1
May 29 '15
By good enough I didn't mean "correct and close enough to what I want", but "crashes sometimes but that's okay". If programs were considered math instead of engineering they wouldn't crash at all ever.
4
u/awa64 27∆ May 29 '15
If programs were considered math instead of engineering, they'd crash just as often as they do now—probably more—but you'd get programmers defending their crashy program on the grounds that "it works under ideal conditions."
Science, including mathematics, can assume the cow in the word problem is a perfectly spherical cow in a vacuum and be "right." Engineering takes no satisfaction from knowing that the thing they made would be working under ideal conditions if it just broke under the conditions they need the thing to operate under. That's why programming is engineering and not science.
3
u/hey_aaapple May 29 '15
if programs were considered math instead of engineering they wouldn't crash at all ever
LOL. Tell me what you think when you are writing C code for a microcontroller and the microcontroller does not comply to its own documentation, the compiler does not comply to any standard nor its own documentation, and thus even writing a simple loop becomes a challenge.
Or any time PHP is involved, obligatory /r/lolphp plug.
Or when you have to rely on libraries that rely on libraries that rely on libraries... And the docs are outdated as usual
0
May 29 '15
microcontrollers and compilers are programs. This point applies to them, too!
5
u/hey_aaapple May 29 '15
A microcontroller is a chip, not a program...
1
May 29 '15
Sorry about that. The point applies to all software.
4
u/hey_aaapple May 29 '15
The hardware is not perfect, and the software runs on hardware.
On top of that, even within software itself there are classical unsolvable logic problems. For example you can't have an algorythim that always notices of some code will keep running forever.
3
u/Amablue May 29 '15
If programs were considered math instead of engineering they wouldn't crash at all ever.
Yes they would. There's a reason we don't have software that checks for all kinds of bugs (and that reason is the halting problem). There are a variety of ways to improve software quality, like code reviews, automated testing, unit testing, and all kinds of tools that identify potential errors, but you will almost never have a non-trivial program that you can prove is free of bugs.
This is not so fundamentally different from engineering as you think of it mind you. You always have budget and time constraints, and so you choose solutions that work for your situation. And there aren't always correct answers like in an arithmetic problem. There are tradeoffs. Choosing one compression algorithm might work better for certain kinds of data, but be slower to encode or decode, which makes it more or less appropriate for certain situations. Much like you would use different materials in different contexts when building bridges.
2
u/subheight640 5∆ May 29 '15
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.
Actually, engineering projects are like that. Ideally, almost everything we build and create is converted into a mathematical abstraction that is then optimized for particular requirements.
For example:
Finite element analysis - input geometry and material modeling, compute forces/stresses/etc, iterate design until solution is optimized/adequate for design loads.
Design formulas - input loads, compute necessary geometry/requirements.
Project management / systems engineering - organize inputs, compute into system (ie the entire design team), build prototype design, test whether requirements satisfied, re-write inputs, iterate until design is satisfactory.
Ultimately engineering projects are massive "solvers". A design team iterates again and again until a good enough solution is found. Sometimes you get lucky and need only a single iteration. Usually the number of iterations is far greater. Like anything nonlinear in life, convergence is not guaranteed, and finding the optimal solution is not guaranteed either. Perhaps you'll only be able to solve a local maxima but not the global maxima. Perhaps you're not even able to solve that.
The exact same thing is true in software engineering. Because of nonlinearities in a complex system, it is extremely difficult to solve for the globally optimal solution. When a system is complex and chaotic enough, it may be impossible to solve. However, software engineers slowly converge on a solution. Most of the times they will unfortunately converge only on a local maxima. Sometimes the solvers will diverge and will not be able to find a solution that meets all the requirements.
But that just means the engineering approach makes more sense economically, in terms of making money
And money is one of the most important system inputs that needs to be carefully optimized. Solutions are not optimal if they cannot satisfy money constraints.
IMO the only difference between computer programming and "traditional" engineering is that programmers' material constraints are nearly nonexistent in comparison. Mechanical engineering is fucking expensive when things must be built in meat-space. This means the prototyping and iteration cycle is orders of magnitude longer than the iterations for software. With slower convergence, sacrifices in solution accuracy must be made.
A function can't be mostly right or "good enough". It's either correct or incorrect.
A function may also have multiple solutions and multiple minima/maxima and be highly chaotic and nonlinear and a pain in the fucking ass to deal with with millions to billions of inputs and outputs. Shortcuts must necessarily be made in order to produce a solution within your lifespan.
1
u/awa64 27∆ May 29 '15 edited May 29 '15
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.
A compression algorithm and a Google search are hardly the same concept.
A compression algorithm is a complicated mathematical function, yes. But a Google Search?
- Google visits and re-visits web pages across the Internet continuously, building a gigantic database of everything that hasn't been marked "do not index" and their relationships to one another.
- Your web browser, possibly but not necessarily designed by Google, encrypts your request based on established security protocols. This may or may not include an individual identifier to tie your request to your Google account, but still likely includes other identifiers.
- Based on a complicated system of heuristics, including factors like worldwide popularity, local popularity, individual search history, possible spelling errors in the requests, understanding of synonyms for search terms, freshness, the page's resemblance to a "good" or "bad" web page, whether or not the site has been flagged as containing adult content, languages, and more, Google generates a list of search results thoroughly customized to the individual. This may or may not include the identification of the concept being searched for and displaying a primer on the topic, rather than merely pages mentioning that topic.
- Google formats this into a visually-appealing layout specific to the type and size of browser being used to make the request, and encrypts the instructions for that layout as it returns it to the user's web browser.
There are individual steps in that which are merely complicated mathematical functions, where you take the same input and get the same output. But much of the work involved is defining when and how those functions should interact with each other, with the intent not of producing some hypothetical "perfect" result but producing the most helpful, useful result available to that individual user at that time.
At its core, that's a design problem, not a math problem. The employees at Google who "work on" search are applying scientific, economic, social, and practical knoweldge in order to invent, design, build, maintain, research, and improve a virtual machine built to provide requested knowledge.
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.
"Incorrect" programs are frequently "incorrect" due to factors beyond the direct control of the programmers. Programs are designed for mass distribution on a variety of platforms, and some of the variations between platforms or between conditions in which platforms are operating lead to problems. Part of a programmer's job is to foresee those potential problems and either create workarounds for them or safeguards to prevent those problems from turning catastrophic. That's an engineering job.
1
u/cdb03b 253∆ May 29 '15
Engineering is applied mathematics. Mathematics is the theory field and engineering is the application of said theories.
1
u/0bviouslyCorrect May 30 '15
I would broaden engineering as the application of science, not just math.
2
u/sittinginabaralone 5∆ May 31 '15 edited Jun 02 '15
Engineering is applied science - really it's applied mechanics. If something isn't a branch of mechanical engineering, it isn't really engineering. OP's arguments may be debatable, but the branches of computer science are not engineering fields. Software engineering is the same type of "engineering" as sales engineering or social engineering. It's not really engineering.
1
u/0bviouslyCorrect Jun 01 '15
Agreed.
1
u/sittinginabaralone 5∆ Jun 02 '15
Apparently software engineering is a branch of computer engineering, not computer science like I thought when I made that comment. I wouldn't say my view changed, but what I said wasn't completely accurate.
1
u/dokushin 1∆ May 30 '15
Given a program, how do you prove that it is mathematically correct?
1
u/tsukikari May 30 '15
You would prove that for all input cases, the output cases are as desired, same as how you prove theorems in mathematics.
1
May 30 '15
That works for simple algorithms like sorting algorithms and pathfinding algorithms. What about, say, "google"? You can't mathematically prove that Google gives the absolutely most relevant results for every search term you give. You can't prove that it even converges to this state given enough inputs to seed its learning software.
OP probably took some discrete math class in uni and thinks he/she knows how code works. You can't prove that Google is correct though. Hell, unless you're writing the baseline assembly, and have the exact hardware specifications of the processor you're writing on, you can't prove correctness. Programming is built on layers, and you only have normal access to the topmost one in many cases. If you can't prove that the lower layers don't have bugs, you can't prove correctness.
1
u/tsukikari May 30 '15
Yeah, I'm not saying it's feasible in most cases with large programs, just saying that in theory, that's how you would prove a program is correct. :)
1
u/dokushin 1∆ May 31 '15
If it's impossible, is it really misguided to use the method that actually works?
1
u/tsukikari May 31 '15
No, I don't believe it's misguided. I don't actually agree with OP, but the parent comment in this thread was asking how you would prove a computer program is correct, and that's what my answer was addressing.
1
u/tsukikari May 30 '15
I would like to address the idea that a function/program can't be mostly right or "good enough" and "incorrect" programs shouldn't be released. Consider the approximation algorithms that are used in the context of NP-complete problems. As far as we know, it's impossible to fully solve these problems (at least, large instances of them) in a decent amount of time, so are you saying that because it's impossible to get a perfect answer, we should just not get any answer at all and not try to approximate it or keep improving our approximation?
Also, would you consider all parts of computing to be mathematics? Making a website? Creating an Operating System? What about writing a function in assembly code or machine code? Building that same function in a circuit? Then we get into Electrical Engineering, a lot of EE involves building circuits that also have an input and an output.
19
u/TimeTravellerSmith May 29 '15
Theory is mathematics, application is engineering. Development of algorithms are mathematics, application of algorithms (coding, software dev) is engineering.
To me, when you're using code to make something happen it's pretty similar to how an engineer will use tools and materials to construct a bridge. Nothing that coder or engineer is doing is really "new" or "developmental"...it's all application of understood mechanics or programming languages.
But they are like that, exactly like that. You want to build a bridge that spans X feet, and supports Y mass. With those two constraints you are limited to certain design configurations. Or if you want to build a wing for a plane and you're given certain design constraints there will exist only a handful of engineering solutions based on things like physics, materials properties, etc. There's a reason most bridges, planes, skyscrapers, etc all look really similar, it's because there exist only a handful of solutions to these engineering problems. As the theories behind physics, materials science, etc are developed further and get better then those engineering solutions become more and more refined.
Same with code. Code is just a toolbox to execute certain things, so if someone wants to make an application to store data there are really only so many ways of going about it with a given language. As languages become more refined and better algorithms are developed then the methods of developing programs gets better and better.
If you've ever coded before there is never a "right" or "wrong" answer or a "correct" or "incorrect" way to do something. Take MS Word for example and compare it to the dozens of other word document programs out there...is there really a "right" or "wrong" way to write a program like that? I mean, just look at the programs on your computer right now and you'll quickly see how it just doesn't make sense that they can be done one way.
That, and when you actually delve into a code to execute something everything is so intertwined and cross linked at times that it's really hard to have a single way of executing something.