This thread on Hacker News terrifies me

[Ola Fosheim Grøstad]

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).