Why OO Sucks by Joe Armstrong (2000)
cs.otago.ac.nz
Why OO Sucks by Joe Armstrong (2000)
1–10 of 396 posts
Re: Why OO Sucks by Joe Armstrong (2000)
#2Worth noting that most of these criticisms also apply to existential types, which are fairly common in functional languages (e.g. Haskell).
Re: Why OO Sucks by Joe Armstrong (2000)
#3I think this may be another one of those swearing-in-church type opinions, but I think C++ is excellent as a compromise here. It's got its faults, but C++ allows use of objects when necessary or helpful without the ridiculously pedantic OO of Java. It is quite nice to be able to use it when convenient while not having to do so when stupid.
Re: Why OO Sucks by Joe Armstrong (2000)
#4I think this may be another one of those swearing-in-church type opinions, but I think C++ is excellent as a compromise here. It's got its faults, but C++ allows use of objects when necessary or helpful without the ridiculously pedantic OO of Java. It is quite nice to be able to use it when convenient while not having to do so when stupid.
It's one of many languages where OO is optional.
Re: Why OO Sucks by Joe Armstrong (2000)
#5I think this may be another one of those swearing-in-church type opinions, but I think C++ is excellent as a compromise here. It's got its faults, but C++ allows use of objects when necessary or helpful without the ridiculously pedantic OO of Java. It is quite nice to be able to use it when convenient while not having to do so when stupid.
It's one of many languages where OO is optional.
There are other reasons I like it: huge library support, ability to do low-level stuff for performance but use higher-level features for an easier time, etc.
Mostly, I've yet to see something better that has the maturity, libraries, depth of talent (!), etc. that doesn't have problems of its own. It's certainly not perfect, but there are reasons it has remained so popular in many fields.
Re: Why OO Sucks by Joe Armstrong (2000)
#6The thing is ‘filename’ is a bad example for a an object.
Of course, it should be a string. However ‘File’ object is a better example that favors OOP. When you call ‘.read’ on a file object, you expect its content. It doesn’t matter if it’s a windows file, unix file, an IO string, or a web resource. When you call ‘.read’, it just work. Whereas in the functional world, you’ll have to 4 different ‘.read’ function calls with an if statement.
Re: Why OO Sucks by Joe Armstrong (2000)
#7The thing is ‘filename’ is a bad example for a an object. Of course, it should be a string. However ‘File’ object is a better example that favors OOP. When you call ‘.read’ on a file object, you expect its content. It doesn’t matter if it’s a windows file, unix file, an IO string, or a web resource. When you call ‘.read’, it just work. Whereas in the functional world, you’ll have to 4 different ‘.read’ function calls…
I think you could use a curried read function, in this case. The read function would be passed as an argument instead of your I/O stream.
I fear I've slipped somewhat into OO habits by using Go interfaces.
Re: Why OO Sucks by Joe Armstrong (2000)
#8Everything 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.
Re: Why OO Sucks by Joe Armstrong (2000)
#9The thing is ‘filename’ is a bad example for a an object. Of course, it should be a string. However ‘File’ object is a better example that favors OOP. When you call ‘.read’ on a file object, you expect its content. It doesn’t matter if it’s a windows file, unix file, an IO string, or a web resource. When you call ‘.read’, it just work. Whereas in the functional world, you’ll have to 4 different ‘.read’ function calls…
[deleted]
Re: Why OO Sucks by Joe Armstrong (2000)
#10I think this may be another one of those swearing-in-church type opinions, but I think C++ is excellent as a compromise here. It's got its faults, but C++ allows use of objects when necessary or helpful without the ridiculously pedantic OO of Java. It is quite nice to be able to use it when convenient while not having to do so when stupid.
I'd extend the same argument to Python