4 ms·

I agree these are just claims, but when I look at the something like the following it is hard not to see the power that comes from simplicity. ;lazy-seq of F

I agree these are just claims, but when I look at the something like the following it is hard not to see the power that comes from simplicity. ;lazy-seq of Fibonacci numbers (defn fibo [] (map first (iterate (fn [[a b]] [b (+ a b)]) [1N 1N]))) You can apply this to a larger set of problems and realize that issues can be solved with less code and that yields less errors. Correctness is also easier to achieve with FP because you don't have the typical problems of non-FP languages (index out of range in a loop for example), I think. I personally think that the following has much more impact on modern CS than the Hughes paper linked above. http://www.erlang.org/download/armstrong_thesis_2003.pdf http://www.erlang.org/download/armstrong_thesis_2003.pdf This is focusing on the reality (operating system threading model, no shared memory across processes -in the Erlang world-, communicate only with message passing, etc.) and this yields to a much higher impact. If you look into Scala features you can find many that came from Erlang, or through Erlang (some of them originally from other languages). SCP also gave a bigger kick to CS (even though it has very little to do with FP) and it seems that FP languages were adopting it faster (I might be wrong on that). http://www.usingcsp.com/cspbook.pdf http://www.usingcsp.com/cspbook.pdf

lectrick 11y ago
I was impressed by both of those papers which is part of the reason I decided to focus on Elixir for now.
coldtea 11y ago
>I agree these are just claims, but when I look at the something like the following it is hard not to see the power that comes from simplicity. What simplicity? That's even more complex to state than the traditional imperative solution, that's also closer to how mathematicians would write the equation.
- istvan__ 11y ago
  I think you are confusing two things here. - calculating the n-th element of the Fibonacci sequence - representing it correctly in code The first one is (assuming the second is present, see code above): (nth (fibo) 10)
alayne 11y ago
I can't be the only one who thinks that implementing a toy function in one line of terse code doesn't demonstrate anything useful. What about programming in the large? What about efficiency of naive implementations? What about maintainability? These are things that actually matter in software engineering.
- collyw 11y ago
  Yep, Django (or anything equivalent) will give you much more productivity in the real world than any of that functional style.
  - istvan__ 11y ago
    I guess you were not joking but we are not talking about web development in this thread. How does Django help my embedded kernel development?
    - collyw 11y ago
      Ok, sure, but I am sure there are related libraries for that kind of development. When talking about the real world, the majority of it is in web development or business apps.
- chriswarbo 11y ago
  > What about maintainability? It's only anecdotal, but I find pure, immutable code far easier to maintain in any language. To a first approximation, a functional interface == a testable interface.
  - denim_chicken 11y ago
    It's only anecdotal, but I feel the opposite.
    - chriswarbo 11y ago
      Really? I'd genuinely love to see some examples. I've joined several projects in their maintenance phase which had no tests, and introduced some as I went about debugging, adding features, etc. Since the code was often untestable, I'd make a few refactorings over and over again to allow testing, and these just-so-happen to tease apart the pure computation from the effects; in essence making the code more functional. An obvious example is to turn implicit state into explicit parameters, eg. // BEFORE function foo(x, y) { b = x + y + a; } // AFTER function foo(x, y) { b = foo_pure(x, y, a); } function foo_pure(x, y, z) { return x + y + z; } This doesn't make `foo` more functional or easier to test; but testing `foo_pure` is trivial. In particular this makes debugging logic errors much easier; since there's no need for elaborate/brittle test setup (eg. setting all the right globals, creating and cleaning up files, etc.).
zak_mc_kracken 11y ago
> it is hard not to see the power that comes from simplicity Actually, it is quite hard for anyone who's not already versed in Lisp and equipped with some reasonable knowledge of basic FP constructs such as folds. It's also important to look at the whole picture, and the author of the paper (and FP advocates in general) have this interesting tendency to completely ignore the opportunity cost of using FP and to dismiss the advantages of alternative approaches over FP. Personally, I think laziness and immutability come at a very heavy price that explains why only the superficial aspects of FP (lambdas) have been adopted while the rest of FP remains the realm of research papers and conferences.
- loup-vaillant 11y ago
  > the author of the paper (and FP advocates in general) have this interesting tendency to completely ignore the opportunity cost of using FP […] Are you referring to the disadvantages of using a non-mainstream style? That's not relevant here. We're comparing the styles themselves, not their popularity. > Personally, I think laziness and immutability come at a very heavy price that explains why only the superficial aspects of FP (lambdas) have been adopted while the rest of FP remains the realm of research papers and conferences. I have a much simpler explanation: first class procedures are compatible with imperative programming, while immutability is not. (And laziness needs immutability to be workable.) People don't adopt FP because old habits die hard.
  - seanmcdirmid 11y ago
    > first class procedures are compatible with imperative programming, while immutability is not But immutability is not is not incompatible with imperative programming, otherwise people wouldn't be writing things like Guy Steele's "Lambda: the ultimate imperative" paper [1]. And of course, monads. > People don't adopt FP because old habits die hard. People don't adopt FP for the same reason they don't wear hair shirts; it is presented and marketed as an "eat your vegetables" affair. [1] http://repository.readscheme.org/ftp/papers/ai-lab-pubs/AIM-353.pdf http://repository.readscheme.org/ftp/papers/ai-lab-pubs/AIM-...
joseraul 11y ago
I suspect that the average coder will find Python-style iterators much easier to read. def fibo(): a, b = 1, 1 while True: yield a a, b = b, a + b
- wz1000 11y ago
  The average speaker would find Mandarin easier to read than any other language. That does not say anything about the effectiveness of Mandarin over other languages.

lectrick 11y ago

I was impressed by both of those papers which is part of the reason I decided to focus on Elixir for now.

coldtea 11y ago

>I agree these are just claims, but when I look at the something like the following it is hard not to see the power that comes from simplicity. What simplicity? That's even more complex to state than the traditional imperative solution, that's also closer to how mathematicians would write the equation.

istvan__ 11y ago
I think you are confusing two things here. - calculating the n-th element of the Fibonacci sequence - representing it correctly in code The first one is (assuming the second is present, see code above): (nth (fibo) 10)

alayne 11y ago

I can't be the only one who thinks that implementing a toy function in one line of terse code doesn't demonstrate anything useful. What about programming in the large? What about efficiency of naive implementations? What about maintainability? These are things that actually matter in software engineering.

collyw 11y ago
Yep, Django (or anything equivalent) will give you much more productivity in the real world than any of that functional style.
- istvan__ 11y ago
  I guess you were not joking but we are not talking about web development in this thread. How does Django help my embedded kernel development?
  - collyw 11y ago
    Ok, sure, but I am sure there are related libraries for that kind of development. When talking about the real world, the majority of it is in web development or business apps.
chriswarbo 11y ago
> What about maintainability? It's only anecdotal, but I find pure, immutable code far easier to maintain in any language. To a first approximation, a functional interface == a testable interface.
- denim_chicken 11y ago
  It's only anecdotal, but I feel the opposite.
  - chriswarbo 11y ago
    Really? I'd genuinely love to see some examples. I've joined several projects in their maintenance phase which had no tests, and introduced some as I went about debugging, adding features, etc. Since the code was often untestable, I'd make a few refactorings over and over again to allow testing, and these just-so-happen to tease apart the pure computation from the effects; in essence making the code more functional. An obvious example is to turn implicit state into explicit parameters, eg. // BEFORE function foo(x, y) { b = x + y + a; } // AFTER function foo(x, y) { b = foo_pure(x, y, a); } function foo_pure(x, y, z) { return x + y + z; } This doesn't make `foo` more functional or easier to test; but testing `foo_pure` is trivial. In particular this makes debugging logic errors much easier; since there's no need for elaborate/brittle test setup (eg. setting all the right globals, creating and cleaning up files, etc.).

zak_mc_kracken 11y ago

> it is hard not to see the power that comes from simplicity Actually, it is quite hard for anyone who's not already versed in Lisp and equipped with some reasonable knowledge of basic FP constructs such as folds. It's also important to look at the whole picture, and the author of the paper (and FP advocates in general) have this interesting tendency to completely ignore the opportunity cost of using FP and to dismiss the advantages of alternative approaches over FP. Personally, I think laziness and immutability come at a very heavy price that explains why only the superficial aspects of FP (lambdas) have been adopted while the rest of FP remains the realm of research papers and conferences.

loup-vaillant 11y ago
> the author of the paper (and FP advocates in general) have this interesting tendency to completely ignore the opportunity cost of using FP […] Are you referring to the disadvantages of using a non-mainstream style? That's not relevant here. We're comparing the styles themselves, not their popularity. > Personally, I think laziness and immutability come at a very heavy price that explains why only the superficial aspects of FP (lambdas) have been adopted while the rest of FP remains the realm of research papers and conferences. I have a much simpler explanation: first class procedures are compatible with imperative programming, while immutability is not. (And laziness needs immutability to be workable.) People don't adopt FP because old habits die hard.
- seanmcdirmid 11y ago
  > first class procedures are compatible with imperative programming, while immutability is not But immutability is not is not incompatible with imperative programming, otherwise people wouldn't be writing things like Guy Steele's "Lambda: the ultimate imperative" paper [1]. And of course, monads. > People don't adopt FP because old habits die hard. People don't adopt FP for the same reason they don't wear hair shirts; it is presented and marketed as an "eat your vegetables" affair. [1] http://repository.readscheme.org/ftp/papers/ai-lab-pubs/AIM-353.pdf http://repository.readscheme.org/ftp/papers/ai-lab-pubs/AIM-...

joseraul 11y ago

I suspect that the average coder will find Python-style iterators much easier to read. def fibo(): a, b = 1, 1 while True: yield a a, b = b, a + b

wz1000 11y ago
The average speaker would find Mandarin easier to read than any other language. That does not say anything about the effectiveness of Mandarin over other languages.