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

Post by chriswarbo » Mon, Jul 01, 2019, 7:00 PM UTC

ajross wrote: post #5

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 exa…

Post by repolfx » Mon, Jul 01, 2019, 8:23 PM UTC

danielscrubs wrote: post #63

ajross wrote: post #5

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 exa…

You have some good points. But have you tried Idris or Agda? My problem with OO is one of culture. If and only if you work with big codebases you start to feel that you can’t make assumptions about anything. For all I know the plus operator can send nukes. Then they say it doesn’t matter because they made the perfect lasagna with a million layers. I know there’s a million ways to code with oo to make it better. But I…

Post by repolfx » Mon, Jul 01, 2019, 8:37 PM UTC

paulhodge wrote: post #48

OOP was a huge trend in the 90s and I think a lot of devs have learned from experience the ways in which it kinda sucks.. - It doesn’t do great as the code gets older or more complex. Google “fragile base class problem”. - Inheritance doesn’t do a good job of modeling most real-world problems. Most situations don’t map into a simple “class Dog extends Animal” kind of hierarchy. Steve Yegge’s “the kingdom of nouns” is…

Post by chriswarbo » Mon, Jul 01, 2019, 10:15 PM UTC

repolfx wrote: post #204

chriswarbo wrote: post #200

Earlier quoted context omitted.

> There's nothing wrong with object methods (that's 100% pure syntax vs. a function call) Not really; in OOP a method call like `foo.bar(baz)` sends the `foo` object the message `bar` with argument `baz` (in Kay's current terminology); or, in more 'mainstream' terminology, it looks for a method in the `bar` slot of `foo` and calls it with `baz`. As far as I'm aware, this is a pretty core concept in OOP: if our code i…

You can do that sort of thing in Kotlin, which is an OOP (well, multi-paradigm) language: inline fun 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() You have to be careful with type inference: if there's no way for the compiler to figure out what type you want…

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

Post by nullwasamistake » Mon, Jul 01, 2019, 11:25 PM UTC

apta wrote: post #182

nullwasamistake wrote: post #8

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 fun…

> They eliminate inheritance, replacing it with interfaces. Exposing the objects for what they really are, structs with functions attached, makes this strategy easier. I don't see how this is not already achievable in Java or C#. No one is forcing you to use inheritance. And when you really need it, it's there for you to use instead of jumping through hoops.