60 ms·

Provocative. The suggestion is that thinking in OO terms makes you think about architectures instead of programs, and the result is to move you away from think

Provocative. The suggestion is that thinking in OO terms makes you think about architectures instead of programs, and the result is to move you away from thinking about the problem and the solution and towards thinking about the program's organization. This is always assumed to be a good thing, especially when accompanied by the usual examples of writing programs for teams of programmers with varying levels of skill. But if we grant that non-OO is better for someone learning to program, why wouldn't it be better for someone reading a program for the first time? EDIT: Thinking further about this, I am not against the idea of design considerations that should be kept from the beginning programmer. But OO isn't really a design consideration, it's a metaphor. If it really "worked," then new programmers would be looking all confused trying to write a Towers of Hanoi program, and you would explain, "Think of each tower as its own thing. What can it do? What does it have?" And slowly you could tease out a program by designing objects from the ground up. But if it actually doesn't work to teach programming using objects, if you teach programming without objects and introduce them as an 'advanced' subject, then at some level you have to wonder if the metaphor is fundamentally broken. If the purpose of OO is design and organization rather than a fundamental way to think about programs, then really we shouldn't say things like "Everything's an object." We should ask what we need to do to design well-factored programs that are cohesive without being coupled and then design language features that directly address those organization requirements rather than thinking that there is this obvious "metaphor" that naturally leads to well-organized programs.

deleted 16y ago
[deleted]
deleted 16y ago
[deleted]
knieveltech 16y ago
"We should ask what we need to do to design well-factored programs that are cohesive without being coupled and then design language features that directly address those organization requirements" Language designers have been chasing that chimera for decades now. An unfortunate (in my mind at least) side effect has been legions of new programmers that are ready to fight to the death over concepts (separation of presentation and logic being an example) that are implied to be the One True Right Way when in my experience most programming rules should not only be broken on occasion but frequently ignored wholesale. "rather than thinking that there is this obvious 'metaphor' that naturally leads to well-organized programs." Herein lies my greatest criticism of OO and it's proponents. There is nothing inherently "obvious" about the metaphor in general and in my opinion adding a layer metaphor on top of an already complex process simply adds further complexity without bringing anything to the table.
jerf 16y ago
In your last two paragraphs of your edit you seem to have sort of slipped in an assumption that our designs should be constrained to at least some extent by what we can teach new programmers in their first few weeks? OO can still be a helpful metaphor, while at the same time perhaps not being the very very first thing we should teach. For instance, perhaps we should not teach the solutions of OO until the student has gone far enough to encounter the problems it solves, to at least some minimal extent. (I include the question mark on purpose, I doubt this is exactly what you meant.) As a bit of a sidebar, I'd also observe that the metaphor we ostensibly want to teach our newbies, about how objects are nouns and methods are verbs and it can model the physical world and lets go talk about class hierarchies involving animals and vehicles, has fallen out of favor in the more advanced OO circles anyhow, since it is, not to put too fine a point on it, a useless way to design real programs. This would also seem to suggest that perhaps OO isn't necessarily the best thing to go out of the gate with.
- raganwald 16y ago
  What prompted this wandering, incoherent mumble was wondering if "what we can teach new programmers" is somehow related to "what is readable by unskilled programmers new to our programs." If OO gets in the way of new programmers, I was wondering if it would get in the way of the mythical maintenance programmers trying to figure out what our programs do and how to modify them. I don't really have a full conclusion, but if we grant that it is a useless metaphor, and just a tool for organizing programs, I wonder if it ought to be relegated to a corner of most languages rather than being put front and center.
  - chromatic 16y ago
    I was wondering if it would get in the way of the mythical maintenance programmers trying to figure out what our programs do and how to modify them. This seems to me to be the point at which your idea goes strange. Why assume that maintenance programmers are interchangeable monkey-cogs with minimal understanding of software development and design? Perhaps we'd have better software if we treated maintenance and ongoing development as tasks requiring just as much, if not more, talent and knowledge and skill and practice as green field development. (I understand that soi disant architects might disagree, but I ignore architects who don't code.)
jacobolus 16y ago
Many of the language and library developments of the last several years of Python have been in making the language better at expressing concepts and control flow in terms of functions which pass around simple data types, which tends to make code less object-y. For example: context managers and decorators make it easier to change code behavior in a region of code or a function body; generators make it easier to iterate through collections of things in a declarative way, storing state without explicitly adding it to an object; named tuple objects help in creating simple data types without resorting to heavily customized objects. Personally, I find in Python that objects are a good and fairly intuitive way to describe data structures or anything needing many similar copies with complex stored state but where each copy is performing some particular action: e.g. representing the users logged into a chat server.
- bad_user 16y ago
  If only they added anonymous code blocks.
ynniv 16y ago
If the purpose of OO is design and organization rather than a fundamental way to think about programs, then really we shouldn't say things like "Everything's an object." If you are an ardent fan of OO, you might enjoy spending some time with modern functional programming in clojure. OO has become the common means by which we achieve encapsulation and polymorphism, but these features can be accomplished by other means which have a different (and to some, better) feel. When we say "Everything is an object", the core sentiment is that "Variables behave similarly". It's jarring to use object.toString() sometimes and "" + 1 others. To (approximately) fix this in an "code belongs to objects" universe, you must make everything an object (and have lots of inherited interfaces). In a functional universe you can achieve a more satisfying fix by having multiple implementations of the same method. (str object) and (str 1) behave similarly without imposing interface requirements on the different types. To have large scale projects, this requires that the str function be implemented in different places and dispatch correctly, which is a sophisticated language feature that isn't available in all functional languages. I have long been a fan of python and The Good Parts of JavaScript. They have their problems, but they have served me well thus far. But OO is actually fundamentally flawed, and you only need to look as far as the Java library situation to see how exponentially complex strongly typed and independently developed OO can get. Duck typed OO has tried to answer the call, but this still results in duplicate, inconsistent interfaces monkey patched at runtime to achieve a measure of sanity. Clojure is really changing my opinion - you get great performance (compared to the majority of languages), optional static typing, and significantly less crufty code. Whether it will age well is of course unknown, but so far it beats the pants off of any other language I have used (including scheme and Common Lisp).
- brehaut 16y ago
  I believe you are wrong about optional static typing; type hints in clojure are purely an optimization and for clarifying dispatch: user=> (defn foo [^Integer i] (prn (type i))) #'user/foo user=> (foo 1) java.lang.Integer nil user=> (foo [1]) clojure.lang.PersistentVector see also: http://clojure.org/java_interop#Java%20Interop-Type%20Hints http://clojure.org/java_interop#Java%20Interop-Type%20Hints
  - 16y ago
ahlatimer 16y ago
I don't know that OO's main goal is to be readable, but rather to manage complexity (which should help readability, but I don't think that's the focus). There's an inherent level of complexity in OO that isn't necessary when you're solving basic, learner type problems, but it can help keep complexity down when you're solving problems that have solutions that can't be kept in your head at any one time. To put it differently, think of an algorithm that's constant time, but has a very large constant and an algorithm that's O(n). The constant time algorithm will be worse for small sets, but better for large sets (once n > that constant). That's the problem with teaching OO to people new to programming. You're adding an additional thing to an already difficult topic, and that thing you're adding doesn't really benefit you at that level of problem, but get to a bigger problem, and it starts to make sense.
- simpleTruth 16y ago
  I agree, but it's good to step back and think why that's true. The real value in OO programming is being able to reduce complexity by reusing code in a new ways. Either by creating several instances of the same object that all manage a complex internal state, or by inheriting from another object and extending functionality. I need to add a window, I already have lot's of windows, but this one is different because X works in OO. I need to build my first window starting from scratch and suddenly OO does not give you any leverage. Which is why OO seems pointless for most being programmers, they can't deal with sufficiently complex problems to gain anything from OO programming. However, you don't need to understand object's to use them. It takes a while to understand why you can keep adding <<'s after cout, but most beginners quickly prefer it over sprintf.
  - raganwald 16y ago
    Which is why OO seems pointless for most being programmers, they can't deal with sufficiently complex problems to gain anything from OO programming. Beware, this is not biconditional. I'm sure you won't have to go very far to find programmers who deal with complex problems but who do not feel that they gain anything from solving them using OO. And there is also the argument that OO as implemented in popular languages introduces its own complexity, such that it ends up being used to solve the problems it introduced in the first place.
edanm 16y ago
"Thinking further about this, I am not against the idea of design considerations that should be kept from the beginning programmer. But OO isn't really a design consideration, it's a metaphor." I would think of OO as just another tool that we've created over the years to help make programs. It's a big tool, with a lot of history to it, and that people used to think was the ultimate all-in-one tool that you needed to use for everything (nowadays less people think that). But it any case, when you teach someone something new, you can't give them too many tools at once. So while I agree with a lot of the sentiments you expressed, I don't think that what you do or don't teach new programmers has that much bearing on what you should or shouldn't use. After all, in your first lesson you probably won't be using loops either.
bad_user 16y ago
OOP is not a metaphor. OOP is about (subtype) polymorphism, or more precisely about functions with polymorphic behavior in regards to the (implicit) parameter. Everything else is there to support and make it easier to apply this concept. Of course you don't need OOP for every problem, because you don't need polymorphism for every problem. And applied improperly, every type of polymorphism (whether it's ad-hoc with early or late binding, or parametric) is broken, not to mention hard to explain. And as an exercise, I want you to count the number of applications where you haven't used any type of polymorphism. The only ones I can count myself are the small exercises of the types I used to do in high-school. See what I did there?
- raganwald 16y ago
  OOP is about (subtype) polymorphism What are we to make of this quote: "OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things."--Alan Kay Do we interpret that as suggesting that polymorphism is the thing and that Alan is using different words to describe it? That polymorphism is an implementation technique for achieving the goals Alan is describing? or perhaps that in the thirty years since Smalltalk has been commercialized, we have moved on from its initial vision?
  - bad_user 16y ago
    "messaging" / "extreme late-binding of all things" - this is about polymorphism. "local retention and protection" - encapsulation is THE goal of every engineer (i.e. black boxes that take some input and reliably give you some output, without you worrying about the details) and is in no way an exclusive property of OOP, although thinking about data-structures as objects that respond to messages gives you powerful tools to do that. EDIT - and thinking about beginners that can't understand OOP, encapsulation is also hard to explain, but that doesn't make it any less of a useful goal.
    - DanielRibeiro 16y ago
      "Messaging" also means loose coupled. It enables things like Structural interfaces (you implement what you implement) like in Go, instead of declarative interfaces (you implement what you say you implement) like in Java/C++/C#. "Messaging" and its loose coupling also means the ability of doing Method Lookup Alteration and Interception [1], such as those provided by Smalltalk’s doesNotUnderstand, Ruby’s missing_method and Python’s __gettattr__ method. This is crucial because it allows you to compose objects, as they are strippable down to the Common Lisp Object System system: an object is a function that takes a message specification (method name and args) and decides what to do with it. Yeah. Messaging is really important and powerful. It also explains why Alan Kay also said: I coined the term object-oriented, and C++ wasn't what I had in mind. [1]http://www.google.com/url?sa=t&source=web&cd=2&ved=0CBsQFjAB&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.91.1021%26rep%3Drep1%26type%3Dpdf&rct=j&q=method+lookup+alteration+and+interception&ei=ZSEsTMTYC4KJuAfw2p3CCQ&usg=AFQjCNH7dktUqD_4vSjR5aHidE9U4Y3sIg&sig2=bHOpRznFWe0WqxTJxx9D9w http://www.google.com/url?sa=t&source=web&cd=2&v...
DanielBMarkham 16y ago
I found your comment much more provocative than the article itself :) Object-Orientation exists in several different places, each of which is more or less important. As a code organization tool, it really shines in large projects. So if you're learning to code, probably don't need it. Code organization gets much more rigorous in larger projects. Many times noobs with small programs start applying large-project concepts to their ten-line algorithm. This is a failure of teaching -- but probably intermediate-level teaching. As a metaphor, it provides a way of looking at "where" to put your code. Noobs don't have a lot of code, so it doesn't matter. I agree that for small problems this extra layer can be distracting. But the most important part of OO has nothing to do with programming: it's OOA. This skill lets you look at your problem, and it's the most powerful thing I've experienced for solving large problems. Functional Programming puts all the symbols and problem-space in your head at one time -- you become the linker. OOA lets you play with ways to solve a problem without writing any code and without taxing your noodle at all. You deal with small, atomic blocks and their relationships with each other. This skill is an absolute necessity, even if the student never touches an object the rest of their career. It's also one that's the most lacking in regular programmers.
- fogus 16y ago
  Functional Programming puts all the symbols and problem-space in your head at one time I feel like the natural response is "then you're doing it wrong", but I think that's too dismissive. My comments do not apply universally across so-called functional languages, but I think it holds as a point of note. That is, when thinking about a system functionally one tends to conceptualize the data in the system and how it gets from looking like one thing to looking like another. How it gets from point A to point B are matters of detail. So while I understand what you mean, I'm not sure that it's emblematic of how functional thinking is actually done. Functional thinking is less about functions than data.
  - DanielBMarkham 16y ago
    Yes. I think we're saying the same thing. By "link" I specifically meant data, not functions. Because everything is potentially visible, FP requires you to keep track of data structures in your head -- sometimes complex data structures with non-trivial relationships to other data structures. Of course, there are methods to keep it simple -- starting small and growing as needed comes to mind first -- but if you're writing FP in a legacy environment with lots of nasty complex data structures you have a big headache. This would not be true in the same data environment with a well-constructed OO tier. [insert discussion here about what makes a well-constructed OO tier] Or maybe I missed it. If I did, please straighten me out.
fogus 16y ago
OOP describes the real-world in the same way that the metaphor Raganwald is a diamond in the rough describes your ability to act as a piece of jewelry.
Goladus 16y ago
A lot of the important concepts we'd consider "object-oriented" are implicit and will likely be picked up intuitively. If you're writing python functions that return ADTs like dictionaries, sets, and lists, you're already using OO programming. Your function is a constructor, and you get back a collection of data with a set of methods that can operate on that data. I wouldn't say that "non-OO is better" for a beginner, just that there isn't much advantage to a peculiar focus on object-orientation, especially as a program design philosophy.

deleted 16y ago

[deleted]

deleted 16y ago

[deleted]

knieveltech 16y ago

"We should ask what we need to do to design well-factored programs that are cohesive without being coupled and then design language features that directly address those organization requirements" Language designers have been chasing that chimera for decades now. An unfortunate (in my mind at least) side effect has been legions of new programmers that are ready to fight to the death over concepts (separation of presentation and logic being an example) that are implied to be the One True Right Way when in my experience most programming rules should not only be broken on occasion but frequently ignored wholesale. "rather than thinking that there is this obvious 'metaphor' that naturally leads to well-organized programs." Herein lies my greatest criticism of OO and it's proponents. There is nothing inherently "obvious" about the metaphor in general and in my opinion adding a layer metaphor on top of an already complex process simply adds further complexity without bringing anything to the table.

jerf 16y ago

In your last two paragraphs of your edit you seem to have sort of slipped in an assumption that our designs should be constrained to at least some extent by what we can teach new programmers in their first few weeks? OO can still be a helpful metaphor, while at the same time perhaps not being the very very first thing we should teach. For instance, perhaps we should not teach the solutions of OO until the student has gone far enough to encounter the problems it solves, to at least some minimal extent. (I include the question mark on purpose, I doubt this is exactly what you meant.) As a bit of a sidebar, I'd also observe that the metaphor we ostensibly want to teach our newbies, about how objects are nouns and methods are verbs and it can model the physical world and lets go talk about class hierarchies involving animals and vehicles, has fallen out of favor in the more advanced OO circles anyhow, since it is, not to put too fine a point on it, a useless way to design real programs. This would also seem to suggest that perhaps OO isn't necessarily the best thing to go out of the gate with.

raganwald 16y ago
What prompted this wandering, incoherent mumble was wondering if "what we can teach new programmers" is somehow related to "what is readable by unskilled programmers new to our programs." If OO gets in the way of new programmers, I was wondering if it would get in the way of the mythical maintenance programmers trying to figure out what our programs do and how to modify them. I don't really have a full conclusion, but if we grant that it is a useless metaphor, and just a tool for organizing programs, I wonder if it ought to be relegated to a corner of most languages rather than being put front and center.
- chromatic 16y ago
  I was wondering if it would get in the way of the mythical maintenance programmers trying to figure out what our programs do and how to modify them. This seems to me to be the point at which your idea goes strange. Why assume that maintenance programmers are interchangeable monkey-cogs with minimal understanding of software development and design? Perhaps we'd have better software if we treated maintenance and ongoing development as tasks requiring just as much, if not more, talent and knowledge and skill and practice as green field development. (I understand that soi disant architects might disagree, but I ignore architects who don't code.)

jacobolus 16y ago

Many of the language and library developments of the last several years of Python have been in making the language better at expressing concepts and control flow in terms of functions which pass around simple data types, which tends to make code less object-y. For example: context managers and decorators make it easier to change code behavior in a region of code or a function body; generators make it easier to iterate through collections of things in a declarative way, storing state without explicitly adding it to an object; named tuple objects help in creating simple data types without resorting to heavily customized objects. Personally, I find in Python that objects are a good and fairly intuitive way to describe data structures or anything needing many similar copies with complex stored state but where each copy is performing some particular action: e.g. representing the users logged into a chat server.

bad_user 16y ago
If only they added anonymous code blocks.

ynniv 16y ago

If the purpose of OO is design and organization rather than a fundamental way to think about programs, then really we shouldn't say things like "Everything's an object." If you are an ardent fan of OO, you might enjoy spending some time with modern functional programming in clojure. OO has become the common means by which we achieve encapsulation and polymorphism, but these features can be accomplished by other means which have a different (and to some, better) feel. When we say "Everything is an object", the core sentiment is that "Variables behave similarly". It's jarring to use object.toString() sometimes and "" + 1 others. To (approximately) fix this in an "code belongs to objects" universe, you must make everything an object (and have lots of inherited interfaces). In a functional universe you can achieve a more satisfying fix by having multiple implementations of the same method. (str object) and (str 1) behave similarly without imposing interface requirements on the different types. To have large scale projects, this requires that the str function be implemented in different places and dispatch correctly, which is a sophisticated language feature that isn't available in all functional languages. I have long been a fan of python and The Good Parts of JavaScript. They have their problems, but they have served me well thus far. But OO is actually fundamentally flawed, and you only need to look as far as the Java library situation to see how exponentially complex strongly typed and independently developed OO can get. Duck typed OO has tried to answer the call, but this still results in duplicate, inconsistent interfaces monkey patched at runtime to achieve a measure of sanity. Clojure is really changing my opinion - you get great performance (compared to the majority of languages), optional static typing, and significantly less crufty code. Whether it will age well is of course unknown, but so far it beats the pants off of any other language I have used (including scheme and Common Lisp).

brehaut 16y ago
I believe you are wrong about optional static typing; type hints in clojure are purely an optimization and for clarifying dispatch: user=> (defn foo [^Integer i] (prn (type i))) #'user/foo user=> (foo 1) java.lang.Integer nil user=> (foo [1]) clojure.lang.PersistentVector see also: http://clojure.org/java_interop#Java%20Interop-Type%20Hints http://clojure.org/java_interop#Java%20Interop-Type%20Hints
- 16y ago

ahlatimer 16y ago

I don't know that OO's main goal is to be readable, but rather to manage complexity (which should help readability, but I don't think that's the focus). There's an inherent level of complexity in OO that isn't necessary when you're solving basic, learner type problems, but it can help keep complexity down when you're solving problems that have solutions that can't be kept in your head at any one time. To put it differently, think of an algorithm that's constant time, but has a very large constant and an algorithm that's O(n). The constant time algorithm will be worse for small sets, but better for large sets (once n > that constant). That's the problem with teaching OO to people new to programming. You're adding an additional thing to an already difficult topic, and that thing you're adding doesn't really benefit you at that level of problem, but get to a bigger problem, and it starts to make sense.

simpleTruth 16y ago
I agree, but it's good to step back and think why that's true. The real value in OO programming is being able to reduce complexity by reusing code in a new ways. Either by creating several instances of the same object that all manage a complex internal state, or by inheriting from another object and extending functionality. I need to add a window, I already have lot's of windows, but this one is different because X works in OO. I need to build my first window starting from scratch and suddenly OO does not give you any leverage. Which is why OO seems pointless for most being programmers, they can't deal with sufficiently complex problems to gain anything from OO programming. However, you don't need to understand object's to use them. It takes a while to understand why you can keep adding <<'s after cout, but most beginners quickly prefer it over sprintf.
- raganwald 16y ago
  Which is why OO seems pointless for most being programmers, they can't deal with sufficiently complex problems to gain anything from OO programming. Beware, this is not biconditional. I'm sure you won't have to go very far to find programmers who deal with complex problems but who do not feel that they gain anything from solving them using OO. And there is also the argument that OO as implemented in popular languages introduces its own complexity, such that it ends up being used to solve the problems it introduced in the first place.

edanm 16y ago

"Thinking further about this, I am not against the idea of design considerations that should be kept from the beginning programmer. But OO isn't really a design consideration, it's a metaphor." I would think of OO as just another tool that we've created over the years to help make programs. It's a big tool, with a lot of history to it, and that people used to think was the ultimate all-in-one tool that you needed to use for everything (nowadays less people think that). But it any case, when you teach someone something new, you can't give them too many tools at once. So while I agree with a lot of the sentiments you expressed, I don't think that what you do or don't teach new programmers has that much bearing on what you should or shouldn't use. After all, in your first lesson you probably won't be using loops either.

bad_user 16y ago

OOP is not a metaphor. OOP is about (subtype) polymorphism, or more precisely about functions with polymorphic behavior in regards to the (implicit) parameter. Everything else is there to support and make it easier to apply this concept. Of course you don't need OOP for every problem, because you don't need polymorphism for every problem. And applied improperly, every type of polymorphism (whether it's ad-hoc with early or late binding, or parametric) is broken, not to mention hard to explain. And as an exercise, I want you to count the number of applications where you haven't used any type of polymorphism. The only ones I can count myself are the small exercises of the types I used to do in high-school. See what I did there?

raganwald 16y ago
OOP is about (subtype) polymorphism What are we to make of this quote: "OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things."--Alan Kay Do we interpret that as suggesting that polymorphism is the thing and that Alan is using different words to describe it? That polymorphism is an implementation technique for achieving the goals Alan is describing? or perhaps that in the thirty years since Smalltalk has been commercialized, we have moved on from its initial vision?
- bad_user 16y ago
  "messaging" / "extreme late-binding of all things" - this is about polymorphism. "local retention and protection" - encapsulation is THE goal of every engineer (i.e. black boxes that take some input and reliably give you some output, without you worrying about the details) and is in no way an exclusive property of OOP, although thinking about data-structures as objects that respond to messages gives you powerful tools to do that. EDIT - and thinking about beginners that can't understand OOP, encapsulation is also hard to explain, but that doesn't make it any less of a useful goal.
  - DanielRibeiro 16y ago
    "Messaging" also means loose coupled. It enables things like Structural interfaces (you implement what you implement) like in Go, instead of declarative interfaces (you implement what you say you implement) like in Java/C++/C#. "Messaging" and its loose coupling also means the ability of doing Method Lookup Alteration and Interception [1], such as those provided by Smalltalk’s doesNotUnderstand, Ruby’s missing_method and Python’s __gettattr__ method. This is crucial because it allows you to compose objects, as they are strippable down to the Common Lisp Object System system: an object is a function that takes a message specification (method name and args) and decides what to do with it. Yeah. Messaging is really important and powerful. It also explains why Alan Kay also said: I coined the term object-oriented, and C++ wasn't what I had in mind. [1]http://www.google.com/url?sa=t&source=web&cd=2&ved=0CBsQFjAB&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.91.1021%26rep%3Drep1%26type%3Dpdf&rct=j&q=method+lookup+alteration+and+interception&ei=ZSEsTMTYC4KJuAfw2p3CCQ&usg=AFQjCNH7dktUqD_4vSjR5aHidE9U4Y3sIg&sig2=bHOpRznFWe0WqxTJxx9D9w http://www.google.com/url?sa=t&source=web&cd=2&v...

DanielBMarkham 16y ago

I found your comment much more provocative than the article itself :) Object-Orientation exists in several different places, each of which is more or less important. As a code organization tool, it really shines in large projects. So if you're learning to code, probably don't need it. Code organization gets much more rigorous in larger projects. Many times noobs with small programs start applying large-project concepts to their ten-line algorithm. This is a failure of teaching -- but probably intermediate-level teaching. As a metaphor, it provides a way of looking at "where" to put your code. Noobs don't have a lot of code, so it doesn't matter. I agree that for small problems this extra layer can be distracting. But the most important part of OO has nothing to do with programming: it's OOA. This skill lets you look at your problem, and it's the most powerful thing I've experienced for solving large problems. Functional Programming puts all the symbols and problem-space in your head at one time -- you become the linker. OOA lets you play with ways to solve a problem without writing any code and without taxing your noodle at all. You deal with small, atomic blocks and their relationships with each other. This skill is an absolute necessity, even if the student never touches an object the rest of their career. It's also one that's the most lacking in regular programmers.

fogus 16y ago
Functional Programming puts all the symbols and problem-space in your head at one time I feel like the natural response is "then you're doing it wrong", but I think that's too dismissive. My comments do not apply universally across so-called functional languages, but I think it holds as a point of note. That is, when thinking about a system functionally one tends to conceptualize the data in the system and how it gets from looking like one thing to looking like another. How it gets from point A to point B are matters of detail. So while I understand what you mean, I'm not sure that it's emblematic of how functional thinking is actually done. Functional thinking is less about functions than data.
- DanielBMarkham 16y ago
  Yes. I think we're saying the same thing. By "link" I specifically meant data, not functions. Because everything is potentially visible, FP requires you to keep track of data structures in your head -- sometimes complex data structures with non-trivial relationships to other data structures. Of course, there are methods to keep it simple -- starting small and growing as needed comes to mind first -- but if you're writing FP in a legacy environment with lots of nasty complex data structures you have a big headache. This would not be true in the same data environment with a well-constructed OO tier. [insert discussion here about what makes a well-constructed OO tier] Or maybe I missed it. If I did, please straighten me out.

fogus 16y ago

OOP describes the real-world in the same way that the metaphor Raganwald is a diamond in the rough describes your ability to act as a piece of jewelry.

Goladus 16y ago

A lot of the important concepts we'd consider "object-oriented" are implicit and will likely be picked up intuitively. If you're writing python functions that return ADTs like dictionaries, sets, and lists, you're already using OO programming. Your function is a constructor, and you get back a collection of data with a set of methods that can operate on that data. I wouldn't say that "non-OO is better" for a beginner, just that there isn't much advantage to a peculiar focus on object-orientation, especially as a program design philosophy.