4 ms·

Yeah 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

Yeah 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 just one pixel, yes. In the context of an image processing application, you may need an alpha channel, a grid of pixels, an undo, and so forth. By identifying just one type instead of talking about a problem, RGB, the author has created a circular reference. Why do you need more than a tuple for RGB values if you only have RGB values? Well you don't. But programs are not about tuples, they are about solving problems. Yes, a problem can only require one simple datatype to solve, but in my experience that's only for a very small subset of problems. OOP concentrates just on assembling various pre-existing datatypes into something new in order to solve a problem. It concentrates on the type. FP concentrates on what you are doing with the type. Either way you still need to assemble various datatypes. The construction of a new type doesn't go away. The emphasis is just different. You don't need to worry about a copy constructor or any of that anymore because the goal isn't to create reusable types that can last forever. Multi-core processing and our experience with large systems is killing that concept -- most types don't scale as advertised. So OOP skills aren't going anywhere. It's just instead of creating a complex type, we're using those skills to create the minimally-complex type sufficient for our immediate needs. Big change in focus.

bad_user 14y ago
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) Is it statically type-safe with a good self-documenting structure? Yes. Is it just a simple tuple? Yes. And under the hood Scala also generates a proper equals() with structural equality and the right getters/setters for the values, because in Scala (like in Smalltalk) member access is always done through a method call. And because it is also a class, you can also attach things to the constructor, like runtime checks to make it even more type-safe: case class RGB(r: Int, g: Int, v: Int) { require(r >= 0 && r < 256, "r must be a value between 0 and 255") } Is this OOP? That's indeed a class, but saying that programming with classes as types is OOP is like saying that programming with functions is functional programming. 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.
- DanielBMarkham 14y ago
  "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.
  - SiVal 14y ago
    Instead of C, I would suggest something like Python, where you don't have to learn to make your own shoes before you can start experimenting with fashion. With Python, you can forget about the computer and just think about programming. (I'm talking about pedagogy here, not production, where C is often a better choice.) The fact that OOP was really bolted onto Python as an afterthought means you can learn simple straightline code, then start clustering it into functions as it starts to get more complex then, eventually, start clustering functions and data into simple classes where it (occasionally) helps to manage the growing complexity, followed by your own modules. You don't have to start with packages and class hierarchies just to print "hello, world" as in Java, but you also don't have to reinvent the string, as in C.
klibertp 14y ago
> 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 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.

bad_user 14y ago

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) Is it statically type-safe with a good self-documenting structure? Yes. Is it just a simple tuple? Yes. And under the hood Scala also generates a proper equals() with structural equality and the right getters/setters for the values, because in Scala (like in Smalltalk) member access is always done through a method call. And because it is also a class, you can also attach things to the constructor, like runtime checks to make it even more type-safe: case class RGB(r: Int, g: Int, v: Int) { require(r >= 0 && r < 256, "r must be a value between 0 and 255") } Is this OOP? That's indeed a class, but saying that programming with classes as types is OOP is like saying that programming with functions is functional programming. 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.

DanielBMarkham 14y ago
"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.
- SiVal 14y ago
  Instead of C, I would suggest something like Python, where you don't have to learn to make your own shoes before you can start experimenting with fashion. With Python, you can forget about the computer and just think about programming. (I'm talking about pedagogy here, not production, where C is often a better choice.) The fact that OOP was really bolted onto Python as an afterthought means you can learn simple straightline code, then start clustering it into functions as it starts to get more complex then, eventually, start clustering functions and data into simple classes where it (occasionally) helps to manage the growing complexity, followed by your own modules. You don't have to start with packages and class hierarchies just to print "hello, world" as in Java, but you also don't have to reinvent the string, as in C.

klibertp 14y ago

> 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 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.