5 ms·

Not really, no. Example: partial function application does not feel nearly as natural as in in Haskell.

altcognito 10y ago
The reason they use JavaScript is because it's known by many and the examples can be tried without downloading/having an additional compiler. There are at least two dozen concepts on the list there - the value of illustrating new concepts for some with a known quantity far outweighs the downsides of having to start with a fresh environment. I will say though for the exact cases you mention, they probably should be clear why this isn't exactly the concept as described.
- gaius 10y ago
  Here you go: http://tryhaskell.org http://tryhaskell.org
Waterluvian 10y ago
It's definitely no Haskell. But if you wanted to do FP in JavaScript, it wouldn't be a painful ordeal, no? Well, ES6 and newer at least.
- catnaroek 10y ago
  Functional programming puts the static structure of a program at the forefront: types, invariants, equations relating inputs and outputs of processes, etc. JavaScript doesn't do this very well. In fact, even C++ does it better than JavaScript. Nobody would in their reasonable mind call C++ a functional language, right?
  - justinhj 10y ago
    In Javascript functions are first class objects, there are closures, and higher order functions. Having a garbage collector makes it easier to implement persistent data structures. I've always thought that despite it's weird corners it's actually a powerful and flexible language. You can see that in the article, because in just a handful of lines of code it is able to express all of these ideas in an accessible way. I'd be interested to see a C++ version of this.
    - catnaroek 10y ago
      > functions are first class objects Programming languages have procedures, not functions. (Yes, even Haskell. Consider the possibility of divergence.) Functional programming is a style that: (0) Emphasizes values over physical object identities. (1) Emphasizes procedures that compute functions - mappings from values from a domain, into values from a codomain. (2) Discourages distinguishing between procedures that compute the same function. Functional languages are languages that facilitate and encourage functional programming. Does JavaScript? IMO, it doesn't even do (0) very well, which is a precondition for discussing whether it does (1) or (2) well. > garbage collector, persistent data structures Don't conflate “purely functional” with “persistent”. Purely functional programming can deal with ephemeral data structures just fine - using substructural types. In the other direction, there exist persistent data structures whose implementation internally uses imperative assignment. > powerful and flexible Those are desirable qualities in a language, but they are orthogonal to whether the language supports functional programming. > express all of these ideas in an accessible way JavaScript doesn't even make it easy to talk about structurally equal values. Since everything is mutable, the only notion of equality that the language will actually respect is equality of physical object identities. Without the ability to talk (soundly) about structural value equality, you can't formulate algebraic laws (e.g., the monoid or group laws), which is the basis for equational reasoning - one of the key benefits of programming in a functional style!
  - drewgross 10y ago
    You can have weakly/dynamically typed functional languages (most lisps for example) just like you can have strongly/statically typed procedural or OO languages, like Fortran or C++. Haskell the language also knows nothing at all about invariants, and the language will happily let you make something a Monad even if it doesn't obey the right laws. The culture and libraries of course take invariants quite seriously, but some aspects of the Javascript culture also take invariants quite seriously, like Promises for example.
    - catnaroek 10y ago
      > You can have weakly/dynamically typed functional languages (most lisps for example) I would call Racket a functional language. Common Lisp? Nope. > Haskell the language also knows nothing at all about invariants I'm aware. But I'm not talking about mechanically enforcing equational laws. I'm talking about the ability to state them in the first place. For this, you need a sufficiently rich value language, where, for example, the list [1,2,3] is always the list [1,2,3] regardless of where it resides in memory. In JavaScript, [1,2,3] isn't a list. It's an expression that, when evaluated, constructs an object whose initial value is one particular list, but its value at another point in time might be a different list. Furthermore, if you evaluate [1,2,3] twice, you get completely different objects. Although the objects are first-class, the list values aren't, so you can't (soundly) formulate any equational laws about lists. And object identities have an equational theory so weak (“everything is equal to itself and nothing else”) that it's completely useless.
      - clarus 10y ago
        I think in any cases you will have to define your notion of equality in the mathematical language you use. Indeed, even in Haskell, the equality operator returns a Haskell boolean but not a proposition, and cannot cope with equality on functions (I guess).
        catnaroek 10y ago
        > I think in any cases you will have to define your notion of equality in the mathematical language you use. The point is that I can reason about equality of ML and Haskell expressions in ML and Haskell themselves, with a few minor extensions (e.g., the usual laws of arithmetic, applied to pure `int` expressions), whereas reasoning about equivalence of JavaScript programs requires carrying out the entire reasoning process in a separate metalanguage. The latter is obviously far more tedious, which is why programmers have largely given up on actually reasoning about JavaScript programs, preferring testing as an alternative. > Indeed, even in Haskell, the equality operator returns a Haskell boolean but not a proposition, Equality testing (a runtime operation, only valid for types with decidable equality) is different from propositional equality (a type constructor on its own, which can be used on any type). See https://existentialtype.wordpress.com/2011/03/15/boolean-blindness/ https://existentialtype.wordpress.com/2011/03/15/boolean-bli... for details. Haskell doesn't have a propositional equality type constructor. > and cannot cope with equality on functions (I guess). Indeed, and, in any higher-order language, this is a feature, not a bug.

The reason they use JavaScript is because it's known by many and the examples can be tried without downloading/having an additional compiler. There are at least two dozen concepts on the list there - the value of illustrating new concepts for some with a known quantity far outweighs the downsides of having to start with a fresh environment. I will say though for the exact cases you mention, they probably should be clear why this isn't exactly the concept as described.

gaius 10y ago
Here you go: http://tryhaskell.org http://tryhaskell.org

Waterluvian 10y ago

It's definitely no Haskell. But if you wanted to do FP in JavaScript, it wouldn't be a painful ordeal, no? Well, ES6 and newer at least.

catnaroek 10y ago
Functional programming puts the static structure of a program at the forefront: types, invariants, equations relating inputs and outputs of processes, etc. JavaScript doesn't do this very well. In fact, even C++ does it better than JavaScript. Nobody would in their reasonable mind call C++ a functional language, right?
- justinhj 10y ago
  In Javascript functions are first class objects, there are closures, and higher order functions. Having a garbage collector makes it easier to implement persistent data structures. I've always thought that despite it's weird corners it's actually a powerful and flexible language. You can see that in the article, because in just a handful of lines of code it is able to express all of these ideas in an accessible way. I'd be interested to see a C++ version of this.
  - catnaroek 10y ago
    > functions are first class objects Programming languages have procedures, not functions. (Yes, even Haskell. Consider the possibility of divergence.) Functional programming is a style that: (0) Emphasizes values over physical object identities. (1) Emphasizes procedures that compute functions - mappings from values from a domain, into values from a codomain. (2) Discourages distinguishing between procedures that compute the same function. Functional languages are languages that facilitate and encourage functional programming. Does JavaScript? IMO, it doesn't even do (0) very well, which is a precondition for discussing whether it does (1) or (2) well. > garbage collector, persistent data structures Don't conflate “purely functional” with “persistent”. Purely functional programming can deal with ephemeral data structures just fine - using substructural types. In the other direction, there exist persistent data structures whose implementation internally uses imperative assignment. > powerful and flexible Those are desirable qualities in a language, but they are orthogonal to whether the language supports functional programming. > express all of these ideas in an accessible way JavaScript doesn't even make it easy to talk about structurally equal values. Since everything is mutable, the only notion of equality that the language will actually respect is equality of physical object identities. Without the ability to talk (soundly) about structural value equality, you can't formulate algebraic laws (e.g., the monoid or group laws), which is the basis for equational reasoning - one of the key benefits of programming in a functional style!
- drewgross 10y ago
  You can have weakly/dynamically typed functional languages (most lisps for example) just like you can have strongly/statically typed procedural or OO languages, like Fortran or C++. Haskell the language also knows nothing at all about invariants, and the language will happily let you make something a Monad even if it doesn't obey the right laws. The culture and libraries of course take invariants quite seriously, but some aspects of the Javascript culture also take invariants quite seriously, like Promises for example.
  - catnaroek 10y ago
    > You can have weakly/dynamically typed functional languages (most lisps for example) I would call Racket a functional language. Common Lisp? Nope. > Haskell the language also knows nothing at all about invariants I'm aware. But I'm not talking about mechanically enforcing equational laws. I'm talking about the ability to state them in the first place. For this, you need a sufficiently rich value language, where, for example, the list [1,2,3] is always the list [1,2,3] regardless of where it resides in memory. In JavaScript, [1,2,3] isn't a list. It's an expression that, when evaluated, constructs an object whose initial value is one particular list, but its value at another point in time might be a different list. Furthermore, if you evaluate [1,2,3] twice, you get completely different objects. Although the objects are first-class, the list values aren't, so you can't (soundly) formulate any equational laws about lists. And object identities have an equational theory so weak (“everything is equal to itself and nothing else”) that it's completely useless.
    - clarus 10y ago
      I think in any cases you will have to define your notion of equality in the mathematical language you use. Indeed, even in Haskell, the equality operator returns a Haskell boolean but not a proposition, and cannot cope with equality on functions (I guess).
      - catnaroek 10y ago
        > I think in any cases you will have to define your notion of equality in the mathematical language you use. The point is that I can reason about equality of ML and Haskell expressions in ML and Haskell themselves, with a few minor extensions (e.g., the usual laws of arithmetic, applied to pure `int` expressions), whereas reasoning about equivalence of JavaScript programs requires carrying out the entire reasoning process in a separate metalanguage. The latter is obviously far more tedious, which is why programmers have largely given up on actually reasoning about JavaScript programs, preferring testing as an alternative. > Indeed, even in Haskell, the equality operator returns a Haskell boolean but not a proposition, Equality testing (a runtime operation, only valid for types with decidable equality) is different from propositional equality (a type constructor on its own, which can be used on any type). See https://existentialtype.wordpress.com/2011/03/15/boolean-blindness/ https://existentialtype.wordpress.com/2011/03/15/boolean-bli... for details. Haskell doesn't have a propositional equality type constructor. > and cannot cope with equality on functions (I guess). Indeed, and, in any higher-order language, this is a feature, not a bug.