Then there are polytechnics which I went to for my degree, where the focus was squarely on Industry and not on academia at all.

But in saying that, we had third year students starting out not understanding how cli arguments work so...

Proper software engineering really takes 5+ years just to get started, 10+ to become actually good at it. Sadly that won't be acceptable in our current society.

On 01/09/2018 12:40 PM, tide wrote:
> On Friday, 31 August 2018 at 22:42:39 UTC, Walter Bright wrote:
>> On 8/31/2018 2:40 PM, tide wrote:
>>> I don't think I've ever had a **game** hung up in a black screen and not be able to close it.
>>
>> I've had that problem with every **DVD player** I've had in the last 20 years. Power cycling is the only fix.
> 
> Two very different things, odds are your DVD players code aren't even written with a complete C compiler or libraries.

And yet they manage to run a JVM with Java on it.

It all comes down to, not enough time to cover the material.

Programming is the largest scientific field in existence. It has merged material from Physics, Chemistry, Psychology (in a BIG WAY), Biology, you name it and that ignores Mathematics.

Three to four years is just scratching the surface of what is needed to be known. There is simply no way to ignore that fact.

On Saturday, 1 September 2018 at 05:51:10 UTC, rikki cattermole wrote:
> Then there are polytechnics which I went to for my degree, where the focus was squarely on Industry and not on academia at all.

But the teaching is based on research in a good engineering school...

> But in saying that, we had third year students starting out not understanding how cli arguments work so...
>
> Proper software engineering really takes 5+ years just to get started, 10+ to become actually good at it. Sadly that won't be acceptable in our current society.

The root cause of bad software is that many programmers don't even have an education in CS or software engineering, or didn't do a good job while getting it!

Another problem is that departments get funding based on how many students they have and many students are not fit to be programmers. Then you have the recruitment process and people in management without a proper theoretical understanding of the topic looking for "practical programmers" (must have experience with framework X) which basically means that they get programmers with low theoretical understanding and therefore fail to build an environment where people can learn... So building a good team where people can become experts (based on actual research) is mostly not happening. It becomes experience based and the experience is that it isn't broken if customers are willing to pay.

Basic capitalism. Happens outside programming too. Make good-looking shit that breaks after the warranty is void.

Anyway, Software Engineering most certainly is a research discipline separate from CS and there is research and theory for developing software at different cost levels.

Games are not bug free because that would be extremely expensive, and cause massive delays in shipping which makes it impossible to plan marketing. Games are less buggy when they reuse existing frameworks, but that makes for less exciting designs.

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

On Friday, 31 August 2018 at 22:23:09 UTC, Walter Bright wrote:
> On 8/31/2018 1:42 PM, Paulo Pinto wrote:
>> Some countries do have engineering certifications and professional permits for software engineering, but its still a minority.
>
> That won't fix anything, because there is NO conventional wisdom in software engineering for how to deal with program bugs. I suspect I am the first to try to apply principles from aerospace to general engineering (including software).
>
> For example, in any CS program, are there any courses at all about this?

Yes, we had them on my degree, given that Portugal is one of those countries with engineering certifications for software engineering.

Certified degrees must comply with an expected level of quality, otherwise they aren't legally allowed to call themselves engineering degrees in informatics.

Now, what we don't have is the requirement of professional permit for everyone, unless one wants to make use of the title in public events or has the legal responsibility to sign off projects.

I expect other countries with engineering colleges to have similar situations.

--
Paulo

On Saturday, 1 September 2018 at 05:57:06 UTC, rikki cattermole wrote:
> It all comes down to, not enough time to cover the material.
>
> Programming is the largest scientific field in existence. It has merged material from Physics, Chemistry, Psychology (in a BIG WAY), Biology, you name it and that ignores Mathematics.
>
> Three to four years is just scratching the surface of what is needed to be known. There is simply no way to ignore that fact.

In many European countries it is 5 years for an engineering degree and 3 for polytechnic.

Then you had 2 years for Msc and up to 3 for Phd.

As of the EU normalization (Bologna), the 5 year degrees became a Msc one, because there were a few countries were a degree would take 3 years.

So on the countries where an engineering degree used to take 5 years, the universities started pushing for what they call "integrated Msc", meaning the same contents before Bologna, but with Msc title at the end.

On 8/31/2018 5:40 PM, tide wrote:
> On Friday, 31 August 2018 at 22:42:39 UTC, Walter Bright wrote:
>> On 8/31/2018 2:40 PM, tide wrote:
>>> I don't think I've ever had a **game** hung up in a black screen and not be able to close it.
>>
>> I've had that problem with every **DVD player** I've had in the last 20 years. Power cycling is the only fix.
> 
> Two very different things, odds are your DVD players code aren't even written with a complete C compiler or libraries.

Doesn't matter. It's clear that DVD player software is written by cowboy programmers who likely believe that it's fine to continue running a program after it has entered an invalid state, presumably to avoid annoying customers.

Newer DVD/Bluray players have an ethernet port on the back. I'd never connect such a P.O.S. malware incubator to my LAN.

On 8/31/2018 5:47 PM, tide wrote:
> I've already read them before. Why don't you explain what is wrong with it rather than posting articles.

Because the articles explain the issues at length. Explaining why your proposal is deeply flawed was the entire purpose I wrote them.


> You are just taking one line comments without even thinking about the context.

We can start with the observation that a fly-by-wire is not a fundamentally different system than a fully powered hydraulic system or even a pilot muscle cable system, when we're talking about safety principles.

There's nothing magic about software. It's just more complicated (a fact that makes it even MORE important to adhere to sound principles, not throw them out the window).

On 8/31/2018 7:28 PM, tide wrote:
> I'm just wondering but how would you code an assert to ensure the variable for a title bar is the correct color? Just how many asserts are you going to have in your real-time game that can be expected to run at 144+ fps ?

Experience will guide you on where to put the asserts.

But really, just apply common sense. It's not just for software. If you're a physicist, and your calculations come up with a negative mass, you screwed up. If you're a mechanical engineer, and calculate a force of billion pounds from dropping a piano, you screwed up. If you're an accountant, and calculate that you owe a million dollars in taxes on a thousand dollars of income, you screwed up. If you build a diagnostic X-ray machine, and the control software computes a lethal dose to administer, you screwed up.

Apply common sense and assert on unreasonable results, because your code is broken.