| HN Mirror

gruseom 4823 days ago

I'm afraid you've misunderstood that Wikipedia page. It attributes the phrase "first-order functional programming" to authors other than Kay. All it attributes to Kay is the phrase "value rule".

Kay's interest in spreadsheets wasn't about functional programming, it was about interactive and dynamic computation. I have a pdf of the 1984 Scientific American article that Wikipedia is quoting from. It does include the phrase "value rule"—by which he simply meant what we would call a spreadsheet formula—but I'm pretty sure it makes no argument about functional programming (it's all images so I can't search to be sure). If you'd like a copy, email me. It's a pretty neat article, ahead of its time as one would expect from Alan Kay.

erichocean 4819 days ago

I've already read the Alan Kay article you mentioned (recently, in fact), and that's not what I took away from it.

I guess we'll agree to disagree, I don't think someone needs to use the phrase "first-order functional programming" when they give the very definition of it, which is what Wikipedia does: summarize Kay's argument.

I do agree the article itself was quite interesting, and certainly ahead of its time.

gruseom 4819 days ago

What's Kay's argument, then? And how does it relate to FP? I'm curious.

I was making a textual point about the Wikipedia article. Its use of the phrase "first-order functional programming" is hyperlinked to http://journals.cambridge.org/action/displayAbstract?aid=727.... It's not citing Alan Kay.

erichocean 4818 days ago

I guess I wasn't clear, sorry. What Alan Kay meant by the "spreadsheet value rule" and what the phrase "a limited form of first-order functional progamming" means are semantically equivalent; they are the same thing.

I have no idea if Alan Kay ever used the latter phrase, but it was easier to use that phrase here on HN than Alan Kay's made up phrase, which would have be difficult to understand without the content of the article explaining it.

gruseom 4818 days ago

Ah, gotcha. I agree with you that spreadsheet formulas are a limited form of first-order functional programming. But the memory model with which they are coupled is just as important (I have in mind the grid addressing system and dataflow semantics) and this does not fit as nicely into the FP paradigm. But I'm repeating what I said in other comments.

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.

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.

The "pure" functions are just a subset of "procedure" functions. One can always restrict to use the "pure" function in PHP and yes, that's "first-order functional programming" in PHP. The question is: do we call PHP a functional language?

Likewise, Excel can do stateful update with side effect. The cell formula function happens to be a subset of all it can do. Sure, we can claim it's "first-order functional programming." But do we want to call it a functional language?

My point is that "first-order functional programming" is a really weak qualifier to call a language functional.

You can do "Object Oriented programming" in C++. you can also do "OOP" in plain C, but why do we call C++ an "OO Language" but not C? because the design of the language itself encourages and enforces a particular style of "OOP".

In this case, I believe the "Excel is a functional language" meme is using "Excel" not to include ALL the things that excel does, which includes things like VB and Javascript scripting, but as shorthand for the spreadsheet model of application, and more specifically aimed at Excel's formula language, which enforces the creation of first order functions by excluding the possibility of state-fulness and side-effects from the language's design. It is the fact that this is inherent in its design that merits calling it a functional language, while in php there are no such design choices which enforce or even encourage a functional way of writing code.

Another point to make is that the "Excel is functional" meme is so useful is because, as soon as you tell most programmers that "functional programming" has no variables, no state, and no side-effects, they can't imagine how it's possible to actually do anything useful in a functional language. On the other hand, most programmers do know how to do useful things in a spreadsheet program- which happens to be effectively equivalent to a stateless side-effect free "pure" functional programming language.

gngeal 4824 days 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?

Functional language has the declarative aspect while declarative language lacks the functional aspect. Just because A => B doesn't mean B => A.

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 4823 days 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 4823 days ago

The cells are the functions.

gruseom 4823 days 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.

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!"

cygx 4823 days 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.

Following that logic, OO is an orthogonal attribute to functional. Both of them can define functions, and thus OO is functional.

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.

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.

hippobravo 4824 days 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.

jewbacca 4824 days 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 4823 days 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 4823 days 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

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`?

hippobravo 4823 days ago

The distinction between functional and imperative is precisely a semantic game and nothing else.

Semantic games are meaningful or this blog post wouldn't be on HN. The title of the post makes it clear that we're playing a semantic game.

Kiselyov is deconstructing the constructs. That's fine. He's playing the semantic game of showing how different concepts share ontology. This doesn't make the concepts identical; it makes their deconstructions identical. These paradigms are not physical things they are conceptual abstractions. Anyway I'm obviously not getting through to you.

const is not a promise, it's a constant. Different concepts, similar ontology.

jewbacca 4823 days ago

I'm not sure we have the necessary language in common to communicate here. Functional programming is not just about stateless pure functions, it's also about composing computations. I'm curious if you've ever written in a natively lazy functional language like Haskell, or encountered `delay`/`force` promises in Scheme. The `const` I'm referring to is not the `const` of C et al: (http://hackage.haskell.org/packages/archive/base/latest/doc/...) and is just an example.

A "promise" is a delayed computation. It's a stand-in for a value, and the computation referencing it will suspend its execution until a value is available for it to consume. Similarly with Iteratees. They encapsulate specific patterns for building computations out of other computations.

What makes the "promise" pattern relatively less imperative than threading callbacks is that it abstracts out a specific pattern for ordering a computation, so that it doesn't need to be restated every time.

What makes the "promise" pattern relatively less declarative than "purely declarative" is that the control of the computation can be specified in the language itself. It's just abstracted out to the pattern in common. Similarly to re-writing certain stateful `for` loops with `map`.

Promises are a pattern in the functional programming paradigm. The "functional programming community" is where the construct comes from, and using them lets you write code that is closer to the declarative ideals of functional programming than the article's specified alternative, threading callbacks, which has relatively more in common with the explicit control of the order of computation that is implied by imperative programming.

I don't see anything in the article that remotely justifies "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.". In fact, I don't see anything wrong with it at all, or anything that substantially disagrees with what I've said or what I've seen any of the type of (yet-unspecified) authorities of certified expertise that you've appealed to have said. Yes, Promises are relatively more declarative, but they're also relatively more functional, relatively less imperative, and I don't see any basis for calling somebody an idiot for not using those terms with total mutual exclusion.

So please, raise, any specific objections you have which I have not addressed, or else have the honesty to retract the undeserved insults you've thrown at the author of this article.

jasondenizac 4824 days ago

HN comment threads are my favorite learning environment.