"First, a few obvious, non-negotiable things any new OO language should have: ..."
Well, that's like your opinion, man ...
Well, that's like your opinion, man ...
The author says there should be no Exceptions and there should be multiple inheritance... I mean, these seem like pretty extreme positions to have when talking about an OO language... if I remember correctly, multiple inheritance, in particular, was one of the features the languages from the late 90's had actually stayed clear of as it had been shown by the previous generation of languages that it was a mostly bad idea. I think even inheritance as done in Java is not the best of ideas, and there seems to be evidence extension methods or, similarly, type classes, are better suited to add behaviour to data structures.
IMO languages like Kotlin and Swift are much more like what modern OOP languages should be than what the author proposes.
My personal take is that implementation inheritance is a bad idea, and, by extension, Object Oriented programming is a dead end.
In Kotlin extension methods are best used as a nice way to add utility methods to code you don't directly control, and as part of the 'extension lambda' system that lets you make DSLs. The way Kotlin defines language integration features using methods with magic names makes it easy to add a thin layer on top of a Java API that makes it much nicer to use, without needing to fork or patch the actual library itself.
Both Google and DuckDuckGo give me no results so an example would be appreciated.
(Hope I'm not caught up in a prototype joke :)
They don't have the proper expertise and will break something, because it's not possible to enforce data consistency well enough. (Apple's modern OO database is called CoreData, has a pedigree from WebObjects, and its consistency features are pretty hard to use in practice.)
The only connection to editing someone else's data was the ability to add fields to soups for things like Contacts which allowed an easy expansion. Given how many programs on UNIX can alter each other's data, I don't agree with Conway in the context of the file system or soup.
If you like Ruby and wish it had types, check out Crystal. It's basically Ruby with Go's concurrency model, and it's as fast as Go.
{Edit: repetition}