I'll bite. I believe the consensus for the 20s for error handling is to have both exceptions and error types (or just error pairs). Without exceptions the code

I'll bite. I believe the consensus for the 20s for error handling is to have both exceptions and error types (or just error pairs). Without exceptions the code starts to bloat up with various try's, ?s, unwraps, pattern matches on sum and option types and nonstandard do notations. You start writing a nice and simple code when prototyping, only to end up with unreadable piece of mess when productionizing and wrapping everything with error handling. Most modern languages which boast for not using exceptions have them anyway, but call them panics or aborts and don't provide first class support for them. I believe the next paradigm beyond OO and FP is data oriented programming. One could argue that it is what FP is, but modern FP means more Type Oriented programming than Functional Programming. In contrast with Lisp and APL family, which are also considered FP, but whole another class. OO gets lots is the kingdom of nouns, as the article points out. You often can't even use a stupid function without wrapping it in some class. Type programming makes a type for everything and gets lost in the kingdom of types. You often can't even start programming before you type your data or provide schema for it. In Data Oriented Programming, you try to limit the number of objects or types to minimum, such as simple linked lists (Lisp) or multidimensional vectors (APL, numpy, tensorflow), json dicts (python, jq), streams of text (shell), tables (sql) or primitives - strings, ints, etc. The big benefit is that you can start coding immediately without defining any classes or types and most operations are already defined for you in a performant way. Once you introduce your custom classes or types, you lose the benefit of carefully designed operations on the language primitives that allow you to stay within the algebra of those language primitives. Eg. in APL you have arrays and numbers and they combine in infinite amount of ways which have been carefully explored and designed over decades for very ergonomic use. I believe the future is to have small amount of versatile types, not to create languages which promote complexity by introducing tons of non-interoperable custom types.