On Friday, 31 August 2018 at 21:09:21 UTC, H. S. Teoh wrote:
>> Some countries do have engineering certifications and professional permits for software engineering, but its still a minority.
> [...]
>
> It's precisely for this reason that the title "software engineer" makes me cringe on the one hand, and snicker on the other hand.  I honestly cannot keep a straight face when using the word "engineering" to describe what a typical programmer does in the industry these days.

Huh? I'm pretty sure they mean it was a management decision. Why do you blame engineers for doing what they are asked to do? Making them write code properly is as simple as paying for exactly that.

On 8/31/2018 11:59 PM, Paulo Pinto wrote:
>> For example, in any CS program, are there any courses at all about this?
> Yes, we had them on my degree,

I'm curious how the courses you took compared with the articles I wrote about it.

On Saturday, 1 September 2018 at 08:19:49 UTC, Walter Bright wrote:
> On 8/31/2018 11:59 PM, Paulo Pinto wrote:
>>> For example, in any CS program, are there any courses at all about this?
>> Yes, we had them on my degree,
>
> I'm curious how the courses you took compared with the articles I wrote about it.

I will read the articles later, but as overview, we learned about:

- requirements gathering
- architecture design based on several methodologies, back then it was Booch, ER, Coad and the newly introduced UML
- introduction to way to manage source control, rcs and cvs
- design by contract, via Eiffel
- use of abstract data types as means to achieve clean architectures with separation of concerns
- ways to perform testing, way before unit testing was even a thing
- we had a semester project going from requirements gathering, design and implementation that was validated how well it achieved those goals.

Which on my year it was the implementation of subway ticketing system with automatic control of access doors, just the software part. The sensors and door controls were simulated.

And the implementation of a general purpose B+ tree library, another semester long project, whose integration tests where not available to us.

We had one week time to make our library could link and successfully execute all the tests that the teacher came up with for the acceptance testing phase. We did not have access to their source code, we just provided our lib.a.

On 31/08/18 23:22, Steven Schveighoffer wrote:
> On 8/31/18 3:50 PM, Walter Bright wrote:
>> https://news.ycombinator.com/item?id=17880722
>>
>> Typical comments:
>>
>> "`assertAndContinue` crashes in dev and logs an error and keeps going in prod. Each time we want to verify a runtime assumption, we decide which type of assert to use. We prefer `assertAndContinue` (and I push for it in code review),"
> 
> e.g. D's assert. Well, actually, D doesn't log an error in production.
> 
> -Steve

I think it's the music of the thing rather than the thing itself.

Mecca has ASSERT, which is a condition always checked and that always crashes the program if it fails, and DBG_ASSERT, which, like D's built in assert, is skipped in release mode (essentially, an assert where you can log what went wrong without using the GC needing format).

When you compare this to what Walter was quoting, you get the same end result, but a vastly different intention. It's one thing to say "this ASSERT is cheap enough to be tested in production, while this DBG_ASSERT one is optimized out". It's another to say "well, in production we want to keep going no matter what, so we'll just ignore the asserts".

Shachar

On Friday, 31 August 2018 at 22:23:09 UTC, Walter Bright wrote:
> For example, in any CS program, are there any courses at all about this?

In Year 1 Q4 of my Bachelor CS, there was a course "Software Testing and Quality Engineering" which covered things like test types (unit, end-to-end, smoke  etc.), code coverage and design by contract. They taught how to implement invariants, preconditions and postconditions in Java by manually placing asserts (since unlike D, there's no `in`, `out` or `invariant` keywords in Java) but I don't recall anything related to recovery from errors, or using aviation safety principles to make a safe system from unreliable parts. They said that you can decide between security and performance when choosing to leave asserts on/off in release builds.

In Year 2 Q1 there was a follow-up "Software Engineering Methods" course which talked about Design Patterns (the GoF ones), process (SCRUM / Agile), and designing (with UML and other graphs). No other courses since then talked about software engineering, they were more focused on specific fields (big data, signal processing, embedded systems) and fundamental computer science (algorithms, complexity theory, programming languages).

On Saturday, September 1, 2018 1:59:27 AM MDT Walter Bright via Digitalmars- d wrote:
> 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.

Unfortunately, in the case of Blu-ray players, if you don't, at some point, you likely won't be able to play newer Blu-rays, because they keep updating the DRM on the discs, requiring updates to the players - which is annoying enough on its own, but when you consider that if it weren't for the DRM, there wouldn't be any reason to hook up a Blu-ray player to a network, the fact that the DRM essentially requires it is that much more egregious. But sadly, increasingly, they seem to want you to hook up all of your stray electronics to the network, which is anything but safe. Fortunately, not all of them actually require it (e.g. I've never hooked up my TV to any network, and I see no value in anything it runs that would require it), but too many do.

- Jonathan M Davis

On Saturday, September 1, 2018 2:19:07 AM MDT Kagamin via Digitalmars-d wrote:
> On Friday, 31 August 2018 at 21:09:21 UTC, H. S. Teoh wrote:
> >> Some countries do have engineering certifications and professional permits for software engineering, but its still a minority.
> >
> > [...]
> >
> > It's precisely for this reason that the title "software engineer" makes me cringe on the one hand, and snicker on the other hand.  I honestly cannot keep a straight face when using the word "engineering" to describe what a typical programmer does in the industry these days.
>
> Huh? I'm pretty sure they mean it was a management decision. Why do you blame engineers for doing what they are asked to do? Making them write code properly is as simple as paying for exactly that.

I think that his point was more that it's sometimes argued that software engineering really isn't engineering in the classical sense. If you're talking about someone like a civil engineer for instance, the engineer applies well-known and established principles to everything they do in a disciplined way. The engineering aspects of civil engineering aren't subjective at all. They're completely based in the physical sciences. Software engineering on the other hand isn't based on the physical sciences at all, and there really isn't general agreement on what good software engineering principles are. There are aspects of it that are very much like engineering and others that are very much subjective.

Someone else could probably explain it better than I could, but based on some definitions of engineering, software engineering definitely doesn't count, but it _does_ have aspects of engineering, so it can be argued either way. Wikipedia even has a "controversy" section on its page for software engineering that talks briefly about it:

https://en.wikipedia.org/wiki/Software_engineering

I'm not sure that I really agree that software engineering isn't engineering, but the folks who argue against it do have a point in that software engineering is definitely not like most other engineering disciplines, and good engineering practices are nowhere near as well-defined in software engineering as those in other engineering fields.

Issues with management cause other problems on top of all of that, but even if you have a group of software engineers doing their absolute best to follow good software engineering principles without any kind of management interference, what they're doing is still very different from most engineering disciplines, and it likely wouldn't be hard for another group of competent software engineers to make solid arguments about why the good software engineering practices that they're following actually aren't all that good.

- Jonathan M Davis

On Saturday, 1 September 2018 at 08:18:03 UTC, Walter Bright wrote:
> 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.
>
> (...)
>
> Apply common sense and assert on unreasonable results, because your code is broken.

Your examples are valid, but I just wanted to say the game development is a bit of a 'special' case in software engineering because there is often no clear 'correct' output for an input. The desired output is simply one that makes the players happy, which is subjective.

Take for example a 3D game where a car gets stuck between bollards and launches into the air. The problem is that real-time physics engines work in discrete steps and try to solve constraints by adding force to push overlapping bodies away from each other. When a rigid body gets stuck inside another rigid body, the force it generates can be comically large. This problem is well known but a 'proper' fix is not easy, it's often solved by designing the geometry so that cars can't get stuck like that. Would an `assert(car.yVelocity < 200 m/s)` that causes the game to crash when that happens really make the game better? Many players actually enjoy such glitches. They don't like when their character randomly clips through the floor and falls into a void however. But how would you assert that doesn't happen? There's no formal definition for it.

By the way, I'm sure the way the Unity game engine treats asserts will make you cry:
"A failure of an assertion method does not break the control flow of the execution. On a failure, an assertion message is logged (LogType.Assert) and the execution continues."[1]

That's in debug builds, in release builds they are removed completely. So my `Assert.IsNotNull()` fails but the assert message quickly gets buried under a slew of errors. Note that the game keeps running, the 'C# script component' of the entity in question just ceases to work. "The show must go on!"

[1] https://docs.unity3d.com/ScriptReference/Assertions.Assert.html

On 9/1/2018 2:15 AM, Paulo Pinto wrote:
> On Saturday, 1 September 2018 at 08:19:49 UTC, Walter Bright wrote:
>> On 8/31/2018 11:59 PM, Paulo Pinto wrote:
>>>> For example, in any CS program, are there any courses at all about this?
>>> Yes, we had them on my degree,
>>
>> I'm curious how the courses you took compared with the articles I wrote about it.
> 
> I will read the articles later, but as overview, we learned about:
> [...]
It appears to have nothing related to what the articles are about.

I'm rather sad that I've never seen these ideas outside of the aerospace industry. Added to that is all the pushback on them I get here, on reddit, and on hackernews.

I see the results all the time. Like when someone can use a radio to hack into a car computer via the keyless door locks, and take over the steering and braking system. Even worse, when engineers discuss that, it never occurs to them that critical systems should be electrically separate from the infotainment system and anything that receives wireless data. They just talk about "fixing the bug".

BTW, people who run spy networks figured this out long ago. It's all divided up by "need to know" rules and cells. Any spy captured and tortured can only give up minimal information, not something that will allow the enemy to roll up the entire network.

On 9/1/2018 3:49 AM, Dennis wrote:
> On Friday, 31 August 2018 at 22:23:09 UTC, Walter Bright wrote:
>> For example, in any CS program, are there any courses at all about this?
> 
> In Year 1 Q4 of my Bachelor CS, there was a course "Software Testing and Quality Engineering" which covered things like test types (unit, end-to-end, smoke  etc.), code coverage and design by contract. They taught how to implement invariants, preconditions and postconditions in Java by manually placing asserts (since unlike D, there's no `in`, `out` or `invariant` keywords in Java) but I don't recall anything related to recovery from errors, or using aviation safety principles to make a safe system from unreliable parts. They said that you can decide between security and performance when choosing to leave asserts on/off in release builds.

Sigh.

It's not just the software industry. Industry outside of aerospace appears to be ignorant of it. See the Deepwater Horizon, Fukushima, medical devices, Toyota car computers, it just goes on and on.

One of my favorite examples is when the power failed in New Orleans during a storm, and the city flooded. Guess where the backup generators were located? In the basements! The flooding took them out. Only one building had power after the disaster, and they'd located the emergency generator above sea level.

Only one did that.

The backups were destroyed by the same situation that caused the need for the backups - flooding from power failure. Completely worthless design, because the systems were coupled.