On 8/31/2018 2:21 PM, tide wrote:
> On Friday, 31 August 2018 at 19:50:20 UTC, Walter Bright wrote:
>> "Stopping all executing may not be the correct 'safe state' for an airplane though!"
> Depends on the aircraft and how it is implemented. If you have a plane that is fly by wire, and you stop all executing then even the pilot no longer has control of the plane anymore, which would be very bad.

I can't even read the rest of posting after this.

Please read the following articles, then come back.

Assertions in Production Code
https://www.digitalmars.com/articles/b14.html

Safe Systems from Unreliable Parts
https://www.digitalmars.com/articles/b39.html

Designing Safe Software Systems Part 2
https://www.digitalmars.com/articles/b40.html

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.

On Friday, August 31, 2018 4:23:09 PM MDT Walter Bright via Digitalmars-d 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?

There are probably some somewhere, but most CS programs really aren't about writing good software or even being a software engineer. Some definitely try to bring some focus on that, but it's far, far more common that the focus is on computer science concepts and not on software engineering. A good CS program gives you a lot of theory, but they're rarely big on the practical side of things. I think that it's a rarity for programmers to graduate college with a good understanding of how to be a good software engineer in the field. That's the sort of thing that they're much more likely to learn on the job, and plenty of jobs don't do a good job with it. Motivated programmers can certainly find resources for learning good software engineering skills and/or find mentors who can help them learn them - and many programmers do - but it's _very_ easy to learn enough programming to get a job and get by without being very good at it. And if a programmer isn't really motivated to improve themselves, it's highly unlikely that they're going to have good software engineering skills. It's often pretty scary how poor the average programer is, and in my experience, when trying to hire someone, you can end up going through a lot of really bad candidates before finding someone even passable let alone good.

- Jonathan M Davis

On Fri, Aug 31, 2018 at 04:45:57PM -0600, Jonathan M Davis via Digitalmars-d wrote:
> On Friday, August 31, 2018 4:23:09 PM MDT Walter Bright via Digitalmars-d wrote:
[...]
> > 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?
> 
> There are probably some somewhere, but most CS programs really aren't about writing good software or even being a software engineer. Some definitely try to bring some focus on that, but it's far, far more common that the focus is on computer science concepts and not on software engineering. A good CS program gives you a lot of theory, but they're rarely big on the practical side of things.
[...]
> It's often pretty scary how poor the average programer is, and in my experience, when trying to hire someone, you can end up going through a lot of really bad candidates before finding someone even passable let alone good.
[...]

The problem is that there is a disconnect between academia and the industry.

The goal in academia is to produce new research, to find ground-breaking new theories that bring a lot of recognition and fame to the institution when published. It's the research that will bring in the grants and enable the institution to 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.

The goal in the industry is to produce working software. The industry doesn't really care if you discovered an amazing new way of thinking about software; they want to actually produce software that can be shipped to the customer, even if it isn't 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.)

A consequence of this disconnect is that the incentives are set up all wrong.  Professors are paid to publish research papers, not to teach students.  Teaching is often viewed as an undesired additional burden you're obligated to carry out, a chore that you just want to get over with in the fastest, easiest possible way, so that you can go back to doing 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.

Then the course material itself is geared toward producing more researchers, rather than industry workers.  After all, the institution needs to replace aging and retiring faculty members in order to continue existing.  To do that, it needs to produce students who can become future researchers.  And since research depends on theory, theory is emphasized, and pragmatism like debugging skills aren't really relevant.

On the other side of the disconnect, the industry expects that students graduating from prestigious CS programs ought to know how to program. The hiring manager sees a degree from MIT or Stanford and is immediately impressed; but he doesn't have the technical expertise to realize what that degree actually means: that the student excelled in the primarily theory-focused program, which may or may not translate to practical skills like programming and debugging ability that would make them productive in the industry.  All the hiring manager knows is that institution Y is renowned for their CS program, and therefore he gives more weight to candidates who hold a degree from Y, even if that actually doesn't guarantee that the candidate will be a good programmer. As a result, the software department is filled up with people who are good at theory, but whose practical programming skills can range anywhere from passably good to practically non-existent.  And now these people with wide-ranging programming abilities have to work together as a team.

Is it any wonder at all that the quality of the resulting software is so bad?


T

-- 
Amateurs built the Ark; professionals built the Titanic.

On Friday, August 31, 2018 5:20:08 PM MDT H. S. Teoh via Digitalmars-d wrote:
> A consequence of this disconnect is that the incentives are set up all wrong.  Professors are paid to publish research papers, not to teach students.  Teaching is often viewed as an undesired additional burden you're obligated to carry out, a chore that you just want to get over with in the fastest, easiest possible way, so that you can go back to doing 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 are plenty of cases where the teachers actually do an excellent job teaching the material that the courses cover. It's just that the material is often about theoretical computer science - and this is actually stuff that can be very beneficial to becoming an excellent programmer. However, many teachers really aren't great programmers. They aren't necessarily bad programmers, but unless they spent a bunch of time in industry before teaching, odds are that they don't have all of the software engineering skills that the students are going to need once they get into the field. And most courses aren't designed to teach students the practical skills. How that goes exactly depends on the school, with some schools actually trying to integrate software engineering stuff, but many really don't. So, even if the schools do an excellent job teaching what they're trying to teach, it still tends to be on the theoretical side of things. But that may be improving. Still, the theoretical side is something that programmers should be learning. It's just that it isn't enough on its own, and it serves more as a good foundation than as the set of skills that you're going to be using directly on the job on a day to day basis.

The school I went to (Cal Poly, San Luis Obispo) at least tries to focus on the practical side of things (their motto is "learn by doing"), and when I went there, they even specifically had a Software Engineering degree where you had to take a year-long course where you did a project in a team for a company. But at least at the time, the big difference between the SE and CS degrees was that they required more classes with group work and fewer theoretical classes, and there certainly weren't any classes on something like debugging. The software engineering-centric classes focused more on a combination of teaching stuff like classic design patterns and then having you do projects in groups. And that was helpful, but it still didn't really prepare you for what you were going to be doing in your full-time job. It's still better than what a lot of schools do though. I'm frequently shocked by how little many CS graduates know when they first get out of school.

- Jonathan M Davis

On Fri, Aug 31, 2018 at 05:47:40PM -0600, Jonathan M Davis via Digitalmars-d wrote: [...]
> The school I went to (Cal Poly, San Luis Obispo) at least tries to focus on the practical side of things (their motto is "learn by doing"), and when I went there, they even specifically had a Software Engineering degree where you had to take a year-long course where you did a project in a team for a company. But at least at the time, the big difference between the SE and CS degrees was that they required more classes with group work and fewer theoretical classes, and there certainly weren't any classes on something like debugging. The software engineering-centric classes focused more on a combination of teaching stuff like classic design patterns and then having you do projects in groups. And that was helpful, but it still didn't really prepare you for what you were going to be doing in your full-time job. It's still better than what a lot of schools do though. I'm frequently shocked by how little many CS graduates know when they first get out of school.
[...]

I suppose it depends on the school.  And yes, I've seen CS graduates who have literally never written a program longer than 1 page.  I cannot imagine what kind of shock they must have felt upon getting a job in the industry and being faced, on their first day, with a 2 million LOC codebase riddled with hacks, last-minute-rushed fixes, legacy code that nobody understands anymore, inconsistent / non-existent documentation, and being tasked with fixing a bug of unclear description and unknown root cause which could be literally *anywhere* in those 2 million LOC.

I was lucky that I was spared of most of the shock due to having spent a lot of time working on personal projects while at school, and thereby picking up many practical debugging skills.


T

-- 
Real men don't take backups. They put their source on a public FTP-server and let the world mirror it. -- Linus Torvalds

On Friday, 31 August 2018 at 23:47:40 UTC, Jonathan M Davis wrote:
> The are plenty of cases where the teachers actually do an excellent job teaching the material that the courses cover. It's just that the material is often about theoretical computer science - and this is actually stuff that can be very beneficial to becoming an excellent programmer. However, many teachers really aren't great programmers. They aren't necessarily bad programmers, but unless they spent a bunch of time in industry before teaching, odds are that they don't have all of the software engineering skills that the students are going to need once they get into the field. And most courses aren't designed to teach students the practical skills.

Imagine getting a Industrial Engineer that switched over to become a teacher, showing up to teach Visual Basic and Database normalization.

That same teacher used one of those red little VB books for his study material ( been 20+ years ago, not sure if they still exist ).

The students ended up helping each other fixing issues because the teacher was useless. It was even so bad, he took examples out of the book, little bit reformatted the questions and used that for tests. Of course one of our fellow students figure this out, he got his hands on the book and voila, every test answer.

Worst was that the teacher was so BORING, that nobody wanted to sit in the front of the class, because his database class was so bad, people literally needed to keep each other up from falling asleep. I am not joking!

You can guess that i never learned database normalization in school and ended up doing it on my own. So yea, first hand experience with bad teachers.

The guy that did C++ was way better and you actually learned from him. A bit scary guy but knew his stuff. Teachers make all the difference for children/students to learn anything.

If they are boring, burned out or just doing it to earn money, it shows in the lacking responds and score of the students. A good teacher draws in the students and helps them focus. A good teacher does not make things over complicated and does not assume that everybody understand. Seen brilliant teachers that are horrible at teaching because they are so smart ( or repeated the same material so much ), they assume everybody understands everything as they do.

Teacher make all the difference in teaching but a lot is so politicizes/internal power games, ... that good teachers tend to leave and bad ones just end up doing the job, because its a good government/public servant job with nice vacation perks ( here in the EU ).

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.

On Friday, 31 August 2018 at 22:27:47 UTC, Walter Bright wrote:
> On 8/31/2018 2:21 PM, tide wrote:
>> On Friday, 31 August 2018 at 19:50:20 UTC, Walter Bright wrote:
>>> "Stopping all executing may not be the correct 'safe state' for an airplane though!"
>> Depends on the aircraft and how it is implemented. If you have a plane that is fly by wire, and you stop all executing then even the pilot no longer has control of the plane anymore, which would be very bad.
>
> I can't even read the rest of posting after this.
>
> Please read the following articles, then come back.
>
> Assertions in Production Code
> https://www.digitalmars.com/articles/b14.html
>
> Safe Systems from Unreliable Parts
> https://www.digitalmars.com/articles/b39.html
>
> Designing Safe Software Systems Part 2
> https://www.digitalmars.com/articles/b40.html

I've already read them before. Why don't you explain what is wrong with it rather than posting articles. You are just taking one line comments without even thinking about the context.

On Friday, 31 August 2018 at 22:05:18 UTC, H. S. Teoh wrote:
> On Fri, Aug 31, 2018 at 09:40:50PM +0000, tide via Digitalmars-d wrote:
>> On Friday, 31 August 2018 at 21:31:02 UTC, 0xEAB wrote:
> [...]
>> > Furthermore, how often have we cursed about games that hung up with a blackscreen and didn't let us close them by any mean other than logging off? If they just crashed, we'd not have run into such problems.
>> 
>> That's assuming an assert catches every error. Not all bugs are going to be caught by an assert. I don't think I've ever had a game hung up in a black screen and not be able to close it.
>
> I have, and that's only one of the better possible scenarios.  I've had games get into a bad state, which becomes obvious as visual glitches, and then proceed to silently and subtly corrupt the save file so that on next startup all progress is lost.
>
> Had the darned thing aborted at the first visual glitch or unexpected internal state, instead of blindly barging on pretending that visual glitches are not a real problem, the save file might have still been salvageable.
>
> (Yes, visual glitches, in and of themselves, aren't a big deal.
>  Most people may not even notice them.  But when they happen unexpectedly, they can be a symptom of a deeper, far more serious problem. Just like an assert detecting that some variable isn't the expected value. Maybe the variable isn't even anything important; maybe it just controls the color of the title bar or something equally irrelevant. But it could be a sign that there's been a memory corruption.  It could be a sign that the program is in the middle of being exploited by a security hack. The unexpected value in the variable isn't merely an irrelevant thing that we can safely ignore; it could be circumstantial evidence of something far more serious.  Continuing to barrel forward in spite of clear evidence pointing to a problem is utterly foolish.)
>
>
> T

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 ?