That's the problem with language design: too much opinion, too little decision making based on actual data.

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.

Bah MI was given a bad reputation by Java fans but their arguments weren't very persuasive.. The diamond issue? As shown in the article, it isn't really an issue, Eiffel actually use this solution.

The author is explicitly using Kotlin as one of their inspirations, and IMO has a pretty reasonable approach to multiple inheritance (and I suspect they would agree that extension methods are preferred when applicable). What problems does MI cause that aren't fixed by OP's solution to diamond inheritance?

Kotlin extension methods can't be grouped and abstracted over like traits can. And moreover they are not virtual methods. Virtual methods are useful for all sorts of reasons.

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.

If you want your language to be called “Object Oriented”, it needs to support implementation inheritance. (Encapsulation and interfaces predate OO).

My personal take is that implementation inheritance is a bad idea, and, by extension, Object Oriented programming is a dead end.

Lol, can't ignore the Lebowski reference :) good one! I actually think it is very subjective list :)

Personally I would drop the static type system and reinvent Self.

After working in Python and Ruby I don't think I could ever choose a dynamically typed language for a project with more than a few thousand lines. There's just a lot of safety, and documentation, you get cheaply when using static types.

Ruby has conventions and a big testing culture which helps mitigate a lot of those issues. I also work with Typescript and I see whole classes of bugs that could be avoided if everyone just stuck with conventions and best practices.

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}

There’s languages like Python and Ruby and then there’s languages like Smalltalk, Common Lisp, Self or Clojure: if dev-time is runtime, you miss compile-time checks a lot less

Cue the "Dynamic Languages Fail At N Lines of Code" bikeshedding as if Facebook, AirBnB and Shopify never happened.

...and steal the Soups from NewtonScript on the way.

What are the soups?

Both Google and DuckDuckGo give me no results so an example would be appreciated.

(Hope I'm not caught up in a prototype joke :)

Chapter 11-7 of https://www.newted.org/download/manuals/NewtonProgrammerGuid... using the Self influenced language NewtonScript https://www.newted.org/download/manuals/NewtonScriptProgramL...

My impression of systems like soups/OpenDoc/component systems/etc is that they're doomed to failure because they don't respect Conway's law. The app model works because each app has its own development team and teams aren't directly editing other teams' data.

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.)

Soups and OpenDoc have no actual relation. Soups is a object file system and OpenDoc was a component system. CoreData is a poor successor to NeXT's EOF. I so miss EOF.

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.

"Data in Newton is stored in object-oriented databases known as soups."

https://en.wikipedia.org/wiki/Apple_Newton#Data_storage

time to dust it off and sell it as new ?

Yeah - I think the kids are ready for that.

rebrand it `selfie`