Hacker News Reader

Comment by phkahler | Hacker News Reader

After seeing GUIs done in Visual Basic 3-6, I decided that event driven anything is a terrible idea.

Even a simple thing like keyboard controlled video games best use a keydown or keyup event to simply set/clear a key state, and everything that cares should monitor (poll) the key state. If your only input is events, convert them to state ASAP because YUK to event driven software. P.S. see Therac-25

View on HN

Sorry how are keyup/keydown events not event-driven software?

I think the point is you're not doing anything with the event immediately, just setting the key state so it can be polled later.

Ironically 5 minutes before I read this I changed a coworkers POC 3d app to use event polling instead of key events as it was horribly unresponsive.

> I think the point is you're not doing anything with the event immediately, just setting the key state so it can be polled later.

Which is event-driven architecture. A component signals that something happened and other components take in that information and update their local state as appropriate.

No, it's not event driven. Maintaining key state up or down and treating it like a discrete I/O input in the rest of the code is not event driven. The event doesn't trigger any behavior. It's an example of how to handle events if that's all you've got as input - map it to non event driven design.

> The event doesn't trigger any behavior.

Yes, that's right. We're talking about EDA, not CQRS or the like. EDA events signal a change of state from one component for other components to synchronize on. They are not commands to react to.

Except when using a USB keyboard and can type faster than the keyboard can determine the keys pressed especially when when using modifier keys like Alt and Shift and the USB bus is being overwhelmed with other USB data.

Stick with a PS/2 keyboard, it makes it easier to spot malware using the USB bus https://wiki.wireshark.org/CaptureSetup/USB

Reply on news.ycombinator.com