[kstenerud]

I can't shake the feeling that we're talking about different classes of problems here.

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?

[Ovid]

You're not missing the point. I apparently didn't do a good job of making it clear.

I'm primarily talking about external data/services. Anything which you would ordinarily consider "suspect", such as "reading from a third-party API", is the target here.

The odds of printf() failing are so ridiculously low that I am not going to write tons of code to handle this case. It's not worth the money.

The odds of putMoneyInCustomerAccount() failing are much higher, and the consequences are much graver, so that's a perfect candidate for saying "maybe just throwing an exception ain't the best solution here."

In the case of OOP, particularly in Kay's vision, these objects might be written by someone else, using code we don't see, and thanks to isolation, might be connecting to third-party services which do all sorts of interesting things we don't know about or need to care about. Thus, they're not trusted.

If I wrote the object or I can read its code, and I know what it's doing, I'm not going to sweat it.

I'm also not arguing that we should always make the code that robust. Some things you can recover from or your budget might not allow you to make the system more robust.

[mcguire]

"After a few months, I had rewritten the ETL system to be a fault-tolerant, rules-driven system that could handle the radically different data formats that pharmaceutical companies kept sending us."

Oddly enough, I'm currently working on exactly this sort of thing, for financial data. And I've been cursing the guy who wrote the initial pass at it, the state of "software engineering" education, and the Pacific Ocean for good measure. It turns out that Mr. Guy is an expert at modern software engineering best practices, dependency injection, unit testing, and ORMs, but had apparently never written a parser. Being an unpleasant and perverse excuse for a human being at this stage of my career, I decided to mostly keep his parser and wrap it in enough error handling to do something useful is some transaction record doesn't have a supplier. That is, rather than rewriting it as a normal-human-being parser or even (heaven forfend) breaking out and learning to use ANTLR. (Whew. I feel better now.)

Anyway, so, yeah, I've been there. I know what you're talking about.

But...

Samuel Falvo II is commenting on a completely different topic. He's not talking about the problem of making a system robust against crazy-pants input or even crazy-pants programmers (well, indirectly...). He's not talking about

"So when fetchDataFromServer() fails, or when an object doesn't respond to the message you sent, what do you? There's a simple way to approach this: ask yourself what you would do in real life."

He's talking about "when an object doesn't respond to the message you sent," how do you know? Don't have a static type system of some sort? If you type "entrie_name" when the message handler is called "entire_name", you won't know until some process tries executing that message send. And if you don't have something like a exception system, you won't even know then. (SIGSEGV, SIGILL, or SIGBUS and the like are really indications that you have just made some grievous error in how you are living your life.)

Falvo, with all his vitriol, is pointing out that the systems of Kay's vision are actively trying to prevent you from writing robust systems. And you have done exactly what he's accused you of doing:

"Don't resort to changing the topic either [...]; the issue is, right then when the error happened... What happens right then and there?

"Until you can answer that question, you have done nothing but bloviate about what is possible in some utopian system...."

[skybrian]

I think some of the confusion here is that code you can't see or change is typically running on a different server, while ordinary method calls are typically about in-process communication. Compile-time checking makes sense for avoiding problems within code that's all going to be compiled together. Runtime error recovery makes sense for remote procedure calls. And there are also situations where you have untrusted code loaded dynamically (JavaScript in a browser).

It seems pretty important to be clear about static assumptions you can trust (because it's compiled in) versus things that can change.

[DonHopkins]

Alan Kay doesn't consider "remote procedure calls" to be "object oriented programming".

http://mythz.servicestack.net/blog/2013/02/27/the-deep-insig...

mythz> On RPC, and how it distorts developers mindsets in architecting and building systems:

Kay> The people who liked objects as non-data were smaller in number, and included myself, Carl Hewitt, Dave Reed and a few others – pretty much all of this group were from the ARPA community and were involved in one way or another with the design of ARPAnet->Internet in which the basic unit of computation was a whole computer. But just to show how stubbornly an idea can hang on, all through the seventies and eighties, there were many people who tried to get by with “Remote Procedure Call” instead of thinking about objects and messages. Sic transit gloria mundi.

mythz> Carl Hewitt being the inventor of the Actor Model and Dave Reed who was involved in the early development of TCP/IP and the designer of UDP.

mythz> The last latin phrase translates to “Thus passes the glory of the world” - expressing his dismay on what might have been.

He also doesn't consider accessing a data field called "entire_name" to be "object oriented programming". He calls that "simulated data structure programming".

https://computinged.wordpress.com/2010/09/15/alan-kay-on-mot...

Kay> If you are “setting” values from the outside of an object, you are doing “simulated data structure programming” rather than object oriented programming. One of my original motivations for trying to invent OOP was to eliminate imperative assignment (at least as a global unprotected action). “Real OOP” is much more about “requests”, and the more the requests invoke goals the object knows how to accomplish, the better. “Abstract Data Types” is not OOP!

[skybrian]

For RPC, substitute "sending a message to a remote machine" if that's what you prefer. Network requests and responses are pretty universal and can be represented in different ways at the language level, but they are pretty different from local requests.

I'm wondering if this stuff could be better explained without going back to what Alan Kay supposedly wanted? If a software architecture idea is good then it should live on its own and others should have elaborations on it.

[mcguire]

As an aside, if you like Erlang, take a look at Pony (https://www.ponylang.io/); it's another take at an actor-based, message-passing, concurrent language with both similarities to and differences from Erlang. It doesn't (yet) have the good robustness story, but there are a lot of good ideas already in place.