On Friday, 31 August 2018 at 23:20:08 UTC, H. S. Teoh wrote:
The problem is that there is a disconnect between academia and the industry.
No, there isn't. Plenty of research is focused on software engineering and software process improvement. Those are separate research branches.
The problem is that most people in forums don't have a basic grasp of how improbable it is for complex systems to be bug free.
After taking a course where you formally prove a program to be bug free fix that problem real fast.
Also, asserts doesn't prevent bugs, they can trip hours or days after the problem arose. The problem doesn't have to be the code either, it could be the data-structure, how different systems interact etc. So, just running the buggy software is problematic, even before the assert trips. (E.g. your plane could be in flames before the assert trips.)
Also, having a shutdown because a search function sometimes return the wrong result is just as unacceptable as getting late to work because you couldn't drive your car because it "was asserted" that the clutch was not in perfect condition.
The goal in academia is to produce new research, to find ground-breaking new theories that bring a lot of recognition
Most research does not focus on ground-breaking theories, but marginal improvments on existing knowledge.
> continue existing. As a result, there is heavy focus on the
theoretical concepts, which are the basis for further research, rather than pragmatic tedium like how to debug a program.
All formalized knowledge that is reusable is theory. Everything you can learn from books is based on theory, unless you only read stories and distill knowledge from them with no help from the author.
There are of course people who build theory on how to structure, test and debug programs.
The goal in the industry is to produce working software.
NO, the goal is to make MONEY. If that means shipping bad software and getting to charge large amounts of money for consulting then that is what the industry will go for.
using the latest and greatest theoretical concepts. So they don't really care how good a grasp you have on computability theory, but they *do* care a lot that you know how to debug a program so that it can be shipped on time. (They don't care *how* you debug the program, just that you know how to to it, and do it efficiently.)
They don't care if it works well, they don't care if it is slow and buggy, they care about how the people who pay for it respond...
A consequence of this disconnect is that the incentives are set up all wrong.
Yes, money does not produce quality products, unless the majority of customers are knowledgable and demanding.
Professors are paid to publish research papers, not to teach students.
I think people publish most when they try to become professors. After getting there the main task is to teach others the topic and help others to do research (e.g. supervising).
> research. After all, it's the research that will win you the
grants, not the fact that you won teaching awards 3 years in a row, or that your students wrote a glowing review of your lectures. So the quality of teaching already suffers.
The have a salary, they don't need a grant for themselves. They need a grant to get a salary to fund ph.d. students. E.g. they need grants to teach how to do research.
Then the course material itself is geared toward producing more researchers, rather than industry workers.
Most of them become industry workers...
Is it any wonder at all that the quality of the resulting software is so bad?
The current shipping software is much better than the software that was shipped in the 80s and 90s. To a large extent thanks to more and more software being developed in high level languages using well tested libraries and frameworks (not C, C++ etc).
Most cars on the road are somewhat buggy, and they could crash as a result of those bugs. Most programs are somewhat buggy, and they could crash as a result of those bugs.
Most of the buggy air fighters are on the ground, but would you want you car to be unusable 20% of the time?
Would you want Google to disappear 20% of the time because the ranking of search results is worse than what the spec says it should be?
As usual, these discussions aren't really based on a good theoretical understanding of what a bug is.
Try to prove one of your programs formally correct, then you'll realize that it is unattainable for most useful programs that retain state.
The human body is full of bugs. Hell, we rely on them, even on the cell-level. We need those parasites to exist. As programs get larger you need to focus on a different strategy to get a reliable system. (E.g. actor based thinking).
