5 ms·

My impression is that this is due to their non-robust programming style. They do not add fallback behavior when e.g. receiving a null object. It would still be

My impression is that this is due to their non-robust programming style. They do not add fallback behavior when e.g. receiving a null object. It would still be a bug, but could be a log entry instead of crash.

mrkeen 2y ago
> My impression is that this is due to their non-robust programming style. It's been 50+ years. I don't think that it's worthwhile just telling the programmer to do a better job. > They do not add fallback behavior when e.g. receiving a null object. It would still be a bug, but could be a log entry instead of crash. This is a pretty big feedback loop: * The programmer puts the null into the code * The code is released * The right conditions occur and the player triggers it * IF DONE SKILLFULLY AND CORRECTLY the game is able to recover from the null-dereference, write it out to a log, and get that log back to the developers. * The programmer takes the null out of the code. If you don't do the first step, you don't get stuck doing the others either.
- nurettin 2y ago
  50+ years and people still fail to grasp this. You have to put something (an optional, or a default constructed object in a useless state) and all you did was to skip the null check. In case of optional, you introduced a stack rewind or a panic. Everything else stayed the same. Maybe that default even deleted the hard drive instead of crashing. Coding is hard. "just don't code" is not the answer. You can avoid something, that doesn't mean it won't show up in some other fashion.
  - sam0x17 2y ago
    Again, if you disallow unwrapping and panicking at the CI level, you actually force your developers to properly handle these situations.
  - mrkeen 2y ago
    > You have to put something (an optional, or a default constructed object in a useless state) No, you really don't. There is no default number, no default string, no default piece of legislation, no default function.
astrange 2y ago
Arbitrary recovery to null pointers isn't a good way to do robust programming. I recommend doing the exact opposite actually. https://en.wikipedia.org/wiki/Crash-only_software https://en.wikipedia.org/wiki/Crash-only_software https://medium.com/@vamsimokari/erlang-let-it-crash-philosophy-53486d2a6da https://medium.com/@vamsimokari/erlang-let-it-crash-philosop...
- 0x457 2y ago
  A crash of an actor in BEAM is incomparable to a crash of a video game.
  - astrange 2y ago
    But if your video game uses a DSL for actors then you can do it in the DSL, which avoids special arbitrary bug-hiding behavior.
  - epr 2y ago
    Is it? Is there no reasonable case where you have a subsystem in a game crash, then restart itself? Unless I'm mistaken, I've experienced this myself in video games more than once. Anything beats a full crash with a pointless error message.
    - 0x457 2y ago
      I feel like a lot of people of HN think making a game is like making a web service or a GUI application. Yes, this behavior is used in video games sometimes, "restart itself" often means reloading a save file or something similar.
- meinersbur 2y ago
  I dare you to board a plane whose software was written that way.

mrkeen 2y ago

> My impression is that this is due to their non-robust programming style. It's been 50+ years. I don't think that it's worthwhile just telling the programmer to do a better job. > They do not add fallback behavior when e.g. receiving a null object. It would still be a bug, but could be a log entry instead of crash. This is a pretty big feedback loop: * The programmer puts the null into the code * The code is released * The right conditions occur and the player triggers it * IF DONE SKILLFULLY AND CORRECTLY the game is able to recover from the null-dereference, write it out to a log, and get that log back to the developers. * The programmer takes the null out of the code. If you don't do the first step, you don't get stuck doing the others either.

nurettin 2y ago
50+ years and people still fail to grasp this. You have to put something (an optional, or a default constructed object in a useless state) and all you did was to skip the null check. In case of optional, you introduced a stack rewind or a panic. Everything else stayed the same. Maybe that default even deleted the hard drive instead of crashing. Coding is hard. "just don't code" is not the answer. You can avoid something, that doesn't mean it won't show up in some other fashion.
- sam0x17 2y ago
  Again, if you disallow unwrapping and panicking at the CI level, you actually force your developers to properly handle these situations.
- mrkeen 2y ago
  > You have to put something (an optional, or a default constructed object in a useless state) No, you really don't. There is no default number, no default string, no default piece of legislation, no default function.

astrange 2y ago

Arbitrary recovery to null pointers isn't a good way to do robust programming. I recommend doing the exact opposite actually. https://en.wikipedia.org/wiki/Crash-only_software https://en.wikipedia.org/wiki/Crash-only_software https://medium.com/@vamsimokari/erlang-let-it-crash-philosophy-53486d2a6da https://medium.com/@vamsimokari/erlang-let-it-crash-philosop...

0x457 2y ago
A crash of an actor in BEAM is incomparable to a crash of a video game.
- astrange 2y ago
  But if your video game uses a DSL for actors then you can do it in the DSL, which avoids special arbitrary bug-hiding behavior.
- epr 2y ago
  Is it? Is there no reasonable case where you have a subsystem in a game crash, then restart itself? Unless I'm mistaken, I've experienced this myself in video games more than once. Anything beats a full crash with a pointless error message.
  - 0x457 2y ago
    I feel like a lot of people of HN think making a game is like making a web service or a GUI application. Yes, this behavior is used in video games sometimes, "restart itself" often means reloading a save file or something similar.
meinersbur 2y ago
I dare you to board a plane whose software was written that way.