Fork me on GitHub
#clojuredesign-podcast
<
2019-12-06
>
mmeix19:12:25

Would transducers be an interesting subject for a podcast?

👍 8
sysarcher19:12:31

YES! I'm having some trouble getting the concepts around this

mmeix19:12:02

me too … so: moderators? 🙂

nate20:12:49

yes, yes they would be an interesting subject for an episode or three

neumann22:12:30

We're starting our journey in that direction starting with the episode we're about to release today!

mmeix13:12:45

great! thanks & looking forward to it!!

mmeix13:12:38

practical use cases of transducers would be something I would be interested in

mmeix16:12:55

… because I built some simple toy transducers, and informally testing them with (time (…)) didn’t show an advantage over functions - but I guess, this view on the matter ist too narrow

mmeix16:12:50

Thanks for the ongoing series “Reduce! Reduce! Reduce!” 🙂

neumann16:12:12

“Reduce! Reduce! Reduce!” That’s great! 🙂

neumann16:12:02

You’re welcome! And yes, we’re trying to keep it practical.

mmeix16:12:06

(and I really appreciate the mixture of humor and knowledge in the podcast!)

neumann16:12:06

Thanks! We love the banter too!

neumann16:12:41

Part of the challenge of keeping it practical is that reducers and transducers are a bit niche.

neumann16:12:38

They have certain performance benefits in certain cases.

mmeix16:12:57

And composability?

neumann16:12:31

and, with transducers specifically, you can use them for Clojure core stuff with really having to know (or care) how they work.

neumann16:12:21

Right. They are motivated by performance, but must be composible by necessity.

mmeix16:12:59

ah, so performance is the main motivation

neumann16:12:45

So composition is a big deal, but the whole point of both of them is to separate out the computation from the underlying representation of the collection.

neumann16:12:29

1. You won’t have intermediate lists 2. You cans parallelize (in some cases)

neumann16:12:51

But to get there, you have to be able to build up the transform.

mmeix16:12:21

Yes, just learning how now (endless REPLing 🙂

neumann16:12:22

So they have to be composible to allow you to do that.

mmeix16:12:51

Another question is, if the benefits are the same in clojurescript

neumann16:12:04

Hurray for REPLing!

mmeix16:12:19

[REPLing all the time]

neumann16:12:29

Reducing functions are useful in general. The reducers library doesn’t work in Clojurescript because it needs Java’s fork-join stuff.

neumann16:12:37

Transducers work everywhere.

mmeix16:12:58

(Yes, I meant transducers specifically)

neumann16:12:17

I haven’t personally done a lot of benchmarking, but the bigger the transform (having a lot of steps), the faster it should run vs the equivalent thread macro version using sequences.

neumann16:12:33

On both platforms.

mmeix16:12:03

because the intermediary colls are not needed/created, right?

neumann16:12:10

Right. It avoids those intermediate collections.

neumann16:12:06

I suppose it’s worth saying that transducers are a great fit if you have some problem domain where you have to assemble different transforms before processing a seq.

neumann16:12:37

I haven’t hit a concrete example of needing transducers yet, but I’m always looking for one.

neumann16:12:11

Using them with core.async channels is a great example, though.

neumann16:12:13

@U0510902N (so this conversation shows up in your threads)

mmeix16:12:00

I’m just working on a musical subject, where transformations are a major thing (this was the main motivation to try a LISP, because it seems so very appropriate, and that lead - happyily - to Clojure)

mmeix16:12:29

(core.async is another thing to learn, yes)

neumann16:12:50

Yes. We need to cover core.async too. We use it constantly.

neumann16:12:08

What music thing are you doing?

mmeix16:12:58

I’m a teacher for music theory in Vienna’s University for Music and Performing Arts

mmeix16:12:14

and I try to build learning tools

mmeix16:12:27

after “Reducers!” I will come back with questions on XML, because of this one: https://music-encoding.org

neumann16:12:34

How neat! It’s a pleasure to meet you!

neumann16:12:03

That initiative looks interesting too.

mmeix16:12:23

Yes, it is, and there is a companion project:

neumann16:12:48

I don’t know if I’d call processing XML “delightful”, but I think it’s about as delightful as possible in Clojure.

neumann16:12:26

Oh, that is seriously cool.

neumann16:12:39

Rendering out scores.

mmeix16:12:24

It’s the first usable music notation engine for the web; it understands music in the form of MEI XML

mmeix16:12:08

so this is the motivation (before I had tried to program such a thing with ClojureScript and SVG, but then found this engine

neumann16:12:17

Now I’m super curious. I’ll check them out later.

neumann16:12:48

It’s been a pleasure chatting this morning! I’ve got to run, but feel free to post here or in the main channel. I’ll be back later.

mmeix16:12:14

Great - thanks for the chat!

porkostomus09:12:24

Apologies for the late reply, but I'd love to help build an MEI parser because that would be super useful

mmeix13:12:50

Sounds great! Being curious: are you working on a similar project?

porkostomus03:12:34

Yes I thought it was pretty funny because I'm also building music training tools, but am still at the stage of attempting to write my own SVG rendering engine.

mmeix16:12:55

ah! that’s what I tried a couple of months ago!

mmeix16:12:57

(some things did work already)

mmeix10:12:24

@U8LB00QMD maybe we should look at both options: parsing and using MEI/Verovio and thinking about “Music-SVG”

porkostomus13:12:06

Sounds like a good idea. I set up a repo with a little starter app: https://github.com/porkostomus/mecca-mei Bonus: it uses transducers! I followed this article, and only had to change it to work in cljs: https://juxt.pro/blog/posts/xpath-in-transducers.html

mmeix18:12:38

wow! that was fast … 👍