3 ms·

> message based architectures are easier to debug (by far) This is the opposite of my experience, mainly because of the lack of proper call stacks, it is very

by Jare 12y ago

> message based architectures are easier to debug (by far) This is the opposite of my experience, mainly because of the lack of proper call stacks, it is very hard to inspect the reason the values in a message are what they are. Can you elaborate?

jacquesm 11y ago
That's interesting. I guess this boils down to how far from the point of origin a bug originates. In a message based system that should be at most one step away from where you find the bad value. If it is more than one step away that's more of an architectural issue, it probably means that you are sending your messages first to some kind of hub which then passes it on to the actual recipient so you lose the point of origin information. A message that gets passed on untransformed from a module that does not realize the data is corrupted is a missed chance for an integrity check and a subsequent crash. Smalltalk does a half decent job at integrating the 'debugger' with the runtime environment (they're so tightly integrated it's hard to tell where one starts and the other one ends) and allows you to see fairly detailed traces of what happened to which parameter along the way, it's as detailed as any call stack dump. Erlang has a 'let it crash' policy (see Joe Armstrong's excellent paper) which tries to enforce the point of origin and the subsequent crash happen as close to each other as possible (and provides a whole range of mechanisms to deal with the fall-out). A 30 level call-stack like say Java would produce simply doesn't happen in those environments. Though if you programmed in a 'Java' style in say 'erlang' then you could generate one and it would make your life much harder.
- Jare 11y ago
  No hehe, my experience is mostly C++ PC and console games, so a) let it crash is not viable, and b) performance precludes performing extensive validation (a debuggable but unresponsive game is not viable). In games, messaging troubles are usually related to systems like character behaviour and AI that deal with multiple complex entities responding to the world state and interacting with each other. It's rarely a case of corrupt data and null pointers (those are easier): physically valid yet logically incorrect or unexpected data.
  - jacquesm 11y ago
    I think you're missing out on something, have a read and see if maybe 'let it crash' is more than you think it is: http://web.archive.org/web/20090430014122/http://nplus1.org/articles/a-crash-course-in-failure/ http://web.archive.org/web/20090430014122/http://nplus1.org/... https://mazenharake.wordpress.com/2009/09/14/let-it-crash-the-right-way/ https://mazenharake.wordpress.com/2009/09/14/let-it-crash-th...

by Jare 12y ago

jacquesm 11y ago

That's interesting. I guess this boils down to how far from the point of origin a bug originates. In a message based system that should be at most one step away from where you find the bad value. If it is more than one step away that's more of an architectural issue, it probably means that you are sending your messages first to some kind of hub which then passes it on to the actual recipient so you lose the point of origin information. A message that gets passed on untransformed from a module that does not realize the data is corrupted is a missed chance for an integrity check and a subsequent crash. Smalltalk does a half decent job at integrating the 'debugger' with the runtime environment (they're so tightly integrated it's hard to tell where one starts and the other one ends) and allows you to see fairly detailed traces of what happened to which parameter along the way, it's as detailed as any call stack dump. Erlang has a 'let it crash' policy (see Joe Armstrong's excellent paper) which tries to enforce the point of origin and the subsequent crash happen as close to each other as possible (and provides a whole range of mechanisms to deal with the fall-out). A 30 level call-stack like say Java would produce simply doesn't happen in those environments. Though if you programmed in a 'Java' style in say 'erlang' then you could generate one and it would make your life much harder.

Jare 11y ago
No hehe, my experience is mostly C++ PC and console games, so a) let it crash is not viable, and b) performance precludes performing extensive validation (a debuggable but unresponsive game is not viable). In games, messaging troubles are usually related to systems like character behaviour and AI that deal with multiple complex entities responding to the world state and interacting with each other. It's rarely a case of corrupt data and null pointers (those are easier): physically valid yet logically incorrect or unexpected data.
- jacquesm 11y ago
  I think you're missing out on something, have a read and see if maybe 'let it crash' is more than you think it is: http://web.archive.org/web/20090430014122/http://nplus1.org/articles/a-crash-course-in-failure/ http://web.archive.org/web/20090430014122/http://nplus1.org/... https://mazenharake.wordpress.com/2009/09/14/let-it-crash-the-right-way/ https://mazenharake.wordpress.com/2009/09/14/let-it-crash-th...