On Saturday, September 1, 2018 6:37:13 AM MDT tide via Digitalmars-d wrote:
> 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.
> >
> > 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.
>
> That's what he, and apparently you don't get. How are you going to use an assert to check that the color of a title bar is valid? Try and implement that assert, and let me know what you come up with.

I don't think that H. S. Teoh's point was so much that you should be asserting anything about the colors in the graphics but rather that problems in the graphics could be a sign of a deeper, more critical problem and that as such the fact that there are graphical glitches is not necessary innocuous. However, presumably, if you're going to put assertions in that code, you'd assert things about the actual logic that seems critical and not anything about the colors or whatnot - though if the graphical problems would be a sign of a deeper problem, then the assertions could then prevent the graphical problems, since the program would be killed before they happened due to the assertions about the core logic failing.

- Jonathan M Davis

On 02/09/2018 1:15 AM, Jonathan M Davis wrote:
> On Saturday, September 1, 2018 6:46:38 AM MDT rikki cattermole via
> Digitalmars-d wrote:
>> On 02/09/2018 12:21 AM, tide wrote:
>>> On Saturday, 1 September 2018 at 05:53:12 UTC, rikki cattermole wrote:
>>>> 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.
>>>
>>> Not the one's Walter is talking about. I rarely have to power cycle any
>>> smart device, even my phone which is running so much shit on it.
>>
>> For some reason I have memories related to DVD players containing a JVM
>> to provide interactivity. But it doesn't look like those memory were
>> based on anything. So ignore me.
> 
> I don't know if any DVD players have ever used Java, but all Blu-ray players
> do require it, because unfortunately, the Blu-ray spec allows for the menus
> to be done via Java (presumably so that they can be fancier than what was
> possible on DVDs).
> 
> - Jonathan M Davis

Harry potter 1&2 had games as part of their menus as of 2001/2, so it was already pretty sophisticated.

On Friday, 31 August 2018 at 19:50:20 UTC, 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),"
>
> "Stopping all executing may not be the correct 'safe state' for an airplane though!"
>
> "One faction believed you should never intentionally crash the app"
>
> "One place I worked had a team that was very adamant about not really having much error checking. Not much of any qc process, either. Wait for someone to complain about bad data and respond. Honestly, this worked really well for small, skunkworks type projects that needed to be nimble."
>
> And on and on. It's unbelievable. The conventional wisdom in software for how to deal with programming bugs simply does not exist.
>
> Here's the same topic on Reddit with the same awful ideas:
>
> https://www.reddit.com/r/programming/comments/9bl72d/assertions_in_production_code/
>
> No wonder that DVD players still hang when you insert a DVD with a scratch on it, and I've had a lot of DVD and Bluray players over the last 20 years. No wonder that malware is everywhere.

It's because programming is done completely wrong. All we do is program like it's 1952 all wrapped up in a nice box and bow tie. WE should have tools and a compiler design that all work interconnected with complete graphical interfaces that aren't based in the text gui world(an IDE is just a fancy text editor). I'm talking about 3D code representation using graphics so projects can be navigated  visually in a dynamic way and many other things.

The current programming model is reaching diminishing returns. Programs cannot get much more complicated because the environment in which they are written cannot support them(complexity != size).

We have amazing tools available to do amazing things but programming is still treated like punch cards, just on acid. I'd like to get totally away from punch cards.

I total rewrite of all aspects of programming should be done(from "object" files(no more, they are not needed, at least not in the form they are), the IDE(it should be more like a video game(in the sense of graphical use) and provide extensive information and debugging support all at a finger tip away), from the tools, to the design of applications, etc.

One day we will get there...

On 9/1/2018 1:18 AM, 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 ?
> [...]

John Regehr has some excellent advice, much better than mine:

https://blog.regehr.org/archives/1091

On 9/1/2018 5:25 AM, tide wrote:
> and that all bugs can be solved with asserts

I never said that, not even close.

But I will maintain that DVD players still hanging on a scratched DVD after 20 years of development means there's some cowboy engineering going on, and an obvious lack of concern about that from the manufacturer.

On 9/1/2018 5:33 AM, tide wrote:
> It is vastly different, do you know what fly by wire is?

Yes, I do. Do you know I worked for three years on critical flight controls systems at Boeing? I said so in the article(s). These ideas are not mine, I did not come up with them in 5 minutes at the keyboard. They're central to the aerospace design industry, and their fantastic safety record is testament to how effective they are.


> If the system controlling that just stops working, how do you expect the pilot to fly the plane?

https://www.digitalmars.com/articles/b40.html

May I draw your attention back to the "Dual Path" section.

Fly by wire failures are no different in principle from a total hydraulic system failure on a fully powered flight control system.

Airliners do suffer total hydraulic failures now and then, despite being unable to fly without hydraulics, yet land safely. I'll give you one guess how that is done :-) I can give you a brief rundown on how it works after you guess.

On Saturday, 1 September 2018 at 11:32:32 UTC, Jonathan M Davis wrote:
> 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.

Most engineering fields have a somewhat stable/slow moving context in which they operate.

If you have a specific context (like banking) then you can develop a software method that specifies how to build banking software, and repeat it, assuming that the banks you develop the method for are similar

Of course, banking has changed quite a lot over the past 15 years (online + mobile). Software often operates in contexts that are critically different and that change in somewhat unpredictable manners.

But road engineers have a somewhat more stable context, they can adapt their methodology over time. Context does change even there, but at a more predictable pace.

Of course, this might be primarily because computers are new. Businesses tend to use software/robotics in a disruptive manner to get a competitive edger over the competitors. So the users themselves creates disruptive contexts in their search for the "cutting edge"  or "competitive edge".

As it becomes more and more intertwined into how people do business it might become more stable and then you might see methods for specific fields that are more like engineering in older established fields. (like building railways).

On 8/31/2018 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),"
> 
> "Stopping all executing may not be the correct 'safe state' for an airplane though!"
> 
> "One faction believed you should never intentionally crash the app"
> 
> "One place I worked had a team that was very adamant about not really having much error checking. Not much of any qc process, either. Wait for someone to complain about bad data and respond. Honestly, this worked really well for small, skunkworks type projects that needed to be nimble."
> 
> And on and on. It's unbelievable. The conventional wisdom in software for how to deal with programming bugs simply does not exist.
> 
> Here's the same topic on Reddit with the same awful ideas:
> 
> https://www.reddit.com/r/programming/comments/9bl72d/assertions_in_production_code/
> 
> 
> No wonder that DVD players still hang when you insert a DVD with a scratch on it, and I've had a lot of DVD and Bluray players over the last 20 years. No wonder that malware is everywhere.

All too true.

A while ago I worked for a large financial company.

Many production systems had zero monitoring. A server with networking issues could continue to misbehave _for hours_ until someone somewhere noticed thousands of error messages and manually intervened.

There were also very few data quality checks. Databases could have duplicate records, missing records or obviously inconsistent information. Most systems just continued to process corrupt data as if nothing happened, propagating it further and further.

Some crucial infrastructure had no usable data backups.

With all this in mind, you would be surprised to hear how much they talked about "software quality". It's just that their notion of quality revolved around having no bugs ever go into production and never bringing down any systems. There were ever increasing requirements around unit test coverage, opinionated coding standards and a lot of paperwork associated with every change.

Needless to say, it didn't work very well, and they had round half a dozen outages of varying sizes _every day_.

Alan Kay, Joe Armstrong, Jim Coplien - just to name a few famous people who talked about this issue. It's amazing that so many engineers still don't get it. I'm inclined to put some blame on the recent TDD movement. They often to seem stress low-level code perfectionism, while ignoring high-level architecture and runtime resilience (in other words, system thinking).

On 9/1/2018 2:33 PM, Gambler wrote:
> Alan Kay, Joe Armstrong, Jim Coplien - just to name a few famous people
> who talked about this issue. It's amazing that so many engineers still
> don't get it. I'm inclined to put some blame on the recent TDD movement.
> They often to seem stress low-level code perfectionism, while ignoring
> high-level architecture and runtime resilience (in other words, system
> thinking).

Yup. The worst notions in the industry are:

1. We can make this software bug-free by using Fad Technique X.

2. Since our software has no bugs in it, we needn't concern ourselves with what happens when it fails.

3. If it does fail, since we have no plan for that due to (2), we must let it proceed anyway.

What could possibly go wrong?

On 9/1/2018 7:36 AM, Walter Bright wrote:
> 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.

Some people do. I should take this opportunity to plug one of Alan Kay's great talks.

"Programming and Scaling" https://www.youtube.com/watch?v=YyIQKBzIuBY

But Kay definitely isn't a Hacker News/Reddit darling, even though he's well respected. He's too critical of the current state of software engineering. Rightfully so, if you ask me.