7 ms·

I feel this is twisting the meaning of functional programming. Excel is not functional. It is declarative. You declare the relationships between the cells an

by ww520 14y ago

I feel this is twisting the meaning of functional programming. Excel is not functional. It is declarative. You declare the relationships between the cells and Excel uses those to propagate changes. Just like a makefile is not functional but declarative. The dependency of the relationships are enforced to produce action. SQL is another example of declarative language and it is nowhere near as functional.

hippobravo 14y ago
This was my thought as well. Promises are declarative... making a promise is almost the very definition of declarative programming. It's not functional at all. This reaffirms my belief that blog posts are a terrible place to learn. People who know the least shout the loudest.
- jasondenizac 14y ago
  HN comment threads are my favorite learning environment.
- jewbacca 14y ago
  A tyrannical dichotomy. Functional programming is declarative. Especially when it's lazy and the program's instantaneous state is abstracted out. One of the motivating goals in functional programming is to be able to define a computation once, in terms of other computations, and have that relationship be maintained with minimal regard to the state of the program or its order of execution. Which is what it seems like (this is the first time I've specifically encountered them) Promises are a powerful tool for accomplishing. In contrast, threading explicit callbacks/continuations through a program, which is explicitly managing the order of execution, is relatively more imperative, which I think is the point of the article -- you don't need the wider control-flow flexibility of explicitly and manually threading callbacks to do the type of computations that most async web stuff does. You can abstract the common callback pattern out into something like Promises, and make all your shit more consistent and concise.
  - hippobravo 14y ago
    I'm not saying his design sense is wrong. I'm saying his characterization of promises as functional is so close to being right that it's the worst kind of wrongness. It's worse to say, "The capital of Kenya is Nairobi Central" than to say "The capital of Kenya is London." It is worse because errors that are only slightly wrong and maybe even partially correct are more deceptive, durable, and confusing. A promise is not a functional concept. Functions don't make promises. You CAN, as a thinking human, re-conceptualize the immutable return value of a function as being "pretty much the same" as a promise, but when you re-conceptualize functional programming you are just deconstructing what is already understood to be an arbitrary conceptual construct. Any conceptual construct--especially one based on simple metaphors--can be deconstructed into some other form. This doesn't invalidate the construct and it doesn't equate the construct as such with the deconstructed components. You might as well say that an airplane is not really an airplane. It's just two wings, a cockpit, some jet engines and a fuselage assembled together in a certain way so that it can fly. It's not really an airplane; it's just those things in that way. And those things are really just all made out of aluminium so really it's not an airplane it's just aluminium. Anyone who says an airplane is more than just aluminium is making a tyrannical dichotomy. So according to you promises are functional because under the hood promises have some conceptual similarity to the immutable return values provided in functional programming. But under the hood the Boeing 737 is just scrap metal. Yet it's NOT just scrap metal. The difference is that "the promise" is a precise concept based on some metaphors that is specifically used in declarative styles and not in functional styles. Functions return immutable values. Declarations make promises. Under the hood there may be similarities but no one made any claims to the contrary. If people don't think these high level conceptual distinctions are important, why are they even reading this article that is entirely about splitting hairs between these conceptual distinctions? AND the article is even getting it wrong because the author is a self-admitted amateur. Why bother learning from the village loudmouth when there are geniuses who publish books and give lectures just down the hall? The stuff that reaches the front page of HN makes no sense. Most of it is written by terribly ignorant people. Programmers have no respect for expertise.
    - jewbacca 14y ago
      Okay, if you require an appeal to authority, here is Oleg Kiselyov deriving Iteratees in Haskell, a more general formalization of "futures"/"promises": http://okmij.org/ftp/Streams.html http://okmij.org/ftp/Streams.html If you insist on setting up semantic games: if Oleg hacking Haskell isn't functional programming then nothing meaningfully is. ---- > Functions return immutable values. Declarations make promises. Under the hood there may be similarities but no one made any claims to the contrary. What does `foldr (+)` return? What about `const 1`?
gngeal 14y ago
"Excel is not functional. It is declarative. You declare the relationships between the cells and Excel uses those to propagate changes." Whereas in functional languages, the functions declare relationships between values and the language uses the evaluation model to propagate the results between function evaluation. Where's the difference?
- ww520 14y ago
  Functional language has the declarative aspect while declarative language lacks the functional aspect. Just because A => B doesn't mean B => A.
  - TheZenPsycho 14y ago
    You are correct that the fact that excel is declarative does not, on its own, make it "functional"... the fact that excel formulas adhere (by the definition of what an excel formula is) to the statelessness, and referential transparency requirements of "first order functions" does make it functional.
    - gruseom 14y ago
      But Excel doesn't have first order functions. You can't even define a function in spreadsheet cells, let alone pass one around as a value.
      - chousuke 14y ago
        The cells are the functions.
        gruseom 14y ago
        A cell formula defines a computation, but not a function. For it to be a function you have to be able to reuse it (call it as a function) in multiple places. For example, you can't define the abstraction "square" in Excel. You can compute 2 * 2, A1 * A1 and so on. But there's no way to define a construct which given x produces x * x, then reuse that construct everywhere you want to square things. Everywhere you want to square something, you must inline the computation. That's the absence of functional abstraction.
erichocean 14y ago
Excel is not functional. It is declarative. Alan Kay (yes, that Alan Kay[1] -- the guy that's won a Turing award) formalized spreadsheets as a limited form of first-order functional programming.[0] [0] http://en.wikipedia.org/wiki/Spreadsheet#Values http://en.wikipedia.org/wiki/Spreadsheet#Values [1] http://en.wikipedia.org/wiki/Alan_Kay http://en.wikipedia.org/wiki/Alan_Kay
- ww520 14y ago
  With all due respect to Alan Kay, I don't know what he meant by "first order functional programming." If we are talking in relation to high order functions, a high order function is one that can take other functions as parameters or produces functions in return, i.e. a high order function maps functions to functions. All other functions are first order function, i.e. they are ordinary functions mapping values to values. In that case any languages supporting function is "first-order functional programming." It's kind of meaningless when we are talking about real functional languages. PHP can define a function that takes a value and returns a value, and thus it can do "first-order functional programming." But no one claims PHP is a functional language. (Not to degrade PHP, it's a good language doing what it does best.) All these twisting the definition of functional programming just produce more confusion.
  - TheZenPsycho 14y ago
    What most C derivative programming languages call a "function" is not actually a "function" in the sense meant in "functional programming". It is more accurately called a "procedure". While you can write a "functional function" in php, there's nothing inherent about php's "functions" that makes them "functional". it's up to the programmer to make them so. On the other hand, a "formula" in excel is inherently a "functional" function or "first order function". Why? two things: No side effects, and statelessness- that is, the order of the computation is theoretically implicit: a value can be computed in a number of different arbitrary orders without effecting the final result.-- not explicit- like in php, where you are specifying an exact order of operations by the order of statements in a procedure ("function"). Another thing about statelessness is that given the same input, a "first order function" must always return the same output. The fact that order is not explicit in excel, that there is no user controlled "state" means that there's certain associative, commutative and compositional properties available to "first order" functions that are not possible with a procedure that is not guaranteed to be a first order function. it's the difference between deciding to do functional programming in an imperative language, and having functional programming structurally enforced by the language.
TheZenPsycho 14y ago
declarative is an orthogonal attribute to functional. The two attributes are not mutually exclusive. You may as well say something like: "A bicycle isn't a vehicle at all! A Bicycle is a metallic object!"
- ww520 14y ago
  Following that logic, OO is an orthogonal attribute to functional. Both of them can define functions, and thus OO is functional.
  - TheZenPsycho 14y ago
    First of all, that's not what "functional" means. Second, OO is an orthogonal attribute to functional. Third, your argument commits a formal fallacy of this form: All cats have whiskers Cats can have stripes Tony has stripes therefore tony is a cat. ---The possibility of an attribute in X, and Y containing that attribute does not imply that Y is an X. the point is that whether something is declarative has no bearing on whether it is functional or not. It's an irrelevant point to bring up. Whether something is OO is equally irrelevant. That is what "orthogonal" means. I would go on to define for you "functional" "declarative", "formal fallacy" "logic", but this seems like a bottomless rabbit hole. I can only hope you'll try and find out what these words actually mean yourself.
    - ww520 14y ago
      Ok. I misread what you wrote in my haste and misunderstood what you said. You can ignore my reply to your original comment. However, my original point was addressing the claim in the blog that functional and declarative are equivalent in that functional has aspect of declarative. And since Excel is declarative, it's functional. I was basically saying that's not the case. While declarative and functional can be orthogonal, and can both live in a language is an interesting but separate topic that is not really related to the original comment.
- cygx 14y ago
  Imo declarative, functional and OO are somewhat but not really orthogonal concepts. A mathematical (ie pure) function is declarative in nature as it defines a relation between sets. However, in practice you often use it imperatively, ie as a means to get an output from some input. An object is imperative in nature as it encapsulates mutable state. However, the set of messages defines an abstract interface which is arguably declarative. In principle, a purely functional language cannot be object-oriented, and a purely object-oriented language cannot be functional. In practice, this doesn't matter as pure languages are rare.

by ww520 14y ago

hippobravo 14y ago

This was my thought as well. Promises are declarative... making a promise is almost the very definition of declarative programming. It's not functional at all. This reaffirms my belief that blog posts are a terrible place to learn. People who know the least shout the loudest.

jasondenizac 14y ago
HN comment threads are my favorite learning environment.
jewbacca 14y ago
A tyrannical dichotomy. Functional programming is declarative. Especially when it's lazy and the program's instantaneous state is abstracted out. One of the motivating goals in functional programming is to be able to define a computation once, in terms of other computations, and have that relationship be maintained with minimal regard to the state of the program or its order of execution. Which is what it seems like (this is the first time I've specifically encountered them) Promises are a powerful tool for accomplishing. In contrast, threading explicit callbacks/continuations through a program, which is explicitly managing the order of execution, is relatively more imperative, which I think is the point of the article -- you don't need the wider control-flow flexibility of explicitly and manually threading callbacks to do the type of computations that most async web stuff does. You can abstract the common callback pattern out into something like Promises, and make all your shit more consistent and concise.
- hippobravo 14y ago
  I'm not saying his design sense is wrong. I'm saying his characterization of promises as functional is so close to being right that it's the worst kind of wrongness. It's worse to say, "The capital of Kenya is Nairobi Central" than to say "The capital of Kenya is London." It is worse because errors that are only slightly wrong and maybe even partially correct are more deceptive, durable, and confusing. A promise is not a functional concept. Functions don't make promises. You CAN, as a thinking human, re-conceptualize the immutable return value of a function as being "pretty much the same" as a promise, but when you re-conceptualize functional programming you are just deconstructing what is already understood to be an arbitrary conceptual construct. Any conceptual construct--especially one based on simple metaphors--can be deconstructed into some other form. This doesn't invalidate the construct and it doesn't equate the construct as such with the deconstructed components. You might as well say that an airplane is not really an airplane. It's just two wings, a cockpit, some jet engines and a fuselage assembled together in a certain way so that it can fly. It's not really an airplane; it's just those things in that way. And those things are really just all made out of aluminium so really it's not an airplane it's just aluminium. Anyone who says an airplane is more than just aluminium is making a tyrannical dichotomy. So according to you promises are functional because under the hood promises have some conceptual similarity to the immutable return values provided in functional programming. But under the hood the Boeing 737 is just scrap metal. Yet it's NOT just scrap metal. The difference is that "the promise" is a precise concept based on some metaphors that is specifically used in declarative styles and not in functional styles. Functions return immutable values. Declarations make promises. Under the hood there may be similarities but no one made any claims to the contrary. If people don't think these high level conceptual distinctions are important, why are they even reading this article that is entirely about splitting hairs between these conceptual distinctions? AND the article is even getting it wrong because the author is a self-admitted amateur. Why bother learning from the village loudmouth when there are geniuses who publish books and give lectures just down the hall? The stuff that reaches the front page of HN makes no sense. Most of it is written by terribly ignorant people. Programmers have no respect for expertise.
  - jewbacca 14y ago
    Okay, if you require an appeal to authority, here is Oleg Kiselyov deriving Iteratees in Haskell, a more general formalization of "futures"/"promises": http://okmij.org/ftp/Streams.html http://okmij.org/ftp/Streams.html If you insist on setting up semantic games: if Oleg hacking Haskell isn't functional programming then nothing meaningfully is. ---- > Functions return immutable values. Declarations make promises. Under the hood there may be similarities but no one made any claims to the contrary. What does `foldr (+)` return? What about `const 1`?

gngeal 14y ago

"Excel is not functional. It is declarative. You declare the relationships between the cells and Excel uses those to propagate changes." Whereas in functional languages, the functions declare relationships between values and the language uses the evaluation model to propagate the results between function evaluation. Where's the difference?

ww520 14y ago
Functional language has the declarative aspect while declarative language lacks the functional aspect. Just because A => B doesn't mean B => A.
- TheZenPsycho 14y ago
  You are correct that the fact that excel is declarative does not, on its own, make it "functional"... the fact that excel formulas adhere (by the definition of what an excel formula is) to the statelessness, and referential transparency requirements of "first order functions" does make it functional.
  - gruseom 14y ago
    But Excel doesn't have first order functions. You can't even define a function in spreadsheet cells, let alone pass one around as a value.
    - chousuke 14y ago
      The cells are the functions.
      - gruseom 14y ago
        A cell formula defines a computation, but not a function. For it to be a function you have to be able to reuse it (call it as a function) in multiple places. For example, you can't define the abstraction "square" in Excel. You can compute 2 * 2, A1 * A1 and so on. But there's no way to define a construct which given x produces x * x, then reuse that construct everywhere you want to square things. Everywhere you want to square something, you must inline the computation. That's the absence of functional abstraction.

erichocean 14y ago

Excel is not functional. It is declarative. Alan Kay (yes, that Alan Kay[1] -- the guy that's won a Turing award) formalized spreadsheets as a limited form of first-order functional programming.[0] [0] http://en.wikipedia.org/wiki/Spreadsheet#Values http://en.wikipedia.org/wiki/Spreadsheet#Values [1] http://en.wikipedia.org/wiki/Alan_Kay http://en.wikipedia.org/wiki/Alan_Kay

ww520 14y ago
With all due respect to Alan Kay, I don't know what he meant by "first order functional programming." If we are talking in relation to high order functions, a high order function is one that can take other functions as parameters or produces functions in return, i.e. a high order function maps functions to functions. All other functions are first order function, i.e. they are ordinary functions mapping values to values. In that case any languages supporting function is "first-order functional programming." It's kind of meaningless when we are talking about real functional languages. PHP can define a function that takes a value and returns a value, and thus it can do "first-order functional programming." But no one claims PHP is a functional language. (Not to degrade PHP, it's a good language doing what it does best.) All these twisting the definition of functional programming just produce more confusion.
- TheZenPsycho 14y ago
  What most C derivative programming languages call a "function" is not actually a "function" in the sense meant in "functional programming". It is more accurately called a "procedure". While you can write a "functional function" in php, there's nothing inherent about php's "functions" that makes them "functional". it's up to the programmer to make them so. On the other hand, a "formula" in excel is inherently a "functional" function or "first order function". Why? two things: No side effects, and statelessness- that is, the order of the computation is theoretically implicit: a value can be computed in a number of different arbitrary orders without effecting the final result.-- not explicit- like in php, where you are specifying an exact order of operations by the order of statements in a procedure ("function"). Another thing about statelessness is that given the same input, a "first order function" must always return the same output. The fact that order is not explicit in excel, that there is no user controlled "state" means that there's certain associative, commutative and compositional properties available to "first order" functions that are not possible with a procedure that is not guaranteed to be a first order function. it's the difference between deciding to do functional programming in an imperative language, and having functional programming structurally enforced by the language.

TheZenPsycho 14y ago

declarative is an orthogonal attribute to functional. The two attributes are not mutually exclusive. You may as well say something like: "A bicycle isn't a vehicle at all! A Bicycle is a metallic object!"

ww520 14y ago
Following that logic, OO is an orthogonal attribute to functional. Both of them can define functions, and thus OO is functional.
- TheZenPsycho 14y ago
  First of all, that's not what "functional" means. Second, OO is an orthogonal attribute to functional. Third, your argument commits a formal fallacy of this form: All cats have whiskers Cats can have stripes Tony has stripes therefore tony is a cat. ---The possibility of an attribute in X, and Y containing that attribute does not imply that Y is an X. the point is that whether something is declarative has no bearing on whether it is functional or not. It's an irrelevant point to bring up. Whether something is OO is equally irrelevant. That is what "orthogonal" means. I would go on to define for you "functional" "declarative", "formal fallacy" "logic", but this seems like a bottomless rabbit hole. I can only hope you'll try and find out what these words actually mean yourself.
  - ww520 14y ago
    Ok. I misread what you wrote in my haste and misunderstood what you said. You can ignore my reply to your original comment. However, my original point was addressing the claim in the blog that functional and declarative are equivalent in that functional has aspect of declarative. And since Excel is declarative, it's functional. I was basically saying that's not the case. While declarative and functional can be orthogonal, and can both live in a language is an interesting but separate topic that is not really related to the original comment.
cygx 14y ago
Imo declarative, functional and OO are somewhat but not really orthogonal concepts. A mathematical (ie pure) function is declarative in nature as it defines a relation between sets. However, in practice you often use it imperatively, ie as a means to get an output from some input. An object is imperative in nature as it encapsulates mutable state. However, the set of messages defines an abstract interface which is arguably declarative. In principle, a purely functional language cannot be object-oriented, and a purely object-oriented language cannot be functional. In practice, this doesn't matter as pure languages are rare.