5 ms·

Is there a reason why you can't do functional programming in JavaScript. Unless I'm mistaken, there isn't anything about JavaScript that explicitly prevents you

by lojack 11y ago

Is there a reason why you can't do functional programming in JavaScript. Unless I'm mistaken, there isn't anything about JavaScript that explicitly prevents you from doing functional programming. Even then, I think we all understand that the OP isn't trying to be strictly pure and is simply trying to explain the concepts in a manner that those used to imperative development can easily digest.

dozzie 11y ago
1. No pattern matching. Libraries can't help here, it's a syntactical and semantical issue. 2. No product types. You can emulate those, but it's awkward. 3. No recursion over lists. You can emulate this, but it's awkward. 4. It's difficult to write code that is efficient, yet is side-effects free. Good luck with prepending an element to a list. About emulation, you can emulate closures on Turing machine, though it doesn't make Turing machine a functional language. Lack of the aspect is simply lack of the aspect. And no, JS doesn't explicitly prevent functional programming (or rather, some aspects of it). It does so implicitly. > OP isn't trying to be strictly pure and is simply trying to explain the concepts in a manner that those used to imperative development can easily digest. It's like trying to show how to do OOP in C. It's a different paradigm than the primary of the host language, so any educational aspect will be severly diluted, to the point of being useless to anybody who doesn't already know functional programming.
- dragonwriter 11y ago
  > No recursion over lists. You can emulate this, but it's awkward. What do you mean by no recursion over lists? I mean, sure, lists aren't a core data type in JS (JS arrays aren't lists), so list operations aren't either, is that it?
  - dozzie 11y ago
    It's not "is that it". Single-linked lists of specific characteristics (access times, construction times and stuff like that) are one of the few core elements of functional programming.
- dllthomas 11y ago
  "2. No product types. You can emulate those, but it's awkward." Do you mean sum types?
- lojack 11y ago
  > It's like trying to show how to do OOP in C. Actually, I'd think that would be a super valuable to a C developer. Learning to implement OOP patterns in C would provide practical patterns that can help architect C software. For non-C developers, it'd also provide fundamentals of how OOP actually works. C developers have been implementing OOP patterns since well before C++ existed. There's lots of resources, and practical examples of this. GObject provides an object system used by both Gnome and GTK. Check out "Object-Oriented Programming With ANSI-C" for a book on the subject.
  - ectoplasm 11y ago
    That GObject stuff is really complicated. You can get pretty far doing simple OOP in C without inheritance and just containment.
  - stream_fusion 11y ago
    It's arguably faster and of more benefit to learn OO in an OO language, and then work backwards to figure out ways to implement those strategies in C (eg. polymorphism using structs with arrays of function pointers, or win32 send_message constructs). It's similar with functional programming. Figuring out folds, pattern matching and monads is probably easiest in haskell or Ocaml/F#. The decision to apply those techniques in other languages without native support then becomes a judgement about the benefit.
    - deleted 11y ago
      [deleted]
- eropple 11y ago
  > It's like trying to show how to do OOP in C. It's a different paradigm than the primary of the host language, so any educational aspect will be severly diluted Says who? I've taught OOP, as a concept, to people using C. It's incredibly obvious when you see it written--once you've implemented inheritance through structural composition, it's strikingly easy to reason about how traditionally OO languages handle their object models. (This is basically what GTK does!)
  - candu 11y ago
    +1. I'd argue teaching OOP in C is better than teaching it in <insert OOP language here>, as then you can build OOP from first principles. Otherwise, OOP is just this black box that has "you know, classes and objects and stuff". Similarly: you can build a simple LISP in Javascript. You can write an event loop in C. You can implement Hindley-Milner type inference in Python. These are all great exercises in understanding exactly what these components of different programming languages do :)
- warfangle 11y ago
  1. Lisp doesn't have built in pattern matching, either. But, just like Lisp, there are libraries out there for it[0]. 2. Would probably make more sense if it were a statically typed language. Don't most dynamically typed FPL need to emulate this? 3. Got an example of it being awkward that isn't helped with ES2015? 4. (item, list) => [item].concat(list) [0]: https://www.npmjs.com/package/pattern-match https://www.npmjs.com/package/pattern-match
- wwweston 11y ago
  > It's like trying to show how to do OOP in C. Pretty much how I learned OOP: http://www.amazon.com/Class-Construction-Object-Oriented-Programming-Fundamentals/dp/0136301045 It can be nice to have language support, but it can be nice to learn a paradigm primarily as a way of organizing your program.
sklogic 11y ago
Until ES6 is widely adopted, there is no correct tail call handling guarantee, which bars using purely functional programming.

by lojack 11y ago

dozzie 11y ago

1. No pattern matching. Libraries can't help here, it's a syntactical and semantical issue. 2. No product types. You can emulate those, but it's awkward. 3. No recursion over lists. You can emulate this, but it's awkward. 4. It's difficult to write code that is efficient, yet is side-effects free. Good luck with prepending an element to a list. About emulation, you can emulate closures on Turing machine, though it doesn't make Turing machine a functional language. Lack of the aspect is simply lack of the aspect. And no, JS doesn't explicitly prevent functional programming (or rather, some aspects of it). It does so implicitly. > OP isn't trying to be strictly pure and is simply trying to explain the concepts in a manner that those used to imperative development can easily digest. It's like trying to show how to do OOP in C. It's a different paradigm than the primary of the host language, so any educational aspect will be severly diluted, to the point of being useless to anybody who doesn't already know functional programming.

dragonwriter 11y ago
> No recursion over lists. You can emulate this, but it's awkward. What do you mean by no recursion over lists? I mean, sure, lists aren't a core data type in JS (JS arrays aren't lists), so list operations aren't either, is that it?
- dozzie 11y ago
  It's not "is that it". Single-linked lists of specific characteristics (access times, construction times and stuff like that) are one of the few core elements of functional programming.
dllthomas 11y ago
"2. No product types. You can emulate those, but it's awkward." Do you mean sum types?
lojack 11y ago
> It's like trying to show how to do OOP in C. Actually, I'd think that would be a super valuable to a C developer. Learning to implement OOP patterns in C would provide practical patterns that can help architect C software. For non-C developers, it'd also provide fundamentals of how OOP actually works. C developers have been implementing OOP patterns since well before C++ existed. There's lots of resources, and practical examples of this. GObject provides an object system used by both Gnome and GTK. Check out "Object-Oriented Programming With ANSI-C" for a book on the subject.
- ectoplasm 11y ago
  That GObject stuff is really complicated. You can get pretty far doing simple OOP in C without inheritance and just containment.
- stream_fusion 11y ago
  It's arguably faster and of more benefit to learn OO in an OO language, and then work backwards to figure out ways to implement those strategies in C (eg. polymorphism using structs with arrays of function pointers, or win32 send_message constructs). It's similar with functional programming. Figuring out folds, pattern matching and monads is probably easiest in haskell or Ocaml/F#. The decision to apply those techniques in other languages without native support then becomes a judgement about the benefit.
  - deleted 11y ago
    [deleted]
eropple 11y ago
> It's like trying to show how to do OOP in C. It's a different paradigm than the primary of the host language, so any educational aspect will be severly diluted Says who? I've taught OOP, as a concept, to people using C. It's incredibly obvious when you see it written--once you've implemented inheritance through structural composition, it's strikingly easy to reason about how traditionally OO languages handle their object models. (This is basically what GTK does!)
- candu 11y ago
  +1. I'd argue teaching OOP in C is better than teaching it in <insert OOP language here>, as then you can build OOP from first principles. Otherwise, OOP is just this black box that has "you know, classes and objects and stuff". Similarly: you can build a simple LISP in Javascript. You can write an event loop in C. You can implement Hindley-Milner type inference in Python. These are all great exercises in understanding exactly what these components of different programming languages do :)
warfangle 11y ago
1. Lisp doesn't have built in pattern matching, either. But, just like Lisp, there are libraries out there for it[0]. 2. Would probably make more sense if it were a statically typed language. Don't most dynamically typed FPL need to emulate this? 3. Got an example of it being awkward that isn't helped with ES2015? 4. (item, list) => [item].concat(list) [0]: https://www.npmjs.com/package/pattern-match https://www.npmjs.com/package/pattern-match
wwweston 11y ago
> It's like trying to show how to do OOP in C. Pretty much how I learned OOP: http://www.amazon.com/Class-Construction-Object-Oriented-Programming-Fundamentals/dp/0136301045 It can be nice to have language support, but it can be nice to learn a paradigm primarily as a way of organizing your program.

sklogic 11y ago

Until ES6 is widely adopted, there is no correct tail call handling guarantee, which bars using purely functional programming.