Magical, Mystical JavaScript Transducers • Hacker News Board

Re: Magical, Mystical JavaScript Transducers

#41

Post by ElFitz » Sat, Jun 29, 2019, 2:28 PM UTC

ur-whale wrote: post #28

cousin_it wrote: post #15

Earlier quoted context omitted.

For me it's the other way around. A for loop is a general purpose solution that changes continuously with the problem: whenever I need to gather some extra data, just add some hairs to the for loop. The time complexity is obvious, so is the space complexity (how much data is in memory at any given time), and it's easy to pause and debug. But if you have a bunch of FP combinators and recursion schemas, when the proble…

100% agree with you. I've always been uneasy with FP-style coding for three reasons: - you have strictly no idea how your code will be evaluated by the CPU. Some people love that aspect. It makes me immensely queasy. I might be a control freak. - as much as I love the idea an cleanliness of composing functions, having to abandon mutability for that is way too hefty a price to pay. There are situations where overwriti…

Totally beside the point (which I agree with), but your bullet list renders horribly on mobile devices (lengthy horizontal scrolls >.<')

Re: Magical, Mystical JavaScript Transducers

#42

Post by darepublic » Sat, Jun 29, 2019, 2:29 PM UTC

blunte wrote: post #30

It's so depressing that JavaScript is growing in use, especially when I see articles like TFA. I hate that momentum has allowed a clusterf*ck of a language to become the standard for front end and now one of the top 3 for back-end. Here's Clojure's explanation of transducers: https://clojure.org/reference/transducers The whole concept is explained more clearly and with far fewer words and code; and the final result i…

I love js and was into it before it was cool. Only sad thing is the momentum to make it typed

Re: Magical, Mystical JavaScript Transducers

#43

Post by talkingtab » Sat, Jun 29, 2019, 2:56 PM UTC

The concept of transducers - I think of it is a conveyor belt of functionality - is great and I periodically run into problems where having an easy to use JavaScript transducer system would be great. Right now I'm processing sets of markdown files, reading shortcodes from them, generating html, applying more shortcodes, adding variables and then using mustache ... It is just a conveyor belt, but with lots of little odds and ends - perfect for a transducer, especially with async.

Ramada looks interesting ...

Re: Magical, Mystical JavaScript Transducers

#44

Post by tomxor » Sat, Jun 29, 2019, 2:59 PM UTC

  function isFound(item) {
      return item.found;
  };

Every time I see this pattern in code (one line accessors) I have a sinking feeling in my stomach in expectation of whats to come.

This is the best example of a forced pattern.

Re: Magical, Mystical JavaScript Transducers

#45

Post by mrgriffin » Sat, Jun 29, 2019, 3:16 PM UTC

cousin_it wrote: post #20

aurelwu wrote: post #19

Earlier quoted context omitted.

That seems to be such a basic task. Please take it not as me not believing it but could you provide some source about there not being a known O(N) solution for that problem, I'd like to know what the hurdles are and why there might be no solution at all or why finding one is so difficult. (I tried googling it but failed to find something useful)

The hurdle is that when you're going through the input, you need to update the output out of order. An imperative array can be updated out of order in O(1) time, but FP data structures can't do that. Strict vs lazy doesn't seem to help. I have no source, but I've given this problem to some strong Haskell programmers and they couldn't solve it (without using escape hatches like ST).

As a professional Haskeller who solves numerical computation problems I wouldn't call ST an escape hatch. You're right that I can't think of a "pure" way to compute a histogram, but I doubt anyone uses Haskell specifically to prevent all mutations but rather to carefully control where mutation can occur[1]. I'd wager referential transparency is "good enough purity" for almost all tastes.

[1] Of course we have plenty of other reasons to use it, but I digress.

Re: Magical, Mystical JavaScript Transducers

#46

Post by ur-whale » Sat, Jun 29, 2019, 3:43 PM UTC

ElFitz wrote: post #41

ur-whale wrote: post #28

Earlier quoted context omitted.

100% agree with you. I've always been uneasy with FP-style coding for three reasons: - you have strictly no idea how your code will be evaluated by the CPU. Some people love that aspect. It makes me immensely queasy. I might be a control freak. - as much as I love the idea an cleanliness of composing functions, having to abandon mutability for that is way too hefty a price to pay. There are situations where overwriti…

Totally beside the point (which I agree with), but your bullet list renders horribly on mobile devices (lengthy horizontal scrolls >.<')

I have indeed heard of these "mobile devices" you speak of :p but for some weird HN algorithmic reason, I can't edit my comment anymore ...

Re: Magical, Mystical JavaScript Transducers

#47

Post by tomxor » Sat, Jun 29, 2019, 4:10 PM UTC

cousin_it wrote: post #15

southerndrift wrote: post #10

Earlier quoted context omitted.

Yours is the obvious solution but the problem is a simple example to help people understand the more complex idea of transducers. It's for situations where the code inside the for loop is so complex that it would be nice to organize it with functional programming principals. The problem with functional programming is that the obvious approach is not efficient since it passes the array several times. So the goal is to…

For me it's the other way around. A for loop is a general purpose solution that changes continuously with the problem: whenever I need to gather some extra data, just add some hairs to the for loop. The time complexity is obvious, so is the space complexity (how much data is in memory at any given time), and it's easy to pause and debug. But if you have a bunch of FP combinators and recursion schemas, when the proble…

> just add some hairs to the for loop. The time complexity is obvious, so is the space complexity (how much data is in memory at any given time)

Exactly, when refactoring code the first thing I do is remove all the boxes, create a huge monolithic procedure, then I can see all the inefficiencies, optimise and simplify it, then break it into better fitting boxes (if necessary).

I don't follow the lingo for all the patterns, but ultimately they are usually just different ways of wrapping up things in boxes. I think they are wooden bullets, the most important thing is to not make boxes too quickly, it should be the very last thing you do after figuring out what the code needs to in it's entirety holistically.

I think the bane of most software complexity is actually people being too scared of taming large contexts, so instead they wrap themselves in a hell of spaghetti boxes, just deferring issues and creating inefficiency and obscurity.

Re: Magical, Mystical JavaScript Transducers

#48

Post by chris_st » Sat, Jun 29, 2019, 10:03 PM UTC

agumonkey wrote: post #31

chris_st wrote: post #25

Earlier quoted context omitted.

Downside: Still going over the array multiple times.

fair point, in js it will, in other languages that idiom gets deforested into a single pass though

Cool, which languages do this?

Re: Magical, Mystical JavaScript Transducers

#49

Post by cofunctor » Sat, Jun 29, 2019, 10:30 PM UTC

chris_st wrote: post #48

agumonkey wrote: post #31

Earlier quoted context omitted.

fair point, in js it will, in other languages that idiom gets deforested into a single pass though

Cool, which languages do this?

This ought to work with any lazy language (or lazy data structure), which is one of the huge benefits of laziness for FP.

Re: Magical, Mystical JavaScript Transducers

#50

Post by Veedrac » Sun, Jun 30, 2019, 10:05 PM UTC

I recommend ignoring transducers unless you know you really need push-based iteration, which probably isn't the case. Generators are generally a superior approach otherwise.