This blog post proposes a "data" sanity solution (alternative external oracles, or "scoring" on probabilities, etc) but that's not really what the comment by Samuel Falvo II was about.<p>His problem was <i>syntax getting broken</i> and not about "questionable data". In the context of dynamic vs static compile, he's worried about scenarios like this:<p><pre><code> x = customer.last_name // worked on Friday and x=="Smith"
- remove field customer.last_name // Saturday refactor
+ add field customer.full_name // Saturday refactor
x = customer.last_name // broken on Monday with a runtime error
</code></pre>
With a static type system, the changes on Saturday would have told them <i>immediately</i> at compile time that the last_name field access by other client code was broken. (And yes, one typical answer for handling errors like that in dynamic type systems is <i>unit tests</i> -- but that's veering off into a different conversation.)<p>This essay is a "solution" to a different problem.
I think there's a big difference between not understanding the message, and not understanding the data (a message parameter).<p>When they get an unrecognized message, Objective C objects call their doesNotRecognizeSelector method, and Smalltalk objects call their doesNotUnderstand method.<p>And the object sending the message can first check with respondsToSelector in Objective C or respondsTo in Smalltalk, before sending the message.<p>But validating and sanitizing input parameters is a totally different thing than handling unknown messages, orthogonal to object oriented programming.
> This is the software equivalent of "Not My Problem." ... This is how you deal with unanswered messages. You <i>think</i> about your response instead of just letting your software crash.<p>A terrific 2014 paper, <i>Simple Testing Can Prevent Most Critical Failures: An Analysis of Production Failures in Distributed Data-Intensive Systems</i> [1] found that most catastrophic crashes in distributed systems are a result of catching exceptions and not paying thought to how to handle them.<p>[1]: <a href="https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-yuan.pdf" rel="nofollow">https://www.usenix.org/system/files/conference/osdi14/osdi14...</a> (talk: <a href="https://www.usenix.org/conference/osdi14/technical-sessions/presentation/yuan" rel="nofollow">https://www.usenix.org/conference/osdi14/technical-sessions/...</a>)
I can't shake the feeling that we're talking about different classes of problems here.<p>Data importers and sanitizers are de-rigueur when dealing with real world data, of course. You have to expect to find crazy things inside, and be expected to just cope with it. That's not a problem.<p>But when you're dealing with purely internal systems, the calculus is different. If you had to keep chasing down fopen(), printf(), and malloc() calls, you'd spend more time in administration than you would getting actual work done.<p>So if I'm understanding this correctly, we're talking about purely internal code vs code that traverses domains (much like in DDD), which require different styles of solutions.<p>Or am I still missing the point?
I was asked to do something very similar at a film post production facility for credits. Essentially I was given a day and a half to reconcile spreadsheets of crew member names (compiled by department HODs) with their "credit name" on our employee database in order to create a master for the production company.<p>I had all kinds of issues - variations of names, mispelled names, nicknames, names with the middle name used as a surname (and vice versa) and a few lacking even that. I recall leaning heavily on tables of common names, various Python string normalisation methods as well as soundex. In the end I was left with a dozen or so names which needed follow up but it was pretty good for the ~1000 I had started with initially.<p>The most harrowing part of it all was attending the crew screening - it is actually possible to address issues on an end crawl (provided you catch it early enough) but I really didn't want to be the guy who screwed up the credit of someone who had just spent the previous three months in crunch to get the picture out the door.
I've watched one of Rich Hickey's talk and at some point he brings
that issue on the table, what happens when the receiver is not responding to the message.<p>He is advocating Queues and one of his arguments is that Queues decoupling the requester from the receiver. So you don't really have to worry about things like this by using a queue.<p>[1] <a href="https://youtu.be/ROor6_NGIWU?t=1955" rel="nofollow">https://youtu.be/ROor6_NGIWU?t=1955</a>
Note that "...how you might handle objects that don't respond to messages" refers specifically to what happens when you send a message (or call a method, in the parlance of most non-Smalltalk languages)<p><pre><code> thingy.spamford()
</code></pre>
and the thingy doesn't implement a handler (or a method) for spamford. It has to do with this paragraph from the original, original post:<p>"<i>Kay argues (correctly, IMHO), that the computer revolution hasn't happened yet because while our bodies are massively scalable meat computers, our silicon computers generally don't scale in the slightest. This isn't just because silicon is slow; it's because of things like print customers.fetch(customer_id).last_name not actually having a last_name method, throwing an exception (assuming it compiled in the first place) and programmers getting frantic late-night calls to bring the batch system back up. The only real upside is that it offers job security.</i>"<p>This has nothing to do with network protocols.
Having worked in healthcare IT, I'm less astonished than I should be about approximate matches and score thresholds being used to confirm "same entity" for pharma data. What could go wrong?<p>(Not knocking the author...the practice is unfortunately needed because providers won't provide good data)
This is the original discussion: <a href="https://news.ycombinator.com/item?id=19968496" rel="nofollow">https://news.ycombinator.com/item?id=19968496</a>
There's something I don't understand about the "messaging" metaphor as opposed to the more pedestrian method calling system that most people are used to...<p>What about private methods? Decently written objects in the wild tend to have some private methods that they call on <i>themselves</i>. The highfalutin metaphor of a <i>message</i> goes out the window there, because it's an individual object doing something to itself, not a communication.
The article is making essentially the same argument as this one: <a href="https://dave.cheney.net/2019/01/27/eliminate-error-handling-by-eliminating-errors" rel="nofollow">https://dave.cheney.net/2019/01/27/eliminate-error-handling-...</a>
am I crazy about this? You should have (at least two) type of message guarantees - "don't care" and "must respond", kind of like "udp" and "tcp". Obviously other messaging systems have other types of guarantees, but these seem like they are a reasonable basic.<p>If your agent that send a "must respond" message doesn't get a response within some customizable time, then it itself fails loudly.
Repeat ... coupling and strict error processing kill token ring and let Ethernet win. So is sna and internet.<p>Cross system require much flexibility and to allow for error.
Right, so this is basically the Go approach: explicit error checking on everything. No exceptions, because exceptions are a weird sort of non-local control flow, and can escape and take down your program as a whole.<p>The "if you don't know the answer, find an approximation from another route" is .. situational. In this case it's exactly what the customer wants. In other cases (finance, security, aerospace) it could be a disaster waiting to happen.<p>I worked on a point-of-sale system where it was a matter of design philosophy that any inconsistency should be an immediate crash-and-reboot; since it also operated as a save-everywhere and audit-everywhere system, if you did manage to crash it then within 30 seconds you'd be back at the screen just before the last button press with no data loss other than the button press that caused the crash. I believe this crash-and-recover approach is very Erlang: <a href="https://ninenines.eu/articles/dont-let-it-crash/" rel="nofollow">https://ninenines.eu/articles/dont-let-it-crash/</a><p>Thinking of exceptions and message validation also makes me think of "in band" versus "out of band" signalling and errors. Exceptions are "out of band" - outside the normal function return process. Internet communication is all "in band" and the whole approach of separate control and data planes has almost entirely gone away, apart from SIP and (nearly dead) FTP.