4 ms·

> now with events that are harder to trace than function calls would have been I don't know how this could be true. Events are things - nouns which can be bac

• sattoshi 2y ago
  How is it not true? Instead of tracking data and function calls over a unified stacktrace, you track Things and Messages over databases, queues, and logs —- none of which you can trivially attach a debugger to. I generally like event-driven architecture, but I need to admit that debuggability is sacrificed where it matters most.
• lmm 2y ago
  There's no "find usages" for events, and it becomes harder to find out why something didn't happen. A function call can't simply "not return" - in the worst case you get an exception, or a stuck thread in the caller that will show up in a stack dump. But downstream event processing can very easily just not happen, for one of many different reasons, and out-of-the-box it's often difficult to investigate.
  • soulofmischief 2y ago
    In JavaScript, const myEvent = 'myEvent', target = new EventTarget() target.on( myEvent, () => { console.log( "It's easy to introspect well-organized code." ) }) target.dispatchEvent( new Event( myEvent ))
    • lmm 2y ago
      Yeah, good luck remembering to do that up-front for every event handler. You missed one? Whoops, enjoy the information you wanted silently not being there when you need it.
      • soulofmischief 2y ago
        Remembering to do what? Properly maintain a list of constants and enums to use throughout my application? That's not something I have to remember or forget, it's a simple habit that is as natural as importing and referencing a function. As a general rule, numbers and string literals should never be hardcoded. Internalizing this should be a base expectation of any high-performing team member.
  • friendzis 2y ago
    > A function call can't simply "not return" Remember "callback hell"? Assumption that a function call returns after running to completion requires rather specific synchronous cascading architecture, which WILL break in multithreaded code. Most of the multithreaded function calls will set a flag in shared memory and return early, expecting caller to poll. If your API is based on single entry-point `invokeMethod(callee, method)` it is equally untraceable to event entry point `fireEvent(producer, event)`.
    • lmm 2y ago
      > Most of the multithreaded function calls will set a flag in shared memory and return early, expecting caller to poll. Which is exactly switching from function calls to event-driven architecture, and the problems with that are exactly the problems we're talking about.
      • friendzis 2y ago
        The problems you describe are inherent to indirect invocations and are related to event-driven architectures only because typical event dispatching architecture is built on non-blocking calls. You do not even need return-early (non-blocking) semantics for these problems to manifest. You can implement a giant string-keyed vtable for all methods in your program (or use a language with advanced reflection capabilities) and will have exactly the same problems. Namely there probably won't be tooling to match caller-callee pairs, which is the core issue here.