Ask HN: Why do new(ish) programming languages eschew OOP features?

Imho, OOP is part of a greater puzzle.

There are domains where OOP fits perfectly, there are domains where functional programming fits perfectly, there are even domains where imperative programming fits perfectly.

We're constantly searching for the perfect fits-it-all solution which we haven't found yet. From my POV this is why there are some competing standards, which all have their merits but on a first glance exclude each other.

OOP made for great tool sets, training seminar and other products. But the mentality of "circle the nouns in your requirements" is stupid, and serves nobody. Programmers analyze they're requirements into code and data, and those things have little bundling to one another or the requirement domain.

Maybe because traditional OOP is already well represented by popular languages with large ecosystems? Creators of new languages want to do something new.

There is Elixir / Erlang which many consider to stick more closely to the original idea of OOP.

Unpopular answer: pure fashion.

There's nothing wrong with object methods (that's 100% pure syntax vs. a function call) and an implicit "this" scope for symbols (which is just a limited form of dynamic scope[1]). They don't make code hard to understand. OO can be abused to produce bad designs, of course, but that's not an indictment of its syntax.

Non-syntactic aspects are maybe a more involved discussion. For an example, I personally think traditional OO lends itself very nicely to runtime polymorphism. And this is something that more modern languages have really struggled with (take a random new hacker and try to explain to them virtual functions vs. trait objects). Now... polymorphism can be horribly abused. But, it's still useful, and IMHO the current trends are throwing it out with the bathwater.

[1] Something that itself has long since fallen out of fashion but which has real uses. Being able to reference the "current" value of a symbol (in the sense of "the current thing we are working on") is very useful.

    var flip = function(f) { return function(x, y) { return f(y, x); }; };
    var rab  = flip(bar);

    bar(foo, baz) == rab(baz, foo)

    inline fun <reified T> String.fromString(): T {
        return when {
            T::class == String::class -> this
            T::class == Int::class -> Integer.valueOf(this)
            else -> TODO()
        } as T
    }

    val str: String = "abc".decode()
    val int: Int = "123".decode()

    inline fun <reified T> String.fromString(): T {
        return when {
            T::class == String::class -> this
            else                      -> T::fromString(this)
        } as T
    }

Inheritance makes some sense, but composition is much, much easier to understand and work with. Inheritance has well documented problems that composition does not. It’s not so much about being object oriented or not, at least not directly.

I could elaborate, but others have said it better anyways.

https://en.m.wikipedia.org/wiki/Composition_over_inheritance

   {...students(ajaxDb), ...teachers(ajaxDb)}

   public class StudentsAndTeachers extends Students implements IStudents, ITeachers {
       private _teachers;
       public constructor(Database db, Teachers teachers) {
           super(db);
           _teachers = teachers;
       }
       public getTeacher(TeacherId teacherId) {
           return _teachers.getTeacher(teacherId);
       }
   }

   new StudentsAndTeachers(ajaxDb, new Teachers(ajaxDb));

A big change in my life was reading the Tao of objects -- https://www.amazon.com/Tao-Objects-Gary-Entsminger/dp/013882... along with the great Coad-Yourdan OOA/OOD books -- example: https://www.amazon.com/Object-Oriented-Analysis-Yourdon-Comp...

The premise was great. We reason about things as real-world objects, if we organize our code the same way, we can reason about our code.

Twenty-plus years later, In practice, however, I'm given a graphics object with a DisplayText method. It has three parameters, two of which are optional. If I call it with text I want displayed? It is an extremely rare event that what I wanted to happen, happens.

It gets much worse from this simple example, with versioning, monkey-patching, and overloading (ouch!). Add in multiple languages using the same codebase? Mutable code?

The maintenance programmer is left with a general concept. Under that concept there is code. Whether that concept maps to the concept the users asked about, or what changes in state that code makes? Nobody knows.

It's worse than bad. The incoming programmer is given concepts he thinks he can reason about, but which rarely match what's actually happening.

To combat that, the OO-mutable guys have gone to TDD. Test-first, then code.

That's a survival skill in modern programming, but all it does is change the definition of "What is a foo?" from a free-wheeling conversation to a concrete executable set of tests. And that is assuming you use it everywhere.

OO was a big-picture, conceptually-simple way of organizing code for big projects. We had a bucket for everything.

We ended up with hundreds of buckets that were confusing and we were never sure what belonged where, or if we touched one thing what other things might happen.

Functions, however, remained very simple. No matter what the function does, is it something you want or not? As long as you keep it simple and immutable, over time you keep building up and honing a reusable set of functions: tokens describing important things you want the system to do. As it turns out, quite surprisingly to me and others, reasoning and simplifying around what you want the system to do is much more productive and easier to understand than reasoning and simplifying around what you want the system to be

IMO they just expose more of how OOP really works, giving you flexibility.

Take Rust. Just because I like their pragmatic approach. They represent objects as structs with functions attached that have access to the struct data. In C++, Java, etc this is roughly how objects actually work underneath.

They eliminate inheritance, replacing it with interfaces. Exposing the objects for what they really are, structs with functions attached, makes this strategy easier.

Traditional OOP, especially with multiple inheritance, tends to encourage nested objects (structs) that become hard to reason about.

Another related innovation has been structural typing. Typescript is great with this. Essentially, if you have two "objects" with the same fields, you can assign them to eachother freely. Typescript doesn't care if they actually inherit from eachother. If the interface signatures are compatible (matching fields, matching types), they can be freely used in eachothers place. This is great for constructing anonymous objects to pass off without all the cruft, basically just Json fields.

TLDR: newer languages decided that if two objects look like ducks they are both ducks, even if you decide to call one something else. Because who really cares what you name your ducks or which ducks they inherit from. This breaks from traditional OOP by loosening the rules of inheritance, but so far it's been a boon for productivity (for me at least)

For a long time, abstraction was the name of the game. OOP is the most popular way to achieve a higher level of abstraction.

Programmers have noticed that infinite abstraction was not necessarily a good thing to have (or an easy one to achieve with a good design).

They had neglected alternative paradigms and lower level languages. They had hoped to just abstract C away, and forget about it. Now they want to replace C instead of abstracting it away.

If you'd like to hear the case against OOP in modern programming, the Rich Hickey talks are a pretty good place to start:

* The value of values

* Simple made easy

* Are we there yet?

I'm on mobile, but you'll find these easily on the google.

With lambdas classical oop (virtual functions) becomes less of a necessity... That and past overdoses of oop.

The author of the article below lists the strengths of Object Oriented Programming:

1. Encapsulation

2. Polymorphism

3. Inheritance

4. Abstraction

5. Code re-use

6. Design Benefits

7. Software Maintenance

8. Single responsibility principle

9. Open/closed principle

10. Interface segregation principle

11. Dependency inversion principle

12. Static type checking

He then goes on to debunk them showing alternatives from functional programming.

http://www.smashcompany.com/technology/object-oriented-progr...

Traditional OOP is a basket and sometimes conflation of multiple powerful concepts, which can be very convenient, but don't always fit the problem well. In practice, if the only tool you have is a spinning electric fan of hammers, your problem can get an awkward and painful shoehorning.

Back when it seemed most people were doing Java, we expected any new language to be OO. At the time, when a new language design chose not to provide traditional OO... that could be for elegance of the language design, and (by accident or design) also a nudge to programmers, to learn how to use other concepts.

And, with some languages, the language is powerful enough that you can layer a reasonable implementation of a traditional object system atop their primitives, if you want to.

FWIW, Racket (a Scheme descendant) has always had an traditional object system library (ordinary class-instance, plus mixins), which was used for its cross-platform GUI library and IDE application framewok, but is not often used for other things. Racket's somewhat simpler `struct`, however, is used heavily, for all sorts of things, as are the traditional basic Scheme/Lisp types. Scheme/Racket procedures are also used heavily, including to do things that you'd use objects for in some other languages. And Scheme (and especially Racket) also gives you very powerful tools for syntax extension, which, among its uses, can do things elegantly that would be pretty messy or nonviable to do with traditional OOP classes. You can also roll your own object library in Scheme/Racket -- I once quickly whipped up a simple prototype-delegation model as an extension to portable Scheme, as an exercise, and this is within the abilities of any fairly new Scheme programmer.

(I'm not disrespecting OO. I'm a long-time OO person, in several languages, including having been a commercial developer of fancy OO developer tools, and tend to architect (at least) data of systems with OO or entity-relationship. But, programming-wise lately, I've mostly been working mostly with what used to be considered non-OO "paradigms".)

any sufficiently complex OOP program is indistinguishable from black magic.

OOP tends to encourage going through more layers of indirection than necessary or helpful, which makes the flow hard to follow. E.g. instead of just calling a library method, OOP frameworks might have you extending a framework class. This makes OOP code difficult to debug and maintain.

Depending on who you ask, "trend" could be replaced with "progression".

I'm with you in that I never really found the OOP style to mesh well with my brain. I always felt like I had to fight it and dealing with massive chains of class inheritance can make it really hard to reason about and change code. I've spent years building web apps with Python and Ruby too.

Having only spent a short while with Elixir, I'm finding semi-complicated topics and patterns to be a lot easier to digest even with no formal functional programming background.

Like just today I watched a talk where a guy live coded a web framework DSL in about 30 minutes[0]. One with a beautiful API for controllers and a router. It was a total head explode moment for me (but not in a bad way, it was like seeing the light).

I'm still a newbie with functional programming but so far it feels much more like a WYSIWYG style of programming where your domain is front and center where with OOP it feels like you're bombarded with purposely confusing legal documents and fine print with a small bit of your domain thrown into the mix.

[0]: https://www.youtube.com/watch?v=GRXc-jKRESA

Mostly because it's generally recognized that inheritance was a bad idea. "Prefer composition and interfaces over inheritance" and such.

Also because mutable object state is problematic--it makes a large system harder to reason about and certan types of bugs more likely, and makes thread safety very difficult.

Because they are written by people who never actually understood Design by Contract and class invariants.

Are they avoiding OOP or classes? With some of these languages (Rust, also Swift) you have OOP without using classes. Here is a good video explaining the benefits of using structs and protocols with swift, which are similar to structs and traits in Rust. (WWDC 2015 Protocol Oriented Programming in Swift) https://www.youtube.com/watch?v=g2LwFZatfTI

Many systems people want to build with computers cannot be easily conceptualised as graphs of largely self-contained objects, interacting through swapping messages. These problems instead revolve around complex data processing, and are more easily conceptualised as data flowing through a network of functions, and into and out of containers.

It is possible to build these systems using OO, by reifying the network of functions and the data into objects. But all you are really doing is reinventing functional programming with a layer of OO cruft on top of it, and it is always going to be easier to build the equivalent system in a language that lets the functions and the data structures be unencumbered.

For programming tasks that actually are best conceptualised as objects, OO works quite well. These usually involve the provisioning of some largely static virtual environment, such as a UI, game world, or inversion of control container. Here, objects are long-lived, genuinely independent, and interact in well-defined ways via actions and events, usually swapping only small pieces of state.

My guess is that the advent of GUIs and sophisticated games in the 80s and 90s pushed programmers to be more interested in this latter type of problem, and this was reflected in the languages that evolved. Then the advent of the internet and machine learning in the 2000s and 2010s revived interest in data processing and data flow, and so language design began to shift back.

I suspect in 100 years, if humans are still doing any programming, all popular languages will be mixed-paradigm, and the question of OO vs functional will simply be a blend decided by needs of the problem at hand, rather than the kind of dogmatic arguments of this era, which will be viewed through a historical lens as rather quaint and silly.

Because OOP is a good idea that's been ridden into the ground by dogmatic implementations.

OOP is fine, and it makes sense for lots of things. But going crazy with OOP makes for a mess, and a lot of software and languages and tools have chosen "let's do OOP" over "let's do good software". So non OOP stuff is just the natural backlash to OOP gone wild.

I'm not sure. As someone who's mostly self taught I don't really understand the big deal either way. I mostly learned about the idea behind oop while trying to implement my own classes using metatables in lua and trying to manually deal with problems languages with built in classes deal with for you.

I like the idea of encapsulating functions with data and like the ability to inherit to subclasses. I don't really like languages like java that enforce oop at the language level. I prefer languages like D, python or c++ that offer it as a tool but don't restrict you to writing strictly oop code. I find D's class implentation to be the simplest to understand. With classes being reference types with inheritence and structs being value types lacking inheritence. It makes it clear to me when a type should be a class and when it should be a struct or some other data type.

I think we're just figuring out different problems are solved using different paradigms.

I find complex business logic tends to be best modelled using algebraic data types and functional programming.

I'm not sure I agree with your thesis. For instance, Javascript has recently added an OOP class syntax, and Typescript extends the result with strict types. (JS was of course in some sense object oriented beforehand, but it wasn't recognisable to most working OO programmers as OO.) Moreover, I think you need a deliberately hamstrung language to get a genuinely OOP language - C++ and Javascript are both fully capable of writing OO code, but most people shy from calling them OO languages because they're not limited. A more interesting question is whether new programs are object oriented, and I guess the answer here remains, broadly, yes. This is why Javascript got class syntax.

But I will assume you're a better observer than me, and make the following claims:

I think there's two reasons: Object-oriented style inheritance is unsound (inheritance is not subtyping), so academics don't like it. Moreover, classical OO is not composable or extensible - unless you write your own primitives in every application and end up with Java-like verbosity. Therefore, research in new features tend not to be object oriented. Therefore, new languages tend to adopt non-OOP styles.

The other reason is probably that there's enough OOP languages. The effort it takes to create a new OOP language exceeds the effort it takes to shoehorn your OOP algorithm into an existing OOP language. Therefore, there's less motivation from the engineering side.

On the other hand, there's still lots of scope for better functional style languages; that marketplace isn't exhausted yet. Rust, for instance, merges a lot of academic techniques trialled on functional languages with a systems programming architecture.

Rust, Go, Julia, Nim are all cruly braced, procedural, mutable, object oriented languages.

I think we need languages that bring new paradigms. All that you quoted fail in this respect.

https://www.youtube.com/watch?v=0fpDlAEQio4

Object oriented programming doesn't really fit every problem. It really seems more strange that it took so long for us to see some alternatives.

I mean, it took over programming like a revolution, like structured programming, but structured->OO doesn't have anything nearly like the benefits of unstructured->structured. It seems like a good paradigm for a couple of problem domains, but IMHO, it got cargo-culted on to everything about mainstream programming without delivering much on the promises it got sold with in regard to increased productivity and code re-use.

That basically no modern oop language is actually oop. Smalltalk is an excellent example of what the oop movement could have been, Java is what it became instead.