3 ms·

It feels a little bit disingenuous to say that you can use a spreadsheet's builtin "sum" function to compute a sum. It honestly sounds like an argument in favor

It feels a little bit disingenuous to say that you can use a spreadsheet's builtin "sum" function to compute a sum. It honestly sounds like an argument in favor of functional languages; here's a Haskell program that's just as simple: Prelude> sum [1, 2, 3] 6 Hey, you could even search for a library that sums lists for you in C, then include and call that function.

eru 11y ago
Yes, it's a simple first order function on some kind of collection. A sum function is not very `function' at all. (It sure feels at home in functional languages, more than in imperative bit-by-bit piecemeal programming, sure.)
- z1mm32m4n 11y ago
  I think the idea that the author was trying to express was that in a spreadsheet language, you select a data range and then choose a function to perform on that data. That's the "functional" aspect I took away from my reading of it.
  - the_french 11y ago
    Its no huge surprise that spreadsheets implement a form of FRP . Specifically, you can look at loeb's function [1] as an example of the relation. Being able to focus on the data itself while easily composing operations is definitely functional in nature. However, FP is not a silver bullet either. In practice I think humans care a bit less about correctness than compilers and would like some aspects of the language to be 'fuzzy' for lack of a better word. To most people "1" and 1 are the same thing so why shouldn't the compiler understand that. There could be potential for a dynamic-fp language of sorts. [1] http://blog.sigfpe.com/2006/11/from-l-theorem-to-spreadsheet.html http://blog.sigfpe.com/2006/11/from-l-theorem-to-spreadsheet...
    - eru 11y ago
      `Fuzziness' and FRP are pretty orthogonal. Ie even in Haskell as it is, it's pretty easy to add an 'if' that takes 'truthy ' and 'falsy' values like in Python. Just use a type-class 'Booly' that include a conversion function toBool.
wuch 11y ago
And in C++ you would write this as follows (with a range library it would be a one-liner): const auto & xs = {1, 2, 3}; cout << accumulate(begin(xs), end(xs), 0);

eru 11y ago

Yes, it's a simple first order function on some kind of collection. A sum function is not very `function' at all. (It sure feels at home in functional languages, more than in imperative bit-by-bit piecemeal programming, sure.)

z1mm32m4n 11y ago
I think the idea that the author was trying to express was that in a spreadsheet language, you select a data range and then choose a function to perform on that data. That's the "functional" aspect I took away from my reading of it.
- the_french 11y ago
  Its no huge surprise that spreadsheets implement a form of FRP . Specifically, you can look at loeb's function [1] as an example of the relation. Being able to focus on the data itself while easily composing operations is definitely functional in nature. However, FP is not a silver bullet either. In practice I think humans care a bit less about correctness than compilers and would like some aspects of the language to be 'fuzzy' for lack of a better word. To most people "1" and 1 are the same thing so why shouldn't the compiler understand that. There could be potential for a dynamic-fp language of sorts. [1] http://blog.sigfpe.com/2006/11/from-l-theorem-to-spreadsheet.html http://blog.sigfpe.com/2006/11/from-l-theorem-to-spreadsheet...
  - eru 11y ago
    `Fuzziness' and FRP are pretty orthogonal. Ie even in Haskell as it is, it's pretty easy to add an 'if' that takes 'truthy ' and 'falsy' values like in Python. Just use a type-class 'Booly' that include a conversion function toBool.

wuch 11y ago

And in C++ you would write this as follows (with a range library it would be a one-liner): const auto & xs = {1, 2, 3}; cout << accumulate(begin(xs), end(xs), 0);