3 ms·

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!"

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!"