> In an OOPL I have to choose some base object in which I will define the ubiquitous data structure. All other objects that want to use this data structure must inherit this object.
So... that's not actually how it works though, right?
Why OO Sucks by Joe Armstrong (2000)
51–60 of 396 posts
Re: Why OO Sucks by Joe Armstrong (2000)
#52Well, I disagree with 99% of this... I'm a guy that started with C, moved to functional programing, added C++, and now do all 3. > Objection 1. Data structure and functions should not be bound together Well, in my experience, in every almost every code-base (either from functional, or imperative programing), we end up with modules, witch are a set of function taking the same type as a parameter. This is very close to…
>Well, in my experience, in every almost every code-base (either from functional, or imperative programing), we end up with modules, witch are a set of function taking the same type as a parameter. This is very close to binding the functions and the types...
And the world is not so neatly divided between things that just are (data structures) and thing that do things (functions). Take a date for example. The fact that it is a Wednesday is a "just is" sort of thing but is typically implemented as a function.
Re: Why OO Sucks by Joe Armstrong (2000)
#53Worth noting that most of these criticisms also apply to existential types, which are fairly common in functional languages (e.g. Haskell).
That's not entirely accurate. Abstract data types (e.g. ML modules) can also be modeled as existential types and don't have the same problems. I think it's the particular combination of only having nominal typing, only allowing the oo-flavor of data abstraction, and encouraging programming with state and using inheritance for code reuse that leads to the object-spaghetti nonsense in heavily-oo Java/C++ codebases.
I just mean that (at least in Haskell) existential types provide information hiding & combine functions with data. In fact, they're implemented with dynamic dispatch, just as with OOP.
The problem is not that OO languages have these features; the problem is that they lack other features common to functional languages.
Re: Why OO Sucks by Joe Armstrong (2000)
#54I think this article is quite old, so I can forgive the author for being out of touch with modern OO language practices. Nonetheless, I find myself disagreeing with almost all of his arguments. When he talks about state for example, I assume he means mutable state. Everyone knows this is best avoided if possible. The vast majority of OO languages provide mechanisms to avoid mutability e.g. data classes or keywords to…
> Everyone knows this is best avoided if possible. The vast majority of OO languages provide mechanisms to avoid mutability e.g. data classes or keywords to make references constant.
Well, clearly not everyone knows it.
My biggest complaint about languages that incorporate functional features is that immutability is most useful when it’s the 99% use case.
When it’s a special tag that may or may not be used within the library/code base you’re using, you don’t get the cognitive advantage of feeling confident you can judge the output of a function by reasoning about its input.
My brain is small. I need all the crutches I can get, and referential transparency is a huge advantage.
Re: Why OO Sucks by Joe Armstrong (2000)
#55Everything sucks, they just all suck differently. I still think OO provides a pretty easy mental framework for programming. You can get good results. Bit of discipline without going crazy and it works really effectively. Despite its shortcomings.
I don't think what I'm about to say is necessarily inherently true, but it reflects how things seem to work in practice: It seems to me that part of the problem is that OO doesn't force you to have discipline and/or without constant vigilance (which product owners are never willing to schedule for) the system inevitably gets out of control over time. On the other hand, it seems to me that the core principles of funct…
Forces discipline is a double edged sword. It can help you keep things clean and understandable, but it can also limit things. For example: I am pretty good with react and redux, but I was more productive with JQuery. JQuery doesn’t have the forced discipline of react+redux, but it gets the job done. At the same time, I’ve seen larger amounts of crap JQuery code than React+Redux.
The real issue: discipline has to be learned, often by experience, it isn’t forced. If you force it, then no one knows why things are they way they are.
Re: Why OO Sucks by Joe Armstrong (2000)
#56[deleted]
Re: Why OO Sucks by Joe Armstrong (2000)
#57Everything sucks, they just all suck differently. I still think OO provides a pretty easy mental framework for programming. You can get good results. Bit of discipline without going crazy and it works really effectively. Despite its shortcomings.
I don't think what I'm about to say is necessarily inherently true, but it reflects how things seem to work in practice: It seems to me that part of the problem is that OO doesn't force you to have discipline and/or without constant vigilance (which product owners are never willing to schedule for) the system inevitably gets out of control over time. On the other hand, it seems to me that the core principles of funct…
Just my personal anecdote. The only functional programming languages I have extensive experience with are C and JS. I have NEVER seen a sensibly organized or maintained medium to large sized C or JS application. Every time it's been total chaos. In Java projects, there's a 50/50 shot of it being moderately sensible. I'm confident other people have completely different experience. Based on your post it sounds like you have had a different experience, and I have no trouble believing that. Anyways, just my $0.02.
Re: Why OO Sucks by Joe Armstrong (2000)
#58I have seen a lot of posts bashing OOP by FP advocates. They write so many points explaining why OOP sucks, however, strangely few of them try to present why and how FP can be better in those points. Most of them assume that FP is unconditionally better in all aspects of coding, so they don't even try to explain.
This post is not different.
Re: Why OO Sucks by Joe Armstrong (2000)
#59I think this article is quite old, so I can forgive the author for being out of touch with modern OO language practices. Nonetheless, I find myself disagreeing with almost all of his arguments. When he talks about state for example, I assume he means mutable state. Everyone knows this is best avoided if possible. The vast majority of OO languages provide mechanisms to avoid mutability e.g. data classes or keywords to…
[deleted]
Re: Why OO Sucks by Joe Armstrong (2000)
#60Earlier quoted context omitted.
I don't think what I'm about to say is necessarily inherently true, but it reflects how things seem to work in practice: It seems to me that part of the problem is that OO doesn't force you to have discipline and/or without constant vigilance (which product owners are never willing to schedule for) the system inevitably gets out of control over time. On the other hand, it seems to me that the core principles of funct…
Just my personal anecdote. The only functional programming languages I have extensive experience with are C and JS. I have NEVER seen a sensibly organized or maintained medium to large sized C or JS application. Every time it's been total chaos. In Java projects, there's a 50/50 shot of it being moderately sensible. I'm confident other people have completely different experience. Based on your post it sounds like you…
In this context, C and JavaScript would not be considered functional. They have functions, but that's not what most people mean by "functional". While it's possible to restrict yourself to a functional subset in both of them, they would typically fall into the "imperative" category.
Imperative programming languages (like C and JavaScript) don't generally impose any discipline on the users.