101–110 of 234 posts
That being said iS an area where OOP is definitively worse than FP: In fact OOP (as defined by JAVA and C++) is Categorically less modular than FP.
There is concrete and definitive reasoning behind why this is the case.
I've explained it all in a thread before I'll just link it for people who disagree or are curious.
The general idea of bundling data definitions with code that operates on the corresponding data seems to mesh well with how most people think and remains hugely popular. Encapsulation has proven useful. Runtime polymorphism is very useful in a proper context and all the languages that you list have some support for it, although this support is not taken to the extreme - e.g. it may be more useful to think of the number 42 as a value rather than as an Object. The most controversial feature is inheritance - deep inheritance hierarchies have proven problematic so new languages discourage it or provide limited support.
Another trend is that ideas from e.g. FP have also entered mainstream and there is an expectation that new languages will provide support for useful features associated with other paradigms so most new languages can be described as multiparadigm rather than strictly OOP.
Client-side moats and rise of the Web. A big idea of OOP is to allow components to evolve independently. Java ensures that today's code would run on next year's JVMs and class libraries. Your user's upgrade their OS and your app keeps running, and now supports dark mode. Rad, right? But new languages like Rust/Go/etc have bincompat as a non-goal. A minor version bump means fix the compiler errors, recompile the unive…
>But new languages like Rust/Go/etc have bincompat as a non-goal
Sorry but this has nothing to do with OOP
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
Nim isn't object oriented either, it's procedural oriented just like C. Experienced Nim devs avoid methods and inheritance and only use them after very careful considerations.
Mutation is needed to implement low-level stuff and have deterministic memory usage.
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…
I don't code Scala, but aren't these traits approximately same as interfaces in C#? Interfaces are used a lot in the wild, including in the standard library, they're often generic, IEnumerable, IComparable, and so on.
Earlier quoted context omitted.
Open recursion is pretty much core to the most useful OOP idiom, which I would assert is UI component toolkits. UI heavily relies on a large number of conventions that the user learns to expect to cat in certain ways. You can parameterize a UI widget that encapsulates these conventions with function pointers or overridden methods, but the end result is pretty much the same. I'll strongly agree however that far too fe…
Except UI trees are probably the worse place for objects In PHP for example all query builders are meant to be used as a tree of objects, which means if you want to recursively change the table names used by the query you're out of luck because that state is often private and behaviour not implemented Or maybe you want to inspect the query as data at runtime or assert against its shape or deeply update or delete or c…
Objects are a bit weaker for UI as a projection of a domain data model, especially when it needs to be reactive to changes in the underlying data. The more the UI is data-bound, the more I prefer a functional / data flow idiom.
Earlier quoted context omitted.
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 don't see that follows. The flood of OO languages in the early 90's went hand in hand with a very broad reorientation of the way design was done. That that had bad side effects isn't really a rejection of the fact that OO design really was a fundamentally different way of thinking about problems, and languages that supported it syntactically were doing so to enable this paradigm shift. That's not really "fashion" i…
I disagree, I'd say all of the quoted languages are attempting to fundamentally change things to get around the expression problem[0][1]
I would say Rust, Go and maybe even Nim are fairly Object Oriented. Only thing that is going away are class hierarchies as a method to structure programs, because it seems they are more trouble than worth?
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…
OOP is a subset of the broader category of polymorphism, and it premised on a broken analogy, which posits that data and the transformations that can be applied to them are similar to actions upon 'objects', and that specializations of objects are perfect subset of ideal 'class' categories. This analogy is vaguely useful to introducing basic programming to uninitiated, but the analogy is neither true in the real worl…
The analogy you describe is only broken if you're doing something that it doesn't work for. It's great for simulations and games, for instance.
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 is.
The strength of a language isn't just in what allows you to do, but also in what it limits you to do.
OO in the style of C++/C#/Java is extremely flexible in terms of code organization. This means that most codebases eventually grow towards a mess of different styles and inconsistent design patterns. One guy's abstraction is the next guy's unnecessary plumbing. Teams often have to manage consistency of style and structure through out-of-code agreements.
The advantage of paradigms like procedural or functional programming as well as trait based "OO", is that there is generally an obvious way to structure something. Two different programmers working on the same problem, are likely to produce similarly structured code. The result is that different programmers will adopt much easier to different codebases.