by Ovid on 5/22/19, 8:07 AM with 59 comments
by jasode on 5/22/19, 1:09 PM
His problem was syntax getting broken and not about "questionable data". In the context of dynamic vs static compile, he's worried about scenarios like this:
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
This essay is a "solution" to a different problem.
by DonHopkins on 5/22/19, 1:09 PM
When they get an unrecognized message, Objective C objects call their doesNotRecognizeSelector method, and Smalltalk objects call their doesNotUnderstand method.
And the object sending the message can first check with respondsToSelector in Objective C or respondsTo in Smalltalk, before sending the message.
But validating and sanitizing input parameters is a totally different thing than handling unknown messages, orthogonal to object oriented programming.
by pron on 5/22/19, 2:25 PM
A terrific 2014 paper, Simple Testing Can Prevent Most Critical Failures: An Analysis of Production Failures in Distributed Data-Intensive Systems [1] found that most catastrophic crashes in distributed systems are a result of catching exceptions and not paying thought to how to handle them.
[1]: https://www.usenix.org/system/files/conference/osdi14/osdi14... (talk: https://www.usenix.org/conference/osdi14/technical-sessions/...)
by kstenerud on 5/22/19, 12:27 PM
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.
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.
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.
Or am I still missing the point?
by tjpnz on 5/22/19, 12:12 PM
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.
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.
by geospeck on 5/22/19, 1:27 PM
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.
by mcguire on 5/22/19, 5:15 PM
thingy.spamford()
"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."
This has nothing to do with network protocols.
by tyingq on 5/22/19, 11:27 AM
(Not knocking the author...the practice is unfortunately needed because providers won't provide good data)
by Ovid on 5/22/19, 8:11 AM
by frou_dh on 5/22/19, 3:38 PM
What about private methods? Decently written objects in the wild tend to have some private methods that they call on themselves. The highfalutin metaphor of a message goes out the window there, because it's an individual object doing something to itself, not a communication.
by earthboundkid on 5/22/19, 1:25 PM
by dnautics on 5/22/19, 4:44 PM
If your agent that send a "must respond" message doesn't get a response within some customizable time, then it itself fails loudly.
by ngcc_hk on 5/22/19, 2:02 PM
Cross system require much flexibility and to allow for error.
by simion314 on 5/22/19, 11:56 AM
by pjc50 on 5/22/19, 2:26 PM
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.
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: https://ninenines.eu/articles/dont-let-it-crash/
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.