5 ms·

My biggest reason is that I have to weigh learning an entirely new paradigm versus bettering myself in a paradigm I already know that's currently making me mone

by ceol 14y ago

My biggest reason is that I have to weigh learning an entirely new paradigm versus bettering myself in a paradigm I already know that's currently making me money. In short, I need it to be worth it.

bunderbunder 14y ago
Getting a good handle on FP has been one of the best things I've done to better myself in the paradigm I get paid to write code in by day. I haven't personally found a whole lot to warrant the "functional programming as universal panacea" meme that's been so popular lately. But most decent imperative languages have pretty good support for many features of functional programming nowadays, and spending some time working in a functional language will teach you to make better use of those features of your native one. To that extent, polishing my FP skills has led me to like my by-day language (C#) even better. Even failing that, learning new ways to think about and code solutions for problems can only improve your ability to think about and code solutions for problems.
- ceol 14y ago
  Thanks for your reply! That certainly gives me a bit of motivation to learn a functional language.
- dmlorenzetti 14y ago
  This has been my experience. I've learned a bit about FP (mainly by reading books on several FP languages, and attending the SF Bay Area Functional Programmers group back when it was still meeting). However, I have never seen a reasonable way to use a true FP language in my work. Most of what I do is inherently stateful-- at the core are iterative algorithms that update vectors of state variables with small corrections until a problem converges. This is a really hard use case for a pure FP language (i.e., one that "takes away assignment") to shine. That said, learning FP has influenced the way I write the code that pumps numbers into the core update algorithms. Think using PURE and ELEMENTAL functions in Fortran, for example. And of course scientific programming has a rich history of passing functions in to general numerical algorithms. I just don't use closures, or create functions on the fly, or any of that other FP goodness.
- alinajaf 14y ago
  > "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!"
exDM69 14y ago
You've probably heard it before but I'll say it again: learning functional programming will make you a better programmer, regardless of what you use in your day job. If you measure only dollars in your bank account and time spent, it probably will not be worth it. If you add in the enjoyment and enlightenment it brings, and the new career options it might indirectly provide you with, it will be worth it. At least to me, learning Haskell and Lisp has been one of the best things I've invested time in. I write my day job code almost exclusively in C. But for some in-house tools we have used Haskell and gotten better results faster than any other tool I can think of could provide. Certain problems are a very good fit for the functional paradigm. In contrast, many problems are not a good fit for the imperative paradigm but we use it anyway, because our computers work "imperatively".
- ceol 14y ago
  A few people have told me learning functional programming will make me a better programmer, so that makes me more confident when I take the plunge. Thanks!
jerf 14y ago
You probably think you know how to write code in which you Don't Repeat Yourself. Haskell will show you you are quite wrong and there are any number of repeating patterns that you currently don't even see, and how you can factor them out too. It will also give you a fantastic workout in learning how to separate logic from code that does stuff. This definitely can have a very positive impact on the rest of your code. Even if you only treat it as a workout like lifting weights, it can still be worth it. The downside is, to really see this you need to try to do a couple of real projects in Haskell. Maps & folds & monads are the words of the language, not fluency. I think a great deal of the "this is useless!" has come from people taking the first mile of the thousand mile journey and wondering why nothing's different yet, and why did I bother taking this mile anyhow?
dinkumthinkum 14y ago
Well, not understanding functional programming is missing a big part of CS. I would think, in all likelihood, if you understood FP you would probably be worth more financially ... unless you are already at maximal worth.

by ceol 14y ago

My biggest reason is that I have to weigh learning an entirely new paradigm versus bettering myself in a paradigm I already know that's currently making me money. In short, I need it to be worth it.

bunderbunder 14y ago

Getting a good handle on FP has been one of the best things I've done to better myself in the paradigm I get paid to write code in by day. I haven't personally found a whole lot to warrant the "functional programming as universal panacea" meme that's been so popular lately. But most decent imperative languages have pretty good support for many features of functional programming nowadays, and spending some time working in a functional language will teach you to make better use of those features of your native one. To that extent, polishing my FP skills has led me to like my by-day language (C#) even better. Even failing that, learning new ways to think about and code solutions for problems can only improve your ability to think about and code solutions for problems.

ceol 14y ago
Thanks for your reply! That certainly gives me a bit of motivation to learn a functional language.
dmlorenzetti 14y ago
This has been my experience. I've learned a bit about FP (mainly by reading books on several FP languages, and attending the SF Bay Area Functional Programmers group back when it was still meeting). However, I have never seen a reasonable way to use a true FP language in my work. Most of what I do is inherently stateful-- at the core are iterative algorithms that update vectors of state variables with small corrections until a problem converges. This is a really hard use case for a pure FP language (i.e., one that "takes away assignment") to shine. That said, learning FP has influenced the way I write the code that pumps numbers into the core update algorithms. Think using PURE and ELEMENTAL functions in Fortran, for example. And of course scientific programming has a rich history of passing functions in to general numerical algorithms. I just don't use closures, or create functions on the fly, or any of that other FP goodness.
alinajaf 14y ago
> "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!"

exDM69 14y ago

You've probably heard it before but I'll say it again: learning functional programming will make you a better programmer, regardless of what you use in your day job. If you measure only dollars in your bank account and time spent, it probably will not be worth it. If you add in the enjoyment and enlightenment it brings, and the new career options it might indirectly provide you with, it will be worth it. At least to me, learning Haskell and Lisp has been one of the best things I've invested time in. I write my day job code almost exclusively in C. But for some in-house tools we have used Haskell and gotten better results faster than any other tool I can think of could provide. Certain problems are a very good fit for the functional paradigm. In contrast, many problems are not a good fit for the imperative paradigm but we use it anyway, because our computers work "imperatively".

ceol 14y ago
A few people have told me learning functional programming will make me a better programmer, so that makes me more confident when I take the plunge. Thanks!

jerf 14y ago

You probably think you know how to write code in which you Don't Repeat Yourself. Haskell will show you you are quite wrong and there are any number of repeating patterns that you currently don't even see, and how you can factor them out too. It will also give you a fantastic workout in learning how to separate logic from code that does stuff. This definitely can have a very positive impact on the rest of your code. Even if you only treat it as a workout like lifting weights, it can still be worth it. The downside is, to really see this you need to try to do a couple of real projects in Haskell. Maps & folds & monads are the words of the language, not fluency. I think a great deal of the "this is useless!" has come from people taking the first mile of the thousand mile journey and wondering why nothing's different yet, and why did I bother taking this mile anyhow?

dinkumthinkum 14y ago

Well, not understanding functional programming is missing a big part of CS. I would think, in all likelihood, if you understood FP you would probably be worth more financially ... unless you are already at maximal worth.