Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Functional programming in JavaScript is an antipattern

hackernoon.com

Post reply on HN
Print view View original

61–70 of 92 posts

Re: Functional programming in JavaScript is an antipattern

#61

Post by weavie »

vog wrote: post #57
weavie wrote: post #36

Earlier quoted context omitted.

Elm is nice. Really really nice. It make it very intuitive and straightforward to write well architectured front end code. The compiler tells you straight away when something is wrong. I have recently started playing with Bucklescript and am really loving it. There is bucklescript-tea which is a port of the Elm architecture to OCaml. So not only do you get the goodness from Elm - intuitively well architectured applic…

Curious question: Why did you choose Typescript over Flow? Flow's type system is better designed. Also, Flow's annotations are really optional, as in: Generating JS from Flow means throwing away the annotations. Nothing else, no code generation at all.

I struggled to get Flow working on FreeBSD. Typescript worked straight away, so I just went with it.

Re: Functional programming in JavaScript is an antipattern

#62

Post by [deleted] »

vog wrote: post #57
weavie wrote: post #36

Earlier quoted context omitted.

Elm is nice. Really really nice. It make it very intuitive and straightforward to write well architectured front end code. The compiler tells you straight away when something is wrong. I have recently started playing with Bucklescript and am really loving it. There is bucklescript-tea which is a port of the Elm architecture to OCaml. So not only do you get the goodness from Elm - intuitively well architectured applic…

Curious question: Why did you choose Typescript over Flow? Flow's type system is better designed. Also, Flow's annotations are really optional, as in: Generating JS from Flow means throwing away the annotations. Nothing else, no code generation at all.

[deleted]

Re: Functional programming in JavaScript is an antipattern

#63

Post by cies »

vbezhenar wrote: post #33
coldtea wrote: post #30

Funny, but HN oldsters probably remember when functional programming wasn't at all tied to immutable data structures, and when Lisp and derivatives where considered enough functional programming, without every discussion of the topic requiring strictly requiring purity and immutability -- just first class functions, map, fold, and the like.

I was taught in university that functional programming means using functions as first-class-values, so function can get other function as a parameter. That's all. You can write functional code with assembler if you want. Immutability is just another design choice with its pros and cons.

> using functions as first-class-values

This is called higher order functions (HOF).

FP is a --in my humble opinion-- broader topic describes a certain programming style. HOF is one thing in there, but so are "function+data rather then classes" and "favor immutability".

In contrast the imperative programming style is not merely about "not having HOF" or "mutable variables all over the place".

Re: Functional programming in JavaScript is an antipattern

#64

Post by moron4hire »

callumlocke wrote: post #56

I hate the arrogance of announcing that thousands of developers' work is an antipattern. This post contains valid discussion of some of the shortcomings of FP-in-JS, and presents alternatives. That's fine. But everyone has their own priorities and tradeoffs. The downsides of adopting Clojurescript in my current situation would outweigh the benefits. > Clojure compiles to Javascript... So any Javascript job could be a…

Maybe it's arrogant to call out valid criticism as attacking the work of others, rather than just the paradigm.

Re: Functional programming in JavaScript is an antipattern

#65

Post by mannykannot »

vbezhenar wrote: post #33
coldtea wrote: post #30

Funny, but HN oldsters probably remember when functional programming wasn't at all tied to immutable data structures, and when Lisp and derivatives where considered enough functional programming, without every discussion of the topic requiring strictly requiring purity and immutability -- just first class functions, map, fold, and the like.

I was taught in university that functional programming means using functions as first-class-values, so function can get other function as a parameter. That's all. You can write functional code with assembler if you want. Immutability is just another design choice with its pros and cons.

The immutability comes in with the definition of 'function', which, in some circles, means something more specific than an arbitrary unit of code that is callable and which may or may not return a value. While neither 'function' nor 'functional programming' can be used in computing with any precision unless they are qualified, there is a distinct paradigm in which functions have no side-effects and are the only mechanism of elaboration.

Re: Functional programming in JavaScript is an antipattern

#66

Post by yomly »

tasuki wrote: post #25
marcus_holmes wrote: post #22

Earlier quoted context omitted.

True, you can write a language parser in any other language. That's not what I meant. I may have not been clear enough.

What did you mean?

If I had to guess: that macros in LISP are natural, owing to the fact that its syntax are all s-exps which make it parsing it easier than in other languages?

Re: Functional programming in JavaScript is an antipattern

#67

Post by yomly »

bestest wrote: post #12

In my opinion the top rated comment is right on point there: "I’d say that ImmutableJS is your anti-pattern here, not FP in JavaScript as a whole."

I agree - I use ImmutableJS in one of my projects and the pros vs cons are substantial - it's hard to keep track of when something is Immutable or not and it has been slowly infecting more and more of my codebase.

I would be interested in hearing strategies of mitigating this, my first step has been to let Immutable creep through the project, but adopt a convention of creating a layer through which guarantees JS output - anything that is logic related in my redux layer is Immutable, anything which is in my presentational react layer is JS.

The difficulty then, is at input points where I need to always remember to deal with nested data structures too.

It feels like a type checker would be of great use here to add additional guarantees about any data

Re: Functional programming in JavaScript is an antipattern

#68

Post by vog »

vog wrote: post #57
weavie wrote: post #36

Earlier quoted context omitted.

Elm is nice. Really really nice. It make it very intuitive and straightforward to write well architectured front end code. The compiler tells you straight away when something is wrong. I have recently started playing with Bucklescript and am really loving it. There is bucklescript-tea which is a port of the Elm architecture to OCaml. So not only do you get the goodness from Elm - intuitively well architectured applic…

Curious question: Why did you choose Typescript over Flow? Flow's type system is better designed. Also, Flow's annotations are really optional, as in: Generating JS from Flow means throwing away the annotations. Nothing else, no code generation at all.

To all those who downvoted this question: Do you care to elaborate?

Re: Functional programming in JavaScript is an antipattern

#70

Post by k__ »

zumu wrote: post #28

I've been doing FP in JavaScript fulltime for a few years now. I find it much easier than the OOP approach. My advice to the author is: choose ImmutableJS, Ramda, OR lodash. Don't choose all three. I think that is his anti-pattern. > I could be more productive if I didn’t have to wonder things like ... “Should I mutate this variable?” If you're doing FP the answer is likely 'No.'

Or?

Ramda doesn't even have the same functionality as Lodash.

Post reply on HN