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

31–40 of 92 posts

Re: Functional programming in JavaScript is an antipattern

#31

Post by seangrogg »

keymone wrote: post #10
marcus_holmes wrote: post #5

I like Javascript. As a language. It's fun, enjoyable, and I'm productive in it. There I said it. I don't mind exploring interesting avenues like immutability, jsx, typescript, declarative or functional styles. I like that JS has enough flexibility to make all of these possible. I get the fatigue about the endless stream of new frameworks, libraries, approaches, and "new hotness". But I became much more relaxed about…

unfortunately this approach does not scale past single developer or multiple klocs of code unless you're really disciplined, but then wouldn't that cognitive effort be better spent elsewhere?

I've seen multiple klocks of code written in Java and C that are taking minutes to handle database operations, unable to process parallel network requests, and choking on errors. Watching new features get added is exciting in the same way it's ensorcelling to watch someone assemble a house of cards.

I'd love a tool that enabled me to spend my cognitive currency how I want to, but so far all I've found are tools that have disguised their expenses in new and interesting ways, like tranches of a collateralized debt obligation.

Re: Functional programming in JavaScript is an antipattern

#32

Post by keymone »

seangrogg wrote: post #31
keymone wrote: post #10

Earlier quoted context omitted.

unfortunately this approach does not scale past single developer or multiple klocs of code unless you're really disciplined, but then wouldn't that cognitive effort be better spent elsewhere?

I've seen multiple klocks of code written in Java and C that are taking minutes to handle database operations, unable to process parallel network requests, and choking on errors. Watching new features get added is exciting in the same way it's ensorcelling to watch someone assemble a house of cards. I'd love a tool that enabled me to spend my cognitive currency how I want to, but so far all I've found are tools that…

i don't think i disagree with you and (i think) neither does the author. argument (as i understand it) is that rather than piling on features that don't really fit and have complex interference you could use a better tool.

Re: Functional programming in JavaScript is an antipattern

#33

Post by vbezhenar »

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.

Re: Functional programming in JavaScript is an antipattern

#34

Post by bonesss »

cies wrote: post #27

>Functional programming in JavaScript is an antipattern The article then shows ClojureScript as an alternative. In the comment section Ken Aguilar mentions two other alternatives: PureScript and Elm. But there are more! Bloomberg's BuckleScript (which is OCaml; possible used on onjunction with Facebook's Reason), GHCJS (Haskell), are two other FP langs that compile to JS. These two have the added bonus of being stron…

To add to the list:

F# has a JS transpiler via fable http://fable.io/ (Elm and its architecture has even been recreated to a degree - https://github.com/AnthonyLloyd/Elm)

Re: Functional programming in JavaScript is an antipattern

#35

Post by js8 »

andriesm wrote: post #24

The author asks WHY hasn't clojure caught on if it is great. I think I have a better answer than his conclusion that it aint popular because people shun things that aren't popular. (1) coding when EVERYTHING is immutable by default is a royal pain in the arse. (2) Coding directly in Abstract Syntax Trees is not pretty, there is a reason why most programming languages don't look like lisp.

I have a different theory about this. Most people are practical and don't like too much abstractions. So any language that lets you make abstractions, no matter how beautiful it is internally, and no matter how useful they can be in coding, such as Lisp, Forth, Scheme, Haskell, Clojure.. (you name it) will not be popular, sadly.

Weird thing is that functions are, for the most part, also a tool to make abstractions, but for some reason, the perception of them is different.

I came to this conclusion after discussions with people I know who don't like these languages, and I now think it comes down to this.

Re: Functional programming in JavaScript is an antipattern

#36

Post by weavie »

cies wrote: post #27

>Functional programming in JavaScript is an antipattern The article then shows ClojureScript as an alternative. In the comment section Ken Aguilar mentions two other alternatives: PureScript and Elm. But there are more! Bloomberg's BuckleScript (which is OCaml; possible used on onjunction with Facebook's Reason), GHCJS (Haskell), are two other FP langs that compile to JS. These two have the added bonus of being stron…

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 applications, but you can do it in a language that can be used everywhere - not just on the server.

Another worth mentioning is Typescript. Having discovered the joy of types through Elm and Bucklescript it was a real pain having to go back to maintain a fairly large javascript code base. My initial thought was to rewrite the whole thing in OCaml, but that would take months if not years. Instead I have started moving it across to Typescript. No code needs rewriting, I can just slowly one file at a time start adding typing information in. I have found a lot of subtle bugs and bugs I knew existed but was tearing my hair out about just easily presented themselves via compiler messages.

I will never go back to raw javascript again.

Re: Functional programming in JavaScript is an antipattern

#37

Post by js8 »

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 think the reason is rise in CPU power - immutability has a processing cost, but it makes things easier for programmers. This is a general trend in programming languages over decades - higher abstraction (easier for programmers) but harder for compilers to optimize.

For example, Common Lisp has two versions of list functions that modify list - one that returns a copy and another that returns mutated original list. (By the way, Paul Graham in his On Lisp, which is from 1993, mentions that functional programming style means that function doesn't modify its arguments and rather returns a copy.) Because once upon a time, the difference actually mattered. Today, mostly it doesn't.

Re: Functional programming in JavaScript is an antipattern

#38

Post by nidu »

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.'

Agree with this one. Reading article i though "Why don't you just drop ImmutableJS in favor of pure js collections with lodash/fp?". I felt the same when were using ImmutableJS. Two collection libraries across the app is very inconvenient. One could build entire infrastructure with ImmutableJS and restrict native collections to only system boundaries, but in js you usually befriend a lot of libs which makes it complex.

Re: Functional programming in JavaScript is an antipattern

#39

Post by pvg »

memracom wrote: post #19

What has happened to Javascript is the same thing that happened to other fundamental high-level languages before them. It has changed from a high-level language to an assembly language just like C and Java. Of course you canb choose to live in the past and keep on hand-rolling your Javascript just like others do with C and Java, but the world has changed. In today's world we write our code in a high-level language an…

It has changed from a high-level language to an assembly language just like C and Java.

That hasn't happened to either C or Java.

Re: Functional programming in JavaScript is an antipattern

#40

Post by cousin_it »

memracom wrote: post #19

What has happened to Javascript is the same thing that happened to other fundamental high-level languages before them. It has changed from a high-level language to an assembly language just like C and Java. Of course you canb choose to live in the past and keep on hand-rolling your Javascript just like others do with C and Java, but the world has changed. In today's world we write our code in a high-level language an…

> No matter how much you like C or Java or Javascript, it is always faster, more efficient and more reliable to write in a truly high-level language that incorporates the best knowledge of the latest research in Computer Science.

Latest research? Clojure is a Lisp family language, JS is an Algol family language. Both Lisp and Algol are from the sixties. Algol family is just more popular, so when people encounter Lisp family for the first time, they think it's "new".

Post reply on HN