4 ms·

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 impo

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
    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. With fp languages the tendency is to think in data and abstract via functions. If your functional tier is well-constructed then all is good right? [insert discussion here about what makes a well-constructed functional tier] ;-)
  - jshen 16y ago
    Your comparing "nasty" fp with "well-structured" OO, but let's ignore that for the moment. My experience is the opposite. I run into a lot of nasty legacy OO code (think java not smalltalk) and it's very hard for me to refactor it piecemeal. I've been doing a clojure project at work for the past 6 months and it's surprisingly easy to refactor side effect free code.
  - nickik 16y ago
    In modern Languages you have namespaces and namespaces let solve the problem your discribing.
  - moomba 16y ago
    Pretty much all recent functional languages deal with oo programming by using multimethods and namespaces. This takes care of the problem you're talking about in a beyer way than most oo languages.

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
  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. With fp languages the tendency is to think in data and abstract via functions. If your functional tier is well-constructed then all is good right? [insert discussion here about what makes a well-constructed functional tier] ;-)
- jshen 16y ago
  Your comparing "nasty" fp with "well-structured" OO, but let's ignore that for the moment. My experience is the opposite. I run into a lot of nasty legacy OO code (think java not smalltalk) and it's very hard for me to refactor it piecemeal. I've been doing a clojure project at work for the past 6 months and it's surprisingly easy to refactor side effect free code.
- nickik 16y ago
  In modern Languages you have namespaces and namespaces let solve the problem your discribing.
- moomba 16y ago
  Pretty much all recent functional languages deal with oo programming by using multimethods and namespaces. This takes care of the problem you're talking about in a beyer way than most oo languages.