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

Learn Functional Programming Design from Redux

pitayan.com

Post reply on HN
Print view View original

31–40 of 48 posts

Re: Learn Functional Programming Design from Redux

#31

Post by adamkl »

Osiris wrote: post #12
yakshaving_jgt wrote: post #3

In my experience learning, teaching, and watching other people learn FP, it's far easier to learn FP with a language which is actually designed for it, e.g. , Elm. JavaScript isn't that. It carries too much legacy baggage. Too many gotchas; too many pointy bits. It's also just super noisy. There's a reason why someone had to write The Good Parts . I don't buy the idea either that modern JavaScript is somehow devoid o…

This is my experience as well. I had a co-worker that really pushed for FP in JavScript using Ramda.js. the principles were appealing, but because JavaScript doesn't have native syntax for many of the principles like pattern matching, you end up with hard to read code that's a bunch of nested arrays or chains wrapped in helper functions like "compose([fn1, fn2])(data)". I later tried to learn F# and while the syntax…

I'm actually thinking about putting together a series of posts on the topic of "Full-stack ClojureScript for JavaScript developers". I've heard ClojureScript described (from a functional programming standpoint) as "JavaScript, but without the stupid parts", as it basically gives you the benefits of Ramda.js + Immutable.js without the headaches of making those libraries play nicely with native JavaScript. It also doesn't veer too far into the theoretical (monads, category theory, etc) so it would make for an easier transition when coming from JavaScript (you can even throw exceptions if you want).

I became a Clojure fan-boy over the course of the last year but one issue that seems to keep popping up when I discuss it with my JavaScript/Node.js co-workers is "Clojure runs on the JVM? Not interested".

Setting aside the technical validity of that opinion (JVM vs. Node.js), it made me wonder if there might be more interest in Clojure from the JavaScript world if they knew they could use ClojureScript for both the front-end and the back-end (on Node.js).

Re: Learn Functional Programming Design from Redux

#32

Post by nicoburns »

Osiris wrote: post #12
yakshaving_jgt wrote: post #3

In my experience learning, teaching, and watching other people learn FP, it's far easier to learn FP with a language which is actually designed for it, e.g. , Elm. JavaScript isn't that. It carries too much legacy baggage. Too many gotchas; too many pointy bits. It's also just super noisy. There's a reason why someone had to write The Good Parts . I don't buy the idea either that modern JavaScript is somehow devoid o…

This is my experience as well. I had a co-worker that really pushed for FP in JavScript using Ramda.js. the principles were appealing, but because JavaScript doesn't have native syntax for many of the principles like pattern matching, you end up with hard to read code that's a bunch of nested arrays or chains wrapped in helper functions like "compose([fn1, fn2])(data)". I later tried to learn F# and while the syntax…

Do you have a link to the pattern matching proposal? IMO if you added pattern matching and made everything (blocks, if-else, switch statements, etc) expressions then JavaScript would be pretty decent for writing in a functional style.

Re: Learn Functional Programming Design from Redux

#33

Post by SwanandK »

adamkl wrote: post #31
Osiris wrote: post #12

Earlier quoted context omitted.

This is my experience as well. I had a co-worker that really pushed for FP in JavScript using Ramda.js. the principles were appealing, but because JavaScript doesn't have native syntax for many of the principles like pattern matching, you end up with hard to read code that's a bunch of nested arrays or chains wrapped in helper functions like "compose([fn1, fn2])(data)". I later tried to learn F# and while the syntax…

I'm actually thinking about putting together a series of posts on the topic of "Full-stack ClojureScript for JavaScript developers". I've heard ClojureScript described (from a functional programming standpoint) as "JavaScript, but without the stupid parts", as it basically gives you the benefits of Ramda.js + Immutable.js without the headaches of making those libraries play nicely with native JavaScript. It also does…

Looking forward to those articles!

Re: Learn Functional Programming Design from Redux

#34

Post by mhaberl »

yakshaving_jgt wrote: post #29
mhaberl wrote: post #26

Earlier quoted context omitted.

const value can be redeclared in a different scope - but to be very precise; this is not really question of (im)mutability - it is a different value inside a scope, the original value is not changed. Other thing is (and I believe this is what the OP is asking you) - if you say: const a = 1; a will always be 1 (inside the scope). Sure if you say: const o = { a: 1}; you can change the value of a inside the o, but the o…

It's not useful to describe the behaviour of "pointers" in JavaScript, because JavaScript does not have pointers[0]. I think the article I linked to earlier was already sufficiently unambiguous. To clarify once again: If you can mutate a value, then the value is mutable. Mutable means it is not immutable. The `const` keyword in JavaScript does not give you an immutable value. [0]: https://stackoverflow.com/a/17382443…

I used the terminology that the OP used to be more clear. Pointer or reference in this context is not so significant as is that 'const' is marking the reference (OP used "pointer") as a constant, and not the value that is referring to.

Point the OP was getting at: 'const' gives you an immutable reference to a mutable value because it is a modifier for the reference and not the value.

Yes, the article you linked was unambiguous, but for another question :)

As i said, a lot of langugaes (I don't know any that behaves differently) uses the const/final modifiers in this way.

In my experience with people that are just learning how to code, it is a more efficient to point out what is the 'const' modifier making a constant of, than pointing out what it does not do, because the latter sometimes sends a message that the 'const' is useless as it 'does not do anything'.

Re: Learn Functional Programming Design from Redux

#35

Post by agumonkey »

yakshaving_jgt wrote: post #3

In my experience learning, teaching, and watching other people learn FP, it's far easier to learn FP with a language which is actually designed for it, e.g. , Elm. JavaScript isn't that. It carries too much legacy baggage. Too many gotchas; too many pointy bits. It's also just super noisy. There's a reason why someone had to write The Good Parts . I don't buy the idea either that modern JavaScript is somehow devoid o…

even with es6 ?

Re: Learn Functional Programming Design from Redux

#36

Post by diegof79 »

While I use Redux, and I like the simplicity of the single application state and the reducer function. I don't see it as a good example of FP or even JavaScript.

The problem with Redux is that it takes many patterns that make sense in languages like Haskell or Elm but are not idiomatic in JS. For example, action types and the usual reducer switch statement is easier to write and extend in Haskell.

And is not idiomatic JavaScript either. It always baffles me that an action dispatch is a way of doing a method dispatch (and yes I know that unlike a method dispatch an action can be persisted, and broadcasted). But if you compare the boilerplate and concepts introduced by a simple action dispatch (action creator, action type, payload, thunk, middleware) with a simple method call, and you look at the benefits (late binding with the state, persistence)... I wonder why solutions like Zustand didn't come up before.

(note, I wrote state management code similar to Zustand for my personal projects, but one of the reasons to continue using Redux is that getting the Context updates right is hard... a problem solved by React-Redux with addition of nice tooling and collaboration from core React devs. As soon React adds fine-grained context state updates the reasons to continue using Redux for me are low).

Re: Learn Functional Programming Design from Redux

#38

Post by otsukare »

adamkl wrote: post #31
Osiris wrote: post #12

Earlier quoted context omitted.

This is my experience as well. I had a co-worker that really pushed for FP in JavScript using Ramda.js. the principles were appealing, but because JavaScript doesn't have native syntax for many of the principles like pattern matching, you end up with hard to read code that's a bunch of nested arrays or chains wrapped in helper functions like "compose([fn1, fn2])(data)". I later tried to learn F# and while the syntax…

I'm actually thinking about putting together a series of posts on the topic of "Full-stack ClojureScript for JavaScript developers". I've heard ClojureScript described (from a functional programming standpoint) as "JavaScript, but without the stupid parts", as it basically gives you the benefits of Ramda.js + Immutable.js without the headaches of making those libraries play nicely with native JavaScript. It also does…

I think I'm like your co-workers, I'm really interested in Clojure, but admittably have that (probably unreasonable) JVM aversion. Do you mind sharing why I shouldn't?

Re: Learn Functional Programming Design from Redux

#39

Post by zarathustreal »

mhaberl wrote: post #34
yakshaving_jgt wrote: post #29

Earlier quoted context omitted.

It's not useful to describe the behaviour of "pointers" in JavaScript, because JavaScript does not have pointers[0]. I think the article I linked to earlier was already sufficiently unambiguous. To clarify once again: If you can mutate a value, then the value is mutable. Mutable means it is not immutable. The `const` keyword in JavaScript does not give you an immutable value. [0]: https://stackoverflow.com/a/17382443…

I used the terminology that the OP used to be more clear. Pointer or reference in this context is not so significant as is that 'const' is marking the reference (OP used "pointer") as a constant, and not the value that is referring to. Point the OP was getting at: 'const' gives you an immutable reference to a mutable value because it is a modifier for the reference and not the value. Yes, the article you linked was u…

Yes precisely this. The person above you might be unaware of the fact but JavaScript (and all other languages that I’m aware of) does indeed make use of pointers albeit indirectly. When you use const and initialize it as a JS object the value in the variable is a “pointer” (call it what you will, it points to or references a memory location) and is indeed immutable. You cannot change the value of the variable. You can, however, change the value of a different variable (such as a property of the object it references) but at that point you’re not longer talking about the same variable. So in a sense “no, it’s not immutable” but in another sense, yes it actually is. It makes the most sense to talk about the value that the variable holds rather than the object it references when speaking of immutability because there also exist primitive values in JS that are immutable in exactly the same way, except they are not references (or pointers) they are just values. So instead of needing to keep the additional “gotcha, object references are immutable but the properties of that object are not frozen” you can simply understand the literal semantics. Of course that is just my personal opinion

Re: Learn Functional Programming Design from Redux

#40

Post by adamkl »

otsukare wrote: post #38
adamkl wrote: post #31

Earlier quoted context omitted.

I'm actually thinking about putting together a series of posts on the topic of "Full-stack ClojureScript for JavaScript developers". I've heard ClojureScript described (from a functional programming standpoint) as "JavaScript, but without the stupid parts", as it basically gives you the benefits of Ramda.js + Immutable.js without the headaches of making those libraries play nicely with native JavaScript. It also does…

I think I'm like your co-workers, I'm really interested in Clojure, but admittably have that (probably unreasonable) JVM aversion. Do you mind sharing why I shouldn't?

The JVM is an excellent general purpose, multi-threaded runtime, with a large ecosystem of open source libraries, and its well suited to many types of "back-end" workloads, which is why it was the initial target for Clojure back in 2006/2007. Clojure's great interop with its host platform made it easy for people to get up and running while leveraging all the existing Java libraries they were used to.

The JVM is still a great choice for all those reasons, but its a little heavier than Node.js which specializes in IO bound use cases (i.e. the back-end-for-front-ends that sit between the browser and the heavyweight back-end systems). Node.js is also probably better suited for smaller services, lambdas, and other light-weight scenarios (IOT?).

I'm interested in promoting a full-stack approach to ClojureScript because the JavaScript/Node.js ecosystem is everything that the Java ecosystem was 15 years ago. It has lots of developers, lots of libraries, and a "bad" language. And by sticking with Node.js, its one less hurdle for JavaScript developers to clear when learning ClojureScript. They still get to use all the same libraries they did before (via ClojureScript's great interop), and the runtime characteristics they are used to. Plus, if they then decide to start looking at Clojure on the JVM in the future, they will have already learned the language.

Post reply on HN