4 ms·

>you can do FP in any language. Not in my experience or that of my colleagues, no. I'm a Haskell user and writing a book for learning Haskell. I'm friends with

>you can do FP in any language. Not in my experience or that of my colleagues, no. I'm a Haskell user and writing a book for learning Haskell. I'm friends with several Scalaz developers including the creator and people that have worked on similar libraries for other languages. I've also attempted to use FP idioms outside of Haskell. You can't take it with you. At best you'll learn to eschew a few bad habits, but that's not FP nor does it bring anywhere near the same benefits.

coldtea 12y ago
Consider than most software in actual use, changing the world and making millions is written in C/C++, those "benefits" must not be that many or that difficult to overcome... And if the price we pay for this "worse is better" is buffer overflows and the ocassional crash and/or security exploit, that's hardly unsurmountable either. Life would be boring with perfectly perfoming programs anyway...
- codygman 12y ago
  You sincerely believe that because "most software in actual use is in X" it means that language X must be effective? > Life would be boring with perfectly perfoming programs anyway... To me, it sounds like you are trying really hard to rationalize why the current state of the industry is okay. I don't blame you for this, it's horribly depressing to believe otherwise and work in our industry. However, if your first sentence is true, why do you feel the need to justify it with "But C/C++ having crashes and exploits can be exciting"?
  - coldtea 12y ago
    >You sincerely believe that because "most software in actual use is in X" it means that language X must be effective? I sincerely believe that "effective" in some platonic rhealm of ideas is BS. I only measure effective in actual effectiveness. Has it worked in the industry? Were products written with it? How evolved? How many use them? Etc... U"most software in actual use is in X" is a checkable observation, that shows fitness to the task and an evolutionary advantage to X. What was the cause of the advantage I don't care much, but I'm 100% sure it's not "just marketing" (on the contrary). And even if it was because "most programmers are idiots and can't comprehend Y which is better" that would still be an advantage of X -- as it's more suited to the available programmers pool. Just don't come to me with platonic ideals of what "should" be used instead, let your Y language win in the real world, and then we talk. >However, if your first sentence is true, why do you feel the need to justify it with "But C/C++ having crashes and exploits can be exciting"? Because what I'm trying to convey is having software with buffer exploits is better than no software (better than the vast amounts of non-written software for Y languages that we rely everyday in its X language version: from all Operating Systems to all browsers).
detaro 12y ago
What is the part of FP in Haskell you can't do in lets say C++? EDIT: or to phrase it better, what is missing or hard to do that you feel has the biggest influence (some things are possible, but just way more complicated)? I don't have enough FP experience myself to judge that.
- codygman 12y ago
  How can you guarantee referential with C++? Can you do it in a practical way? I've heard of people using templates to do this, but is a solution like that really maintainable? Can you write maintainable, sane, and performant C++ code that leverages immutable data structures, guarantees referential transparency, and eschews mutable state?
  - einhverfr 12y ago
    Now, note what I said that started this thread, that you can do FP in any language. I never said you could do it well or maintainably. For some languages (I am thinking of Java in particular, but C++ seems similar there), I can't imagine it being more than useful as an academic exercise. Certainly there are languages which don't support FP approaches well. But lack of utility is not the same as impossibility. If nothing else the exercise ("How far can you take FP in Java?") will teach you all kinds of things.
    - codygman 12y ago
      > Now, note what I said that started this thread, that you can do FP in any language. I never said you could do it well or maintainably. For some languages (I am thinking of Java in particular, but C++ seems similar there), I can't imagine it being more than useful as an academic exercise. > Certainly there are languages which don't support FP approaches well. But lack of utility is not the same as impossibility. If nothing else the exercise ("How far can you take FP in Java?") will teach you all kinds of things. My mistake then. I agree that seeing how far you can take FP in Java is a useful exercise.
twic 12y ago
Nor in mine. I worked on some codebases in Java 6/7 with a team who yearned for functional programming. They used various libraries that tried to support a functional style - Guava for the moderates, FunctionalJava for the zealots, lambdaj for those who liked to be different. None of them really worked well (for functional programming - Guava is excellent in other ways). Java just doesn't let you write the function-like classes concisely enough for it to be worth breaking code down as far as you need to to call it functional programming. Plus, no higher-kinded types, so no functors. And what's functional programming without functors and their kin?
- einhverfr 12y ago
  But here you are talking about functional style rather than functional programming on a definitional level. I do agree that Java is not well suited for FP. I think you can apply the base theory of FP to the language, but it may be little more than an academic exercise. The problem with FP and Java is that FP and object encapsulation don't really go very well hand in hand. I.e. in Java you are encouraged to think about objects and their behavior, as encapsulating state. Encapsulated state in not a goal in any FP I have done -- rather the problem is solved by making state structures immutable. But this doesn't mean you can't. It certainly won't look like Haskell though. It won't be idiomatic Java either. In fact it may be almost, though not entirely, unlike normal Java code.
- einhverfr 12y ago
  Think about what following the most basic aspects of functional programming would mean in Java: 1. No private attributes (all state is transparent and immutable). 2. All methods that transform an object return a transformed copy. So instead of: rectangle.stretch_x(2.5); you have: newRectangle = rectangle.stretched_x(2.5); Even this very small move here moves you way outside Java as typically programmed. This means further that even at this level (the most basic level of FP), your program will: 1. Be unable to work with standard libraries without mixing paradigms 2. Be unable to be used in other projects because of the same problems. Given that ABCL uses supertypes to allow round-trips between Java and Common Lisp, I am fairly sure that functors should be possible in Java, if not elegant.

coldtea 12y ago

Consider than most software in actual use, changing the world and making millions is written in C/C++, those "benefits" must not be that many or that difficult to overcome... And if the price we pay for this "worse is better" is buffer overflows and the ocassional crash and/or security exploit, that's hardly unsurmountable either. Life would be boring with perfectly perfoming programs anyway...

codygman 12y ago
You sincerely believe that because "most software in actual use is in X" it means that language X must be effective? > Life would be boring with perfectly perfoming programs anyway... To me, it sounds like you are trying really hard to rationalize why the current state of the industry is okay. I don't blame you for this, it's horribly depressing to believe otherwise and work in our industry. However, if your first sentence is true, why do you feel the need to justify it with "But C/C++ having crashes and exploits can be exciting"?
- coldtea 12y ago
  >You sincerely believe that because "most software in actual use is in X" it means that language X must be effective? I sincerely believe that "effective" in some platonic rhealm of ideas is BS. I only measure effective in actual effectiveness. Has it worked in the industry? Were products written with it? How evolved? How many use them? Etc... U"most software in actual use is in X" is a checkable observation, that shows fitness to the task and an evolutionary advantage to X. What was the cause of the advantage I don't care much, but I'm 100% sure it's not "just marketing" (on the contrary). And even if it was because "most programmers are idiots and can't comprehend Y which is better" that would still be an advantage of X -- as it's more suited to the available programmers pool. Just don't come to me with platonic ideals of what "should" be used instead, let your Y language win in the real world, and then we talk. >However, if your first sentence is true, why do you feel the need to justify it with "But C/C++ having crashes and exploits can be exciting"? Because what I'm trying to convey is having software with buffer exploits is better than no software (better than the vast amounts of non-written software for Y languages that we rely everyday in its X language version: from all Operating Systems to all browsers).

detaro 12y ago

What is the part of FP in Haskell you can't do in lets say C++? EDIT: or to phrase it better, what is missing or hard to do that you feel has the biggest influence (some things are possible, but just way more complicated)? I don't have enough FP experience myself to judge that.

codygman 12y ago
How can you guarantee referential with C++? Can you do it in a practical way? I've heard of people using templates to do this, but is a solution like that really maintainable? Can you write maintainable, sane, and performant C++ code that leverages immutable data structures, guarantees referential transparency, and eschews mutable state?
- einhverfr 12y ago
  Now, note what I said that started this thread, that you can do FP in any language. I never said you could do it well or maintainably. For some languages (I am thinking of Java in particular, but C++ seems similar there), I can't imagine it being more than useful as an academic exercise. Certainly there are languages which don't support FP approaches well. But lack of utility is not the same as impossibility. If nothing else the exercise ("How far can you take FP in Java?") will teach you all kinds of things.
  - codygman 12y ago
    > Now, note what I said that started this thread, that you can do FP in any language. I never said you could do it well or maintainably. For some languages (I am thinking of Java in particular, but C++ seems similar there), I can't imagine it being more than useful as an academic exercise. > Certainly there are languages which don't support FP approaches well. But lack of utility is not the same as impossibility. If nothing else the exercise ("How far can you take FP in Java?") will teach you all kinds of things. My mistake then. I agree that seeing how far you can take FP in Java is a useful exercise.

twic 12y ago

Nor in mine. I worked on some codebases in Java 6/7 with a team who yearned for functional programming. They used various libraries that tried to support a functional style - Guava for the moderates, FunctionalJava for the zealots, lambdaj for those who liked to be different. None of them really worked well (for functional programming - Guava is excellent in other ways). Java just doesn't let you write the function-like classes concisely enough for it to be worth breaking code down as far as you need to to call it functional programming. Plus, no higher-kinded types, so no functors. And what's functional programming without functors and their kin?

einhverfr 12y ago
But here you are talking about functional style rather than functional programming on a definitional level. I do agree that Java is not well suited for FP. I think you can apply the base theory of FP to the language, but it may be little more than an academic exercise. The problem with FP and Java is that FP and object encapsulation don't really go very well hand in hand. I.e. in Java you are encouraged to think about objects and their behavior, as encapsulating state. Encapsulated state in not a goal in any FP I have done -- rather the problem is solved by making state structures immutable. But this doesn't mean you can't. It certainly won't look like Haskell though. It won't be idiomatic Java either. In fact it may be almost, though not entirely, unlike normal Java code.
einhverfr 12y ago
Think about what following the most basic aspects of functional programming would mean in Java: 1. No private attributes (all state is transparent and immutable). 2. All methods that transform an object return a transformed copy. So instead of: rectangle.stretch_x(2.5); you have: newRectangle = rectangle.stretched_x(2.5); Even this very small move here moves you way outside Java as typically programmed. This means further that even at this level (the most basic level of FP), your program will: 1. Be unable to work with standard libraries without mixing paradigms 2. Be unable to be used in other projects because of the same problems. Given that ABCL uses supertypes to allow round-trips between Java and Common Lisp, I am fairly sure that functors should be possible in Java, if not elegant.