Isn't JS functional?
Last year, I wrote an article [1] talking a little bit about this, arguing that the notion of 'language paradigms' is mostly a crutch to avoid thinking critically about what a language is.
[1] https://chadaustin.me/2015/09/haskell-is-not-a-purely-functi...
The recent trend of "functional JavaScript" is mostly using third party tools that emulate feature from other languages (like Immtutable.js or Ramda), but IMO the core language cannot be called a proper functional language.
Everything else is a convenience and not a requirement for the functional paradigm.
Mind you, I do much prefer a Lisp or Scala to Javascript, but I face no trouble writing functional code in Javascript.
The big paradigm divisions were largely a thing of the 1990s; since then languages have become increasingly multiparadigm, so that it's almost hard to find a language that isn't nowadays. I think Haskell and Golang might be just about the last remaining standard-bearers of the league of one-trick ponies.
Out of curiousity, what other criteria would you apply?
You're more than welcome to have your own definition, but it's my opinion that it's too broad since HOFs exist in some form in languages like Java and Ruby and I wouldn't call them functional though like another commented said, languages are mixing paradigms nowadays (with the exception of Haskell!).
Or, say, SQL sans stored procedures?
I think the more appropriate term in this case is "declarative". "Functional" really implies something having to do with functions.
(0) It encourages using values over objects with a notion of physical identity.
(1) It encourages using procedures that compute functions: mappings from values to values.
(2) It discourages distinguishing between procedures that compute the same function.
Let's see how well JavaScript fares:
(0) Are `[1,2,3]` and `[1,2,3]` equal or different?
(1) Given `function(x) { return { first: x, second: y }; }`, are `f("hello")` and `f("hello")` equal or different?
(2) Are `function(x,y) { return x + y; }` and `function(x,y) { return x + y; }` equal or different?
This should tell you whether JavaScript is a functional language.
> A functional language is a procedural language
this doesn’t sound authoritative:
> that meets the following three additional conditions
this doesn’t sound like the right distinction:
> It encourages using values over objects
and this doesn’t sound meaningful:
> It discourages distinguishing between procedures that compute the same function.
A functional language still uses procedures, even Haskell! To see what I mean, consider the possibility of divergence (infinite loop, `undefined`, `error "foo"`, you name it). It doesn't make sense for a mathematical function to diverge. The difference between, on the one hand, Haskell, ML and Racket, and, on the other hand, JavaScript, Python and Ruby, is that the former group encourages you program with procedures that compute mathematical functions, whereas the latter group does not.
> this doesn’t sound like the right distinction
It doesn't suffice, but it's a precondition. For good or for bad, mathematical functions are mappings from values to values, so you can't talk about computing functions in a language without a rock-solid notion of (possibly compound) value.
> and this doesn’t sound like the right example for (2) [deleted from your original post, but I'm not deleting it from here]
Yes, it's the right example. Haskell and ML prevent you from accidentally distinguishing two extensionally equal functions by not letting you compare procedures in the first place.
> and this doesn’t sound meaningful
These functions ought to be extensionally equal in any mathematically civilized language:
function foo(x,y) { return x + y; }
function bar(x,y) { return x + y; }
In other words, Haskell doesn't have try/catch for things like `undefined`, so we do have to worry about them occuring, but we don't have to worry about them causing the code to misbehave; it'll either behave or it will stop progressing (either halting or looping infinitely).
On the other hand, the "IO" DSL built in to Haskell can do try/catch; but once you're in IO, all bets are off.
The nice thing about Haskell is that it distinguishes between procedures that may only compute functions (or diverge), and procedures with arbitrary effects.
And Prolog programs are literally lists of declarations (of inference rules), yet Prolog isn't a functional language.
Backing up to equality as an aside, is there any language that will let you determine whether two functions are equal? If the functions that can be compared aren’t restricted to some silly level and the language is Turing-complete, I can’t imagine any better behaviour than Haskell’s that you already mentioned, which you can bring to JavaScript pretty easily.
Well, your quote doesn't even provide a full definition, sooo...
> Backing up to equality as an aside, is there any language that will let you determine whether two functions are equal?
No, that's obviously undecidable. (Rice's theorem.) But read what I said more carefully. Did I ever say “A functional language lets you determine whether two functions are equal?” I didn't! What I said is “A functional language doesn't let you distinguish equal functions.” Not letting you test functions for equality is a perfectly valid (and, in fact, the only valid) approach in a higher-order language.
> which you can bring to JavaScript pretty easily.
Not really. I can't undefined JavaScript's existing equality operator.
I thought as much and it would really help if you would just say these sorts of things outright so the comments are actually useful instead of deeply nested wording quibbles.
With that out of the way: you can define a subset of JavaScript that satisfies your third condition by saying “don’t compare functions”. That’s why I didn’t consider it a meaningful condition.
Functional programming works best as a paradigm and then we can just call languages where it’s standard “functional languages”. Much simpler.
I find it absolutely essential to make perfectly clear what exactly I'm refuting.
> With that out of the way: you can define a subset of JavaScript that satisfies your third
Second.
> condition by saying “don’t compare functions”.
That's a different language. Do you know of any implementation of it?
> Functional programming works best as a paradigm and then we can just call languages where it’s standard “functional languages”. Much simpler.
Nope. A functional language is one that makes it easy to write functional programs, by satisfying the conditions I gave above. A programming language is first and foremost its semantics, whatever the culture of its users.
Except you’ve still given no source for the conditions, condition -1 (“a functional language is a procedural language”) is wrong, and a language satisfying the conditions in no way makes it easier to write a functional program just by virtue of satisfying the conditions (because they can be satisfied entirely by removing features you don’t have to use). Maybe you meant “harder to write non-functional programs”.
> Second.
The last item in a list of three items is not the second item.
It's correct. In a procedural language, computations are structured as procedures that may call each other. In a functional language, that condition (plus three additional ones) hold.
> and a language satisfying the conditions in no way makes it easier to write a functional program just by virtue of satisfying the conditions
Removing pointer arithmetic makes it easier to write programs that don't contain memory errors. Removing spurious distinctions between memory blobs that hold the same value makes it easier to program with mathematical functions.
> (because they can be satisfied entirely by removing features you don’t have to use)
Removing features creates a different language. Often a nicer one!
> Maybe you meant “harder to write non-functional programs”.
Nope. That would exclude any general-purpose programming language. Lest you think otherwise: it's very easy to write imperative programs in Haskell and ML.
> The last item in a list of three items is not the second item.
Zeroth, first, second.
Erm, yes you can. You don't need "a rock-solid notion" of anything in order to talk about anything. It's certainly nice to have such well-defined concepts/terms, but requiring them is preposterous.
So? Is the problem here that you can’t compare objects equivalent according to this with `==`? You can make a comparison to do this properly. (This is why functional programming as a paradigm works better and functional languages are just those where it’s the obvious standard.)
That's not the point! Even if I made a custom equality comparison that says two different objects are “equal”, it would be unsound to treat them as equal, because there exist other constructs in JavaScript that will let me distinguish them. For example, if I mutate one of the objects, the other will remain in its original state. This is exactly why a usable functional language must provide a good notion of compound value!
I didn't see anyone making claims about soundness. From a Curry-Howard perspective, all JS code is sound: it's unityped, so all programs are proofs of the trivial theorem "true".
From the perspective of equality functions/operators, you're right that it won't be sound; but so what? It's pretty much given that "Javascript foo" is a poor model of "foo", for all values of "foo" (function, integer, boolean, etc.); why should equality make any difference?
Just add "==" and "===" to your list of things to avoid, alongside mutation, random numbers, user input and other things which aren't referentially transparent. To be honest, equality isn't particularly bad if your code has some notion of types/contracts (whether enforced or not); e.g. it's perfectly safe to use "==" when you know that both sides will be strings, for example.
> For example, if I mutate one of the objects, the other will remain in its original state.
Mutation doesn't seem like a great example when discussing (pure) functional programming patterns.
> This is exactly why a usable functional language must provide a good notion of compound value!
You introduction of the term "usable" seems like a moving goalpost/no true scotsman.
Haskell and ML aren't unityped, but, in both, every type is inhabited by expressions. (Caveat: In ML, not all types are inhabited by values, but that doesn't matter, because programs correspond to expressions, not values.) So this doesn't distinguish them from JavaScript.
> From the perspective of equality functions/operators, you're right that it won't be sound; but so what? It's pretty much given that "Javascript foo" is a poor model of "foo", for all values of "foo" (function, integer, boolean, etc.); why should equality make any difference?
Equality matters, because the very first condition to determine whether a procedure computes a function is to see whether it maps equal inputs to equal outputs!
> Just add "==" and "===" to your list of things to avoid, alongside mutation, random numbers, user input and other things which aren't referentially transparent.
That's a different language. Do you know of any good implementations of it? And, FWIW, procedures that compute random numbers are totally fine. You can't rule out procedures that don't compute mathematical functions. You can only keep their use to the minimum necessary.
> To be honest, equality isn't particularly bad if your code has some notion of types/contracts (whether enforced or not); e.g. it's perfectly safe to use "==" when you know that both sides will be strings, for example.
In my day-to-day programming I manipulate more complex data structures than strings.
> Mutation doesn't seem like a great example when discussing (pure) functional programming patterns.
I'm not talking about pure anything. I'm saying that mathematical functions are value mappings, and if the language doesn't let you define compound values (tuples, lists, trees, whatever), then it can only conveniently implement very trivial functions - not enough for practical programming.
> You introduction of the term "usable" seems like a moving goalpost/no true scotsman.
I'm not moving anything. A functional language is one that makes it easy to write functional programs. The lack of compound values means that I'm given two unpleasant choices:
(0) Use Gödel numbers to encode compound values. Would you?
(1) Do imperative programming.
In practice, Haskellers don't think this way about their programs. Haskell's library ecosystem attests to the fact they think of Hask as some moral analogue of the category of sets, which has both sums and tensor products. And the worst sin a semantics can commit is to not reflect how programmers actually think about their code.
function time() { return new Date() }
I'm aware, but that's too strong a requirement. I wanted my definition to capture the bare minimum necessary to make it pleasant to write functional programs. The basic idea is “functional programming is designing your programs in terms of mathematical functions whenever possible (not always!)”, not “functional programming is requiring an embedded IO DSL to do anything effectful”. (But don't take this as a dismissal of Haskell. While I do have complaints against it, effect segregation isn't one of them.)
> but because the return value of this function can change even when its arguments don't, this is not true in Javascript.
That's okay. A procedure that returns the system date will never be referentially transparent, yet such a procedure is a necessity in any programming language.
My beef is actually with the fact JavaScript doesn't have compound values: https://news.ycombinator.com/item?id=12191119 . Since compound entities (whether values or mutable objects) are a necessity in practical programming, the harsh reality is that JavaScript programmers have to use mutable objects whether they want it or not.
As long as it accepts a Universe or State parameter, a system time function is referentially transparent. This is rather like how every query in a database can be seen as implicitly depending on a transaction ID parameter.
One intuition that falls out of the Church-Turing thesis is that there is no routine in C, Pascal, &c that has no referentially transparent equivalent.
Which begs the question - where do you get that Universe parameter from? Note that getting a single Universe parameter at the beginning of the program is of no use, because then you couldn't query the system date right now. You could only query the system date at the moment the program started.
You can't completely get rid of non-referentially transparent procedures in a general-purpose programming language. What you can do, at most, is banish them to a special sublanguage, like Haskell does.
> the Church-Turing thesis
The Church-Turing thesis is a statement about computable functions, but a procedure that returns the system date clearly doesn't compute a mathematical function.
This is like saying, "...getting a single input at the beginning of the program is of no use..." but see below.
> The Church-Turing thesis is a statement about computable functions...
It is a statement about what is "computable", which is the alpha and the omega of what computers can do. If there is a Turing model for a particular "computation" there is a Lambda Calculus model for it.
A program that returns the system date operates on the machine state. You can treat this as "read from the tape" in the Turing sense or as input in the Lambda Calculus sense. The "output" can be seen as one of:
* A tape where the system states has been updated (since we took some steps, we updated the CPU counter, handled some interrupts, &c) and the system time has been written to a special place on the tape so the next computation can find it.
* A tuple of a new system state and the time value (picked out, again, for our convenience).
If we imagine the world "as a computer" then it is natural to compute a later state of the world as a function of the previous state. This approach actually works well in practice and it is not coincidental that this approach works with computers, since it is deeply tied into how they work.
Per Heraclitus, we never set foot in the same river twice. Treating the State or Universe as non-comparable captures this idea.
The Church-Turing thesis is about what functions are computable.
> A program that returns the system date operates on the machine state. You can treat this as "read from the tape" in the Turing sense or as input in the Lambda Calculus sense.
Are you saying that the input tape may contain the later time at which a program will query the system's date? That seems like a physical impossibility to me.
> If we imagine the world "as a computer" then it is natural to compute a later state of the world as a function of the previous state.
The fundamental deficiency of this model is that it assumes you can put the entire world inside your program, and then get an entire new world as result. It utterly fails to take concurrency into consideration.
Are you saying, that procedural programming can do something besides compute computable functions?
> Are you saying that the input tape may contain the later time at which a program will query the system's date? That seems like a physical impossibility to me.
When the computer retrieves the time from the clock, it does exactly that -- reads it from a location in memory.
> > If we imagine the world "as a computer" then it is natural to compute a later state of the world as a function of the previous state.
> The fundamental deficiency of this model is that it assumes you can put the entire world inside your program, and then get an entire new world as result. It utterly fails to take concurrency into consideration.
How does it fail to take concurrency into account? We can treat the world as being made up of many objects and evolve their state simultaneously if we like.