The current trend in computer game architecture is also away from OOP/inheritance and to Entity-Component-System designs where you have entities without behavior (often just an Id) that are composed of components (pure data structures) that are operated on by systems specialized to single or small sets of components (functions).
Ask HN: Why do new(ish) programming languages eschew OOP features?
141–150 of 234 posts
Re: Ask HN: Why do new(ish) programming languages eschew OOP features?
#142Earlier quoted context omitted.
Class hierarchies are the best way to structure OOP programs. The main reason why people started moving away from OOP is precisely because those people didn't know how to structure their programs correctly. With functional programming, you can write correct code without any structure... It's extremely hard to follow the logic but it works. IMO full functional programming is a bandaid patch which allows incompetent de…
SmallTalk would beg to differ. Javascript as well. And I worked with large, fairly OO-oriented codebases in JS, and it was fine and I didn't miss inheritance.
When I say class, I don't explicitly mean using the class keyword. Also when I say hierarchy, I don't mean only inheritance (composition is also a kind of hierarchy). In my statement, I mean class more like "a kind of structure from which you can create instances", prototypes are similar to classes in that way. Definitely you should still follow some kind of hierarchy when using prototypes... In fact you should be even more careful.
Re: Ask HN: Why do new(ish) programming languages eschew OOP features?
#143It depends on what you mean with OOP. If you mean the original meaning: just messaging, extremely late binding, hiding the state etc. OOP never took off.
The established meaning is using classes as some kind of abstract data type with getters and setters or using classes interfaces. That kind of OOP is usually supported.
Re: Ask HN: Why do new(ish) programming languages eschew OOP features?
#144Unpopular 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…
Unpopular answer to the unpopular answer: OOP was pure fashion .. “Our customers wanted OO prolog so we made OO prolog” .. http://harmful.cat-v.org/software/OO_programming/why_oo_suck... .. screw things up with any idiotic "object model" crap. .. http://harmful.cat-v.org/software/c++/linus
I always figured that the main thing people really wanted out of "OO" was simply namespaces. People forget about dealing with older programming systems with global namespace (C, Matlab, Fortran, etc). Namespaces were a big step forward, and in the early days, most of the languages with them were OO, so it would be easy to mistake the benefits of namespaces for OO magic.
OO crapola also mapped reasonably well onto GUI design. That's a whole class of programming that doesn't really exist any more. Where it does (I dunno what people use besides Qt), it looks kind of objecty.
Re: Ask HN: Why do new(ish) programming languages eschew OOP features?
#145I was a big fan of OOP in theory when I learned it in the 90s and I still use it quite often, but in practice, any sizable OOP codebase that I've had to work with is _way_, _way_, more difficult than a non-OOP codebase that just directly solves the problem in a straightforward way. OOP encourages adding layers of abstraction, indirection, and generic stuff that sounds great if you're trying to create some kind of gen…
> OOP encourages adding layers of abstraction, indirection, and generic stuff [...]
Generics/templates and indirection are not OOP. Procedural style encourages them as well. You can see that in C++ itself.
Re: Ask HN: Why do new(ish) programming languages eschew OOP features?
#146I think there are many useful ideas in OOP languages and I still struggle with purely functional languages, I think/hope we'll see increasingly mixed model languages.
I'd be interested to see a language like C# but with:
+ Immutable by default.
+ 'Free' functions, so they don't have to be in classes.
+ No inheritance.
+ Some sort of distinction, and I'm not clear how it would work yet, between data objects (immutable fields/properties and pure functions) and service objects (functions only, but with the ability to constructor inject dependencies).
+ Purity to be a method signature level contract, enforced by the compiler.
+ C# 8 approach to nullability, e.g. Maybe types.
+ Data 'shapes' as well as/rather than interfaces. So you can require that a method parameter must have some shape, e.g. some property or method, rather than having to implement the interface/inherit.
I think parts of these exist in lots of other languages, or are on C#'s roadmap, but every other language I've tried feels, to me, like it's missing the amazing productivity of C# (and I'd guess Java) where the available IDEs, packages and core libraries are still way ahead of many other languages.
I guess the described language might be closer to F#, but when I tried F# it felt like it was missing the obvious "here's how you actually build a thing" part. A lot of functional language material talks about avoiding state, or not changing state, but that's the point where most the applications I build actually do something useful. So for me it was missing obvious on-ramps for building a website, or a desktop application, perhaps things have changed more recently?
Re: Ask HN: Why do new(ish) programming languages eschew OOP features?
#147I'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…
> Object-oriented style inheritance is unsound (inheritance is not subtyping)
Most modern OO type systems rule out unsound inheritance. (Java, Scala, etc.)
Re: Ask HN: Why do new(ish) programming languages eschew OOP features?
#148I think there are many useful ideas in OOP languages and I still struggle with purely functional languages, I think/hope we'll see increasingly mixed model languages. I'd be interested to see a language like C# but with: + Immutable by default. + 'Free' functions, so they don't have to be in classes. + No inheritance. + Some sort of distinction, and I'm not clear how it would work yet, between data objects (immutable…
Not a favorite language of mine, but I think Kotlin comes close to your description.
Re: Ask HN: Why do new(ish) programming languages eschew OOP features?
#149Earlier quoted context omitted.
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
Of course, it is possible to totally eschew inheritance as a language feature . Go does it nicely and I can’t think of many circumstances where modeling my code has suffered as a result, usually the opposite. That said I don’t claim inheritance to be useless by any means, and I would not use Go for every kind of software.
I didn't claim it is impossible either :)
I kinda agree. Still, for an imperative language I think it's a tool I'd like to have in my toolbox, or at least it needs a compelling alternative, which I don't think Go has (1). Of course there are many cases in which you can do perfectly without.
(1) I know it has composition through struct embedding, but not real inheritance: a method delegated to the embedded struct can't call back a method on the embedder automatically. If you do know of some other means in which Go can replace this kind of inheritance, I'd be happy to hear about it.
Re: Ask HN: Why do new(ish) programming languages eschew OOP features?
#150I was a big fan of OOP in theory when I learned it in the 90s and I still use it quite often, but in practice, any sizable OOP codebase that I've had to work with is _way_, _way_, more difficult than a non-OOP codebase that just directly solves the problem in a straightforward way. OOP encourages adding layers of abstraction, indirection, and generic stuff that sounds great if you're trying to create some kind of gen…
> OOP encourages adding layers of abstraction, indirection, and generic stuff [...] Generics/templates and indirection are not OOP. Procedural style encourages them as well. You can see that in C++ itself.
C++ is OOP, though.