On Thursday, 18 September 2014 at 16:55:33 UTC, H. S. Teoh via
Digitalmars-d wrote:
> On Thu, Sep 18, 2014 at 07:13:48PM +0300, ketmar via Digitalmars-d wrote:
>> On Thu, 18 Sep 2014 17:05:31 +0100
>> Bruno Medeiros via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> 
>> > * a small (or big) visual glitch, like pixels out of place,
>> > corrupted textures, or 3D model of an object becoming deformed, or
>> > the physics of some object behaving erratically, or some broken
>> > animation.
>> or the whole game renders itself unbeatable due to some correpted
>> data, but you have no way to know it until you made it to the Final
>> Boss and can never win that fight. ah, so charming!
>
> Exactly!!!!
>
> Seriously, this philosophy of ignoring supposedly "minor" bugs in
> software is what led to the sad state of software today, where nothing
> is reliable and people have come to expect that software will inevitably
> crash, and that needing to reboot an OS every now and then just to keep
> things working is acceptable. Yet, strangely enough, people will scream
> bloody murder if a car behaved like that.
>
>
> T

Fully agree. I support the idea that software companies should be
accountable by their products the same way as other industries.

Just like when you buy a car the car dealer will be accountable
for any defect.

Sure it will make software development a bit more expensive, but
it will also end with a lot of cowboy programming, updates that
only work in full moon, ...

--
Paulo

On Thursday, 18 September 2014 at 16:05:32 UTC, Bruno Medeiros wrote:
>
> "If it's a game, who cares" -> Oh let's see... let's say I'm playing a game, and then there's a bug (which happens often). What would I prefer to happen:
>
> * a small (or big) visual glitch, like pixels out of place, corrupted textures, or 3D model of an object becoming deformed, or the physics of some object behaving erratically, or some broken animation.
>
> * the whole game crashes, and I lose all my progress?
>
> So Walter, which one do you think I prefer? Me, and the rest of the million gamers out there?

Don't worry.  A shipped game would have been built with -release set because it's a release build.  No one cares about the reliability of released software, only test builds. /rant

On Thursday, 18 September 2014 at 16:55:33 UTC, H. S. Teoh via Digitalmars-d wrote:
>
> Seriously, this philosophy of ignoring supposedly "minor" bugs in
> software is what led to the sad state of software today, where nothing
> is reliable and people have come to expect that software will inevitably
> crash, and that needing to reboot an OS every now and then just to keep
> things working is acceptable. Yet, strangely enough, people will scream
> bloody murder if a car behaved like that.

A car did behave like that--the Toyota Prius.  It would randomly accelerate out of control because of a bug in the car's software.  People died.  And yes, bloody murder was screamed.

I used to work for the telephone company, and telcos are a bit weird because they're considered an essential service.  If martial law were enacted in the US, telephone workers would still be allowed on the street because the telephone system must work.  There was one instance when I was working that I had to get to the switch for maintenance during a horrible storm where the police had closed the roads.  No problem--they let me through.  Network services are rapidly approaching this point.  People depend on the internet for communication these days as much or more than they do on telephone calls.  I suspect/hope that it won't be long before communications software is held to standards similar to telephone, which will require a huge adjustment on the part of programmers.  People in this industry still tend to not think of things in terms of 5+ "nines" of uptime for their service, despite that being the expectation of their users.

On Friday, 19 September 2014 at 13:56:14 UTC, Sean Kelly wrote:
> I suspect/hope that it won't be long before communications software is held to standards similar to telephone, which will require a huge adjustment on the part of programmers.  People in this industry still tend to not think of things in terms of 5+ "nines" of uptime for their service, despite that being the expectation of their users.

Oh, just to clarify one thing though.  The typical way that a lot of network services work for reasons of performance is via asynchronous event-based models (fancy versions of the Unix poll() routine).  If a logic error results in a transaction failure and I can be sure that the scope of this error is limited to the state of that one transaction, I don't necessarily want to terminate the process as it will result in thousands of failed transactions.  Functional languages like Erlang tend to support this model really well, because a "process" is actually just a thread of execution in the VM.  The "process" (thread) is terminated and the VM soldiers on because there's no logical way for the state of the VM to have been corrupted.

I'm still unsure how I feel about D in this regard.  Clients will retry if a request fails, and so terminating the entire process and failing thousands of transactions would be bad but possibly still invisible to users.  At least unless the logic error occurs in a common path of execution, in which case terminating the entire process on a logic error becomes a potential attack vector to bring down the entire system.

I suspect that what I'll be doing with D is moving away from asserts and throwing Errors to give myself the latitude to handle situations in whatever manner I feel is appropriate.  I'm still not sure about this, but I'm leaning towards feeling that the D approach is possibly too draconian for multi-user systems.  Perhaps it's possible to split each transaction off to be handled by a separate process (via unix domain sockets, for example, or IPC), but I suspect this won't scale to the degree that's needed.  This is how web servers used to work, for example, and I'm pretty sure none of them do this any more.  But I want to think more on the problem, as I do like the motivation behind these rules.

On 18/09/2014 17:49, H. S. Teoh via Digitalmars-d wrote:
> On Thu, Sep 18, 2014 at 05:05:31PM +0100, Bruno Medeiros via Digitalmars-d wrote:
>> On 01/08/2014 05:12, Walter Bright wrote:
>>> On 7/31/2014 2:21 PM, Sean Kelly wrote:
>>>> Thoughts?
>>>
>>> If a process detects a logic error, then that process is in an
>>> invalid state that is unanticipated and unknown to the developer. The
>>> only correct solution is to halt that process, and all processes that
>>> share memory with it.
>>>
>>> Anything less is based on faith and hope. If it is medical, flight
>>> control, or banking software, I submit that operating on faith and
>>> hope is not acceptable.
>>>
>>> If it's a dvr or game, who cares :-) My dvr crashes regularly needing
>>> a power off reboot.
>>
>> "If it's a game, who cares" -> Oh let's see... let's say I'm playing a
>> game, and then there's a bug (which happens often). What would I
>> prefer to happen:
>>
>> * a small (or big) visual glitch, like pixels out of place, corrupted
>> textures, or 3D model of an object becoming deformed, or the physics
>> of some object behaving erratically, or some broken animation.
>>
>> * the whole game crashes, and I lose all my progress?
> [...]
>
> What if the program has a bug that corrupts your save game file, but
> because the program ignores these logic errors, it just bumbles onward
> and destroys all your progress *without* you even knowing about it until
> much later?
>
> (I have actually experienced this firsthand, btw. I found it *far* more
> frustrating than losing all my progress -- at least I can restore the
> game to the last savepoint, and have confidence that it isn't
> irreparably corrupted! I almost threw the computer out the window once
> when after a game crash I restored the savefile, only to discover a few
> hours later that due to a corruption in the savefile, it was impossible
> to win the game after all. Logic errors should *never* have made it past
> the point of detection.)
>
>
> T
>

I never implied a program should try to recover or ignore *all* bugs that an assertion triggers. Sometimes it is better to crash the whole program straight away, yes. But sometimes ignoring the bug and keep going (or throwing an exception) is perfectly fine, and far better than the alternative (full program crash).
And since when you're working with assertion checks you know if they relate to game logic (the equivalent to "business" model), or to presentation (UI, 3D, graphics, sound, etc.), you could define if the program tries to continue running or not.

Under Walter's idea, you'd always crash the program.

Even if I had to choose between an occasional savefile corruption that would render a game impossible to win, and having my games crash every time ANY bug happened, I would still prefer the former. Because of all the games I played in my life (I'm 31 and I like gaming, so I've played quite a few), I've encountered maybe 3 games where that happened, that I can remember (*). But I've seen visual glitches in nearly all games I've played, and in maybe 60-75% of them those glitches happened *often enough* that it would render the game virtually unplayable.

BTW, the same doesn't apply just to games. Same thing for other desktop applications: IDEs, browsers, etc.. For example, in an IDE a bug in a parser might bring some visual or behavior glitch ing the current editor, but the whole IDE doesn't need to crash because of that!


* If anyone is curious:
Elder Scrolls 2 - Daggerfall: one of the possible endings, the one I was trying to go for, became impossible to achieve due to a main quest bug.
Fallout 2: an big side quest in a town became completely unresolvable.
Ultima VII- The Black Gate : with a certain magical spell you can sneak into a cave by a point that was meant only for exit. The problem is that the cave was only meant to be entered in a different place, and much later in the storyline. As such, in the cave you start to find dialogues, and notes that are clues to a *murder* that hadn't even happened yet! Unfortunately I only realized I was not meant to be the cave after several hours of gameplay (battling high level monsters took a while)... and even after that, I not only lost those hours, but I had a big twist and a massive chunk of the game's storyline spoiled...

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros

On Tue, 23 Sep 2014 15:19:56 +0100
Bruno Medeiros via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> Even if I had to choose between an occasional savefile corruption that would render a game impossible to win, and having my games crash every time ANY bug happened, I would still prefer the former.
it game will crash on ANY bug, it will contain alot less bugs.
'cause even the dumbiest QA full of monkeys will not let the game which
crashes once in a ten seconds to go out of the door.

yet game that renders itself unbeatable after some bug can sucessfully pass even the very good QA.

so it's easy: bug --> crash. oh, this game has only "savepoint" save system and last save was long ago? designers of this game are lazy dumbs, don't buy their games anymore.

On Tue, Sep 23, 2014 at 09:25:51PM +0300, ketmar via Digitalmars-d wrote:
> On Tue, 23 Sep 2014 15:19:56 +0100
> Bruno Medeiros via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> 
> > Even if I had to choose between an occasional savefile corruption that would render a game impossible to win, and having my games crash every time ANY bug happened, I would still prefer the former.
>
> it game will crash on ANY bug, it will contain alot less bugs.  'cause even the dumbiest QA full of monkeys will not let the game which crashes once in a ten seconds to go out of the door.

+1. When the game blatantly crashes on every little thing, there is pressure on the coders to actually fix the problem. Ignored errors == convenient excuse for coders to evade work ("it's *only* a minor display glitch!", "the deadline's tomorrow, we don't have time to fix this", "it's 5pm, I need to go home and feed my goldfish", "besides, it still works anyway, more or less", etc.).


T

-- 
Life is complex. It consists of real and imaginary parts. -- YHL

On 23/09/2014 19:35, H. S. Teoh via Digitalmars-d wrote:
>> >it game will crash on ANY bug, it will contain alot less bugs.  'cause
>> >even the dumbiest QA full of monkeys will not let the game which
>> >crashes once in a ten seconds to go out of the door.

When doing QA, that's a whole different thing than when playing normally.

> +1. When the game blatantly crashes on every little thing, there is
> pressure on the coders to actually fix the problem. Ignored errors ==
> convenient excuse for coders to evade work ("it's*only*  a minor display
> glitch!", "the deadline's tomorrow, we don't have time to fix this",
> "it's 5pm, I need to go home and feed my goldfish", "besides, it still
> works anyway, more or less", etc.).

I would invite you to buy a *retail copy* of Elder Scrolls 3 : Morrowind for PC and try playing that. The game did exactly what Walter and you guys suggested: when an assertion tripped, it would crash straight away to the desktop, with only a message dialog saying that an assertion had failed (with info on the source and line of the assertion, and an extra message).
I couldn't play that game, it would crash too often. And saving wasn't quick enough that I could in practice be manually saving every 15 min. or so.
Only when several iterations of patches game out, several months after release, did the game become stable enough to be played enjoyably.
(in fairness, if the assertions where about core game logic, I too would prefer a crash rather then possible corruption of game state. But IIRC there was a few assertions crashes that seemed related to textures, directx, or shader stuff - for that I could have lived without a game crash)

Sometimes even with known bugs the game is shipped, because of management pressure and/or huge delays already. (especially with pressures to do multi-platform releases).

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros

On Monday, 29 September 2014 at 13:01:19 UTC, Bruno Medeiros wrote:
> On 23/09/2014 19:35, H. S. Teoh via Digitalmars-d wrote:
>>> >it game will crash on ANY bug, it will contain alot less bugs.  'cause
>>> >even the dumbiest QA full of monkeys will not let the game which
>>> >crashes once in a ten seconds to go out of the door.
>
> When doing QA, that's a whole different thing than when playing normally.
>
>> +1. When the game blatantly crashes on every little thing, there is
>> pressure on the coders to actually fix the problem. Ignored errors ==
>> convenient excuse for coders to evade work ("it's*only*  a minor display
>> glitch!", "the deadline's tomorrow, we don't have time to fix this",
>> "it's 5pm, I need to go home and feed my goldfish", "besides, it still
>> works anyway, more or less", etc.).
>
> I would invite you to buy a *retail copy* of Elder Scrolls 3 : Morrowind for PC and try playing that. The game did exactly what Walter and you guys suggested: when an assertion tripped, it would crash straight away to the desktop, with only a message dialog saying that an assertion had failed (with info on the source and line of the assertion, and an extra message).
> I couldn't play that game, it would crash too often. And saving wasn't quick enough that I could in practice be manually saving every 15 min. or so.
> Only when several iterations of patches game out, several months after release, did the game become stable enough to be played enjoyably.
> (in fairness, if the assertions where about core game logic, I too would prefer a crash rather then possible corruption of game state. But IIRC there was a few assertions crashes that seemed related to textures, directx, or shader stuff - for that I could have lived without a game crash)
>
> Sometimes even with known bugs the game is shipped, because of management pressure and/or huge delays already. (especially with pressures to do multi-platform releases).

And the right attitude as consumer is to ask for the money back, not to wait patiently for the day those bugs eventually get fixed.

If everyone did that, the quality in IT would be much better.

--
Paulo

On Monday, 29 September 2014 at 13:41:33 UTC, Paulo  Pinto wrote:
> And the right attitude as consumer is to ask for the money back, not to wait patiently for the day those bugs eventually get fixed.
>
> If everyone did that, the quality in IT would be much better.

The mobile freemium model where you try before you buy kind of offsets this position though. But if the game saves frequently and reloads quickly it is less annoying.

After watching the initial years of MMO I also think people are willing to live with bugs, nerfing and other upsetting events until the Next Big Thing comes along. There probably is some value in having something common to complain about. :-)