4 ms·

> "functional programming as universal panacea" To me at least, the endgame for any complex system that you end up with a large number of modular decoupled com

> "functional programming as universal panacea" To me at least, the endgame for any complex system that you end up with a large number of modular decoupled components. This endgame looks more or less the same today in both functional and object oriented paradigms. The difference is how you get there. In functional programming, you start with modular, decoupled components. With OOP, you make a mess and you 'refactor' into somewhat modular, somewhat decoupled components later.

bunderbunder 14y ago
In OOP I start with modular, decoupled components. And to answer the other popular complaint about OOP, the vast majority of my classes are not stateful. Just like for the preferred practice in functional programming, I try to only introduce state when practicality demands it. Making a mess and then (maybe) refactoring later is a regrettably common practice among may object-oriented programmers. But it's not a fundamental or necessary approach. It's just a bad habit that refuses to die. Might die faster if people who've been taught better practice within the functional programming sphere would quit trying to suggest that everything outside the (supposed) ivory tower is irretrievably corrupt and barren. And while we're at it, 'functional' and 'object-oriented' are orthogonal characteristics. There are a whole lot of object-oriented functional languages out there.
- alinajaf 14y ago
  Agree on all points, how I wish there more OO programmers like this in the world.
  - bunderbunder 14y ago
    Haha, me too. And if there were less effort going into suggesting that functional programming is somehow antagonistic to the rest of the programming industry, or that there's this insurmountable valley between functional or procedural programming, I think that could happen. Originally several of the courses at my alma mater were being taught in Scheme. (I'd personally have picked ML, but that's a different argument.) Several years back they dropped it, leaving Java as the department's one official language. The rationale was that Java's the marketable language, and that Scheme didn't have anything to offer in that department. Now the first is self-evidently true. The second is patently false. . . but it's a falsehood that I think is perpetuated most vigorously (if unwittingly) by functional programming advocates. Because they perpetuate the myth that everything one might learn from working in a functional language is the exclusive territory of functional programming. Speaking as someone who used to be in the habit of chalkboarding procedures in LISP-like pseudocode before implementing them in C, I can say that isn't even true when the imperative language has virtually no language-level support for functional constructs. And I think taking Scheme out of the intro classes in particular also harmed the students' object-oriented programming skills. Because it meant they had to be introduced to objects almost immediately. Object-oriented programming isn't really a fundamental programming technique; it's a more advanced, architectural software engineering technique. Introducing it to students before they've even got the basics down leaves too much opportunity for them to be confused about what object-oriented features are actually for, and how they should be used. Better to learn how to write organized code first before learning new and exciting ways to disorganize it with contrived inheritance hierarchies and the same routines copy-pasted into a gajillion different classes and suchlike. So we've got an entire generation of programmers being taught in a cocked-up way. And I think if something like SML were to get traction as a good introductory language then FP could help fix that. Procedural programming certainly can't because the only good non-OO procedural language nowadays is C, and pointers and manual memory management are also complications that are best saved for later. (And it - not C++, too high-level - does need to come later. Don't get me started on kids these days not understanding how memory management really works.) But FP isn't well-positioned to step in, because a bunch of people who don't really know or appreciate what's good in FP think that knowing about FP isn't useful if you can't find a day job working in Haskell, and rather trying to disabuse them of that notion the FP community's party-line response is to say, "Yes that's right!"
- spacemanaki 14y ago
  > And to answer the other popular complaint about OOP, the vast majority of my classes are not stateful. Do you mean that they don't have any mutable state? What's a stateless class in an OOP language except a bunch of namespaced functions?
  - bunderbunder 14y ago
    Sorry, I should have said 'immutable' instead.

bunderbunder 14y ago

In OOP I start with modular, decoupled components. And to answer the other popular complaint about OOP, the vast majority of my classes are not stateful. Just like for the preferred practice in functional programming, I try to only introduce state when practicality demands it. Making a mess and then (maybe) refactoring later is a regrettably common practice among may object-oriented programmers. But it's not a fundamental or necessary approach. It's just a bad habit that refuses to die. Might die faster if people who've been taught better practice within the functional programming sphere would quit trying to suggest that everything outside the (supposed) ivory tower is irretrievably corrupt and barren. And while we're at it, 'functional' and 'object-oriented' are orthogonal characteristics. There are a whole lot of object-oriented functional languages out there.

alinajaf 14y ago
Agree on all points, how I wish there more OO programmers like this in the world.
- bunderbunder 14y ago
  Haha, me too. And if there were less effort going into suggesting that functional programming is somehow antagonistic to the rest of the programming industry, or that there's this insurmountable valley between functional or procedural programming, I think that could happen. Originally several of the courses at my alma mater were being taught in Scheme. (I'd personally have picked ML, but that's a different argument.) Several years back they dropped it, leaving Java as the department's one official language. The rationale was that Java's the marketable language, and that Scheme didn't have anything to offer in that department. Now the first is self-evidently true. The second is patently false. . . but it's a falsehood that I think is perpetuated most vigorously (if unwittingly) by functional programming advocates. Because they perpetuate the myth that everything one might learn from working in a functional language is the exclusive territory of functional programming. Speaking as someone who used to be in the habit of chalkboarding procedures in LISP-like pseudocode before implementing them in C, I can say that isn't even true when the imperative language has virtually no language-level support for functional constructs. And I think taking Scheme out of the intro classes in particular also harmed the students' object-oriented programming skills. Because it meant they had to be introduced to objects almost immediately. Object-oriented programming isn't really a fundamental programming technique; it's a more advanced, architectural software engineering technique. Introducing it to students before they've even got the basics down leaves too much opportunity for them to be confused about what object-oriented features are actually for, and how they should be used. Better to learn how to write organized code first before learning new and exciting ways to disorganize it with contrived inheritance hierarchies and the same routines copy-pasted into a gajillion different classes and suchlike. So we've got an entire generation of programmers being taught in a cocked-up way. And I think if something like SML were to get traction as a good introductory language then FP could help fix that. Procedural programming certainly can't because the only good non-OO procedural language nowadays is C, and pointers and manual memory management are also complications that are best saved for later. (And it - not C++, too high-level - does need to come later. Don't get me started on kids these days not understanding how memory management really works.) But FP isn't well-positioned to step in, because a bunch of people who don't really know or appreciate what's good in FP think that knowing about FP isn't useful if you can't find a day job working in Haskell, and rather trying to disabuse them of that notion the FP community's party-line response is to say, "Yes that's right!"
spacemanaki 14y ago
> And to answer the other popular complaint about OOP, the vast majority of my classes are not stateful. Do you mean that they don't have any mutable state? What's a stateless class in an OOP language except a bunch of namespaced functions?
- bunderbunder 14y ago
  Sorry, I should have said 'immutable' instead.