6 ms·

It's a good paper, but what it hints at (but doesn't really come out and say) is that in separating concerns, functional programming actually eliminates concern

It's a good paper, but what it hints at (but doesn't really come out and say) is that in separating concerns, functional programming actually eliminates concerns from the programmer. This isn't really just a question of the language -- you can do FP in any language. But by thinking about programming differently, we can eliminate concerns entirely. This is what garbage collection does, and it is what FP does.

codygman 12y ago
> you can do FP in any language Depends on your definition of functional programming.
- einhverfr 12y ago
  This is true. However.... The basic premise that you are operating with mathematical functions, which allow you to reason equationally can be done in any language. Of course when you move from C to Perl you pick up a lot of power in what you can do functionally, and when you move from Perl to Common Lisp you pick up even more, and when you move to Scala or Haskell, you pick up even more from what I have seen. But just as you can do object-oriented programming in C (a language really not designed for it), you can do functional programming in a lot of languages not really designed for it too.
  - codygman 12y ago
    > But just as you can do object-oriented programming in C (a language really not designed for it), you can do functional programming in a lot of languages not really designed for it too. This statement is only true depending on what you mean by OOP. For instance see this post[0] implementing minimal OOP with scheme. 0: http://robots.thoughtbot.com/you-could-invent-objectoriented-programming http://robots.thoughtbot.com/you-could-invent-objectoriented...
    - einhverfr 12y ago
      This is also true. OOP in Java is certainly not the same as OOP using CLOS, and not the same as Perl and Moose. But there is a common thread through these. Namely with OOP, you are tying structure and behavior together so that behavior can encapsulate structure. OOP, like FP, isn't so much "a paradigm" as a "family of paradigms," one or more per language.
coolsunglasses 12y ago
>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).
current_call 12y ago
No, you really can't do FP in any language. "Please let’s not have a discussion about Turing Equivalence. Computer Science “Theory” tells us “there’s no such thing as more powerful.” Perhaps we share the belief that In theory, there’s no difference between theory and practice. But in practice, there is." Programming paradigms are about how programs are written. If a problem can be solved in one language, it can be solved in every language, but that doesn't mean it can be solved in every paradigm in every language.
- kaeluka 12y ago
  You make a claim here but don't back it up. I think that a functional program, compiled to native code is STILL a functional program. You seem to not think that. Edit: If so, why? Edit 2: Oh, maybe your point is that FP is statically typed?
  - ajuc 12y ago
    Of course not. Functional program compiled to machine code becomes imperative program. It's now all about global variables (memory, stack and registers) and side effects. How is that functional? Well, you can think of it as functional, if you consider every machine instruction to be function (whole machine state->whole machine state), but it's not practical and nobody really thinks about machine code like that. And anyway - if you want to think about it like that - evey imperative program becomes functional :)
    - einhverfr 12y ago
      I am not entirely sure that ASM can be used directly for functional programming. Also I am not entirely sure that functional == declarative although that is a very powerful combination. As far as I am concerned functional programming centers around the guarantee that f(x) has the properties associated with a function, i.e. for every x, exactly one f(x) is correct. That's why your data structures must be immutable. That's why you need referential transparency, etc. But how you calculate f(x) really doesn't determine whether this is FP or not. There's certainly a lot of power that can come from a language that can compose or decompose functions for you. But I wouldn't use that as a litmus test for FP. But I suspect (not entirely sure, but suspect) that if you apply sufficient discipline, and omit from the equation the global necessities of registers, you can probably create functions in assembly, and call them in a functional way. In fact I suspect if this were not possible, then FP languages would not be possible to create. But FP in ASM sounds really really painful.

codygman 12y ago

> you can do FP in any language Depends on your definition of functional programming.

einhverfr 12y ago
This is true. However.... The basic premise that you are operating with mathematical functions, which allow you to reason equationally can be done in any language. Of course when you move from C to Perl you pick up a lot of power in what you can do functionally, and when you move from Perl to Common Lisp you pick up even more, and when you move to Scala or Haskell, you pick up even more from what I have seen. But just as you can do object-oriented programming in C (a language really not designed for it), you can do functional programming in a lot of languages not really designed for it too.
- codygman 12y ago
  > But just as you can do object-oriented programming in C (a language really not designed for it), you can do functional programming in a lot of languages not really designed for it too. This statement is only true depending on what you mean by OOP. For instance see this post[0] implementing minimal OOP with scheme. 0: http://robots.thoughtbot.com/you-could-invent-objectoriented-programming http://robots.thoughtbot.com/you-could-invent-objectoriented...
  - einhverfr 12y ago
    This is also true. OOP in Java is certainly not the same as OOP using CLOS, and not the same as Perl and Moose. But there is a common thread through these. Namely with OOP, you are tying structure and behavior together so that behavior can encapsulate structure. OOP, like FP, isn't so much "a paradigm" as a "family of paradigms," one or more per language.

coolsunglasses 12y ago

>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).

current_call 12y ago

No, you really can't do FP in any language. "Please let’s not have a discussion about Turing Equivalence. Computer Science “Theory” tells us “there’s no such thing as more powerful.” Perhaps we share the belief that In theory, there’s no difference between theory and practice. But in practice, there is." Programming paradigms are about how programs are written. If a problem can be solved in one language, it can be solved in every language, but that doesn't mean it can be solved in every paradigm in every language.

kaeluka 12y ago
You make a claim here but don't back it up. I think that a functional program, compiled to native code is STILL a functional program. You seem to not think that. Edit: If so, why? Edit 2: Oh, maybe your point is that FP is statically typed?
- ajuc 12y ago
  Of course not. Functional program compiled to machine code becomes imperative program. It's now all about global variables (memory, stack and registers) and side effects. How is that functional? Well, you can think of it as functional, if you consider every machine instruction to be function (whole machine state->whole machine state), but it's not practical and nobody really thinks about machine code like that. And anyway - if you want to think about it like that - evey imperative program becomes functional :)
  - einhverfr 12y ago
    I am not entirely sure that ASM can be used directly for functional programming. Also I am not entirely sure that functional == declarative although that is a very powerful combination. As far as I am concerned functional programming centers around the guarantee that f(x) has the properties associated with a function, i.e. for every x, exactly one f(x) is correct. That's why your data structures must be immutable. That's why you need referential transparency, etc. But how you calculate f(x) really doesn't determine whether this is FP or not. There's certainly a lot of power that can come from a language that can compose or decompose functions for you. But I wouldn't use that as a litmus test for FP. But I suspect (not entirely sure, but suspect) that if you apply sufficient discipline, and omit from the equation the global necessities of registers, you can probably create functions in assembly, and call them in a functional way. In fact I suspect if this were not possible, then FP languages would not be possible to create. But FP in ASM sounds really really painful.