I think you're confusing classes with data structures: the first exposes behaviors and hides as much as possible the internal state (data), the second is a low level piece of information.
OOP Isn't a Fundamental Particle of Computing
61–70 of 163 posts
Re: OOP Isn't a Fundamental Particle of Computing
#62Earlier quoted context omitted.
The problem is that most languages touted as non-OOP actually have OO as their kernel data types, like Python, Ruby and JavaScript cases.
Why's that a problem? I like python because it removes a lot of the syntactic ceremony of a "pure-OOP" language; how that's actually implemented is irrelevant.
Because the people that rant against OO make the faux pas of using OO languages as argument.
Re: OOP Isn't a Fundamental Particle of Computing
#63Yeah not so much. I've become a huge fan of FP over OOP over the last couple of years, but I think he missed it. At some point early in any program, you have to concatenate existing types into something else purposed for the solution you are writing. In the OOAD world, we call this moving from the problem domain to the solution domain. Is an RGB value just a tuple? Depends on what the problem is. In the context of ju…
Most people that have a problem with OOP are conflating it with how OOP gets used in Java.
Like if you wanted to represent a RGB pixel on screen, in Java that ends-up being a class having methods like draw() and such. And this is the problem with OOP in Java, because of the limited toolset, you always end up having heavy Objects that have their own behavior instead of functions that operate on a whole composite of such values. Having draw() defined for a pixel is pretty bad design and yet people do it anyway.
Also, some of the common complaints about OOP classes (e.g. you end up having to write boilerplate, like when defining getters and setters and equals and hashCode) are again related to Java and Java-like bureaucratic OOP languages. In Scala all you have to do is this:
case class RGB(r: Int, g: Int, b: Int)
case class RGB(r: Int, g: Int, v: Int) {
require(r >= 0 && r In my opinion Java should never be taught as an introductory language and in universities people should really get exposure to pure forms of OOP, like Smalltalk and CLOS.
Re: OOP Isn't a Fundamental Particle of Computing
#64Yeah not so much. I've become a huge fan of FP over OOP over the last couple of years, but I think he missed it. At some point early in any program, you have to concatenate existing types into something else purposed for the solution you are writing. In the OOAD world, we call this moving from the problem domain to the solution domain. Is an RGB value just a tuple? Depends on what the problem is. In the context of ju…
> So OOP skills aren't going anywhere.
And you're disagreeing with author about what, exactly? He states explicitly that: "applied to problems below an arbitrary complexity threshold, OOP can be verbose and contrived [...] it makes it harder to identify the cases where an object-oriented style truly results in an overall simplicity and ease of understanding"
Also, read (it doesn't hurt) the previous post he links to at the end: http://prog21.dadgum.com/93.html
Basically the author says that OOP should be applied only where appropriate - not to every simple script or every course for beginners.
Re: OOP Isn't a Fundamental Particle of Computing
#65I agree with the author's conclusion "When blindly applied to problems below an arbitrary complexity threshold, OOP can be verbose and contrived" but I think he fails to recognize that the opposite is also true. Yes, it's much simpler to store RGB color in a three-element tuple when you're working on simple code that you've written all yourself. But what happens when get a tuple from somewhere containing {289, 345, -…
> But what happens when get a tuple from somewhere containing {289, 345, -1}? Or god forbid {200, "Monkeyspit", {}}!
You just move type check to runtime and use some kind of contracts... but what does it have in common with OOP? It's closer to classic dynamic vs. static typing argument and as someone pointed out OO type systems are mostly inferior to Haskell's. The point being - it's not relevant here.
Re: OOP Isn't a Fundamental Particle of Computing
#66Yeah not so much. I've become a huge fan of FP over OOP over the last couple of years, but I think he missed it. At some point early in any program, you have to concatenate existing types into something else purposed for the solution you are writing. In the OOAD world, we call this moving from the problem domain to the solution domain. Is an RGB value just a tuple? Depends on what the problem is. In the context of ju…
Most people that have a problem with OOP are conflating it with how OOP gets used in Java. Like if you wanted to represent a RGB pixel on screen, in Java that ends-up being a class having methods like draw() and such. And this is the problem with OOP in Java, because of the limited toolset, you always end up having heavy Objects that have their own behavior instead of functions that operate on a whole composite of su…
"Is this OOP?"
Okay, that's beyond my pay grade. I could argue that either way. OOP is the grouping of data and functionality into units called types or classes. So yes, technically, but I know what you mean.
I agree that Java is a bad way to start, but I wonder if I wouldn't come at it from just the opposite angle. Start with C, move to structs, then move to something like the class you show, then to more complex type creation. After all, C++, probably the most widely-used OOPL on the planet, started with the problems of scaling C.
The problem here is the confusion between "the way things work in language X" and "the way things generally are". I think you need a few OOP languages, and perhaps some functional ones too, under your belt to be able to understand that.
What I think you're getting at is problem-solving strategies. There is a certain problem-solving strategy available in OOP that doesn't make much sense in FP. Many functional guys look at OOP and say something like "It all looks like just a bunch of wiring" -- which is true but misses the point. It works the same in FP, they have ways of solving problems differently than the OOP guys, but that's for another day.
In either case, starting with Java is not so good, if for no other reason than you end up in namespace-land with even the simplest code. Start simple, either with Smalltalk or with C, and work in the more complex pieces.
Note: I _do_ think that any OOP learning experience should end with creating your own robust type system, just like I think any FP learning experience with creating your own parser and compiler. But this also is a topic for another day.
Re: OOP Isn't a Fundamental Particle of Computing
#67Earlier quoted context omitted.
Why's that a problem? I like python because it removes a lot of the syntactic ceremony of a "pure-OOP" language; how that's actually implemented is irrelevant.
Because the people that rant against OO make the faux pas of using OO languages as argument.
Python: "Paradigm(s): multi-paradigm: object-oriented, imperative, functional, procedural, reflective"
JavaScript: "Paradigm(s): Multi-paradigm: scripting, object-oriented (prototype-based), imperative, functional"
Ruby: "Paradigm(s): multi-paradigm: object-oriented, imperative, reflective, functional"
From Wikipedia. So, where the faux pas is?
Re: OOP Isn't a Fundamental Particle of Computing
#68OOP has never been just about computing. It's strength is that it allows the business rules to be most directly mapped to the code that needs to be written. When both parts of this process are performed by the same person it loses much of it's value (until the problem gets larger and you need more than one person). As we have better computing tools in modern languages it is more often the same person. It has never be…
> It's strength is that it allows the business rules to be most directly mapped to the code that needs to be written. Absolutely this. Discussions around OOP vs functional always seem to ignore this massive boon to productivity that OOP brings. Being able to create something of a DSL and map your business rules onto basic operations on this DSL is a huge win. The trick is to design your objects and operations such th…
> Being able to create something of a DSL and map your business rules onto basic operations on this DSL is a huge win.
Hold on - how is this a concept specific to object-oriented programming? Creating a DSL for your problem domain and solving the problem in the new language is exactly what functional programmers have been doing for decades! E.g. here's a mini-DSL in Haskell for parsing CSVs, built on top of the Parsec parsing DSL:
cellContents = many (noneOf ",\n") -- match up to first comma/newline
remainingCells = (char ',' >> cells) -- comma => parse more cells
(return []) -- else done
cells = do first Re: OOP Isn't a Fundamental Particle of Computing
#69Earlier quoted context omitted.
You should worry. If you don't want your server or your app to run slow, you should worry about these things. Can you imagine going into a programming interview and saying something like this? You sound like someone who doesn't really understand performance very well. Lists and strings and arrays as implemented in any scripting language can implement virtually any algorithm with only a constant factor performance and…
Yeah I always hear people saying how Python is slow. But in 10 years of Python programming, I see 2 repeated performance anti-patterns: 1) Writing quadratic loops and not realizing it, then it blows up on a biggish data set. This is quite easy to do in Python because people don't realize that "in" on a list and .remove() and so forth do a linear search. 2) Writing Python like Java, where you have tons of indirection,…
> Writing Python like Java, where you have tons of indirection, which is slow
I've actually just introduced one of my younger colleagues (and pretty new to Python, but knowledgeable in C# and Java) to this 8-year old article: http://dirtsimple.org/2004/12/python-is-not-java.html
I remember reading that article back in the day, I had only begun to do stuff in Python for a year or so, and everything seemed so well explained but here I am now instead still spreading the word :) At least some part of it I hope it's done for good, such as "XML is not the answer", which actually brings back "horrific" memories of Zope3.
Re: OOP Isn't a Fundamental Particle of Computing
#70Well, most OOP isn't object oriented at all, it's class oriented or maybe another way to look at it is that most of the time OOP is used as containers for data and function, not for things. For example, say you have an object that holds some strings and numbers and it has getters and setters on it. How is that different than a Hash? Is that object oriented? If you add a couple helper methods to said object is it more…
> OOP is not that useful for anything other than namespacing Namespacing, and modularization in general, are cornerstones of well structured code. OOP gives you nice tools to help with this.
Namespacing and modularisation are completely orthogonal to OOP. It just happens that recent languages sold as "OOP" have namespaces and modules.