Live data from Hacker News

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

news.ycombinator.com

11–20 of 234 posts

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

#11
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…

It's "pure fashion" until you try to massage your new subclass into behaving slightly differently when you're living with class hierarchies that are N levels deep.

Clean compositions, ala Scala traits, can be done with OO. It's just not something I've seen in the wild, or something actively encouraged by any OO teachings I've witnessed. At the same time, composition is pretty much the only way FP is taught (at least in my experience).

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

#13
post #6

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

This, 100 times. Program for enough years and you'll find composition such a breath of fresh air. But like any pattern/design, the proof is in the pudding; as in, crap code can be written in any shape or format.

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

#14
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...

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

#15
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".)

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

#16

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.

Eh, I think circling the nouns is useful, but mostly for database entity modeling.

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

#17
post #6

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

[deleted]

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

#18
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…

It's "pure fashion" until you try to massage your new subclass into behaving slightly differently when you're living with class hierarchies that are N levels deep. Clean compositions, ala Scala traits, can be done with OO. It's just not something I've seen in the wild, or something actively encouraged by any OO teachings I've witnessed. At the same time, composition is pretty much the only way FP is taught (at least…

This, basically. People should stop thinking about "composition vs. inheritance" and start thinking of implementation-inheritance and thus OOP in a strict sense as "composition plus open recursion". Open recursion (viz. the fact that methods defined on your "base" classes can invoke 'virtual' methods on self and end up depending on behavior that may have been overridden at any level in the class hierarchy) is quite often a misfeature and not what you actually want, given that the invariants involved in making its use meaningful or sane are extremely hard to usefully characterize.

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

#19
post #6

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

Composition should be favored over inheritance whenever feasible. It is not always feasible so many use for inheritance remain.

What you can do is make composition easier. Kotlin does this with its delegation system: https://kotlinlang.org/docs/reference/delegation.html

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

#20
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.

Post reply on HN