Clojure 1.7 is now available • Hacker News Board

Re: Clojure 1.7 is now available

#11

Post by birdsbolt » Tue, Jun 30, 2015, 3:28 PM UTC

icey wrote: post #9

It would be great to see a refactor of some code using transducers to get a better sense of what they're useful for. From an abstraction standpoint, I can see the attraction; but I am having a tough time imagining how it would improve code in practice.

It improves the performance by fusing some of the operations doing them in one pass instead of multiple passes, and it does so generically - operations are composed regardless of the source, and the implementation isn't looking at the type of the source at all.

I believe one of the arguments was also that these couldn't be written in statically typed languages. Although, I do not know if this turned out to be true.

Re: Clojure 1.7 is now available

#12

Post by astine » Tue, Jun 30, 2015, 3:32 PM UTC

27182818284 wrote: post #2

>Transducers are composable algorithmic transformations. They are independent from the context of their input and output sources and specify only the essence of the transformation in terms of an individual element. Because transducers are decoupled from input or output sources, The biggest thing holding me back from learning Clojure is that I fear it will take me a decade to become remotely competent in it.

That's not a very plain-language description of transducers. Transducers are functions which can be applied to any sort of collection or sequence. You can use then to do something like filter a collection or an input stream with the same code. They are basically just a way to make things like 'map' and 'filter' work on datatypes other than sequences, such as streams or channels.

http://blog.cognitect.com/blog/2014/8/6/transducers-are-comi...

Re: Clojure 1.7 is now available

#13

Post by jarcane » Tue, Jun 30, 2015, 3:35 PM UTC

27182818284 wrote: post #2

>Transducers are composable algorithmic transformations. They are independent from the context of their input and output sources and specify only the essence of the transformation in terms of an individual element. Because transducers are decoupled from input or output sources, The biggest thing holding me back from learning Clojure is that I fear it will take me a decade to become remotely competent in it.

honestly, I use Clojure 1.7 for work every day and I don't even know what a transducer is.

It's easy to overstate the necessity of advanced features, ones very few programmers probably actually use.

Re: Clojure 1.7 is now available

#14

Post by coolsunglasses » Tue, Jun 30, 2015, 3:39 PM UTC

birdsbolt wrote: post #11

icey wrote: post #9

It would be great to see a refactor of some code using transducers to get a better sense of what they're useful for. From an abstraction standpoint, I can see the attraction; but I am having a tough time imagining how it would improve code in practice.

It improves the performance by fusing some of the operations doing them in one pass instead of multiple passes, and it does so generically - operations are composed regardless of the source, and the implementation isn't looking at the type of the source at all. I believe one of the arguments was also that these couldn't be written in statically typed languages. Although, I do not know if this turned out to be true.

>I believe one of the arguments was also that these couldn't be written in statically typed languages. Although, I do not know if this turned out to be true.

It's not true, they were just abstrusely defined and there's some weirdness around the implicit effects that you can choose to either ignore or incorporate into the equivalent.

Fusion is one of the main things Haskell is known for and an API that gets close enough to what one would use transducers for is `Control.Lens.Fold`.

Others have made more faithful attempts at making it explicit, such as in this post: http://jspha.com/posts/typing-transducers/

Re: Clojure 1.7 is now available

#15

Post by enoch_r » Tue, Jun 30, 2015, 3:39 PM UTC

27182818284 wrote: post #2

>Transducers are composable algorithmic transformations. They are independent from the context of their input and output sources and specify only the essence of the transformation in terms of an individual element. Because transducers are decoupled from input or output sources, The biggest thing holding me back from learning Clojure is that I fear it will take me a decade to become remotely competent in it.

If you have an understanding of functions like map, filter, and reduce, transducers are actually pretty easy.

Say you have `(map inc [1 2])`. You can run that, and get `'(2 3)`.

A transducer is the `(map inc)` part of that call (slightly confusingly, this isn't partial application or currying). You can apply it to something like `[1 2]`, but you can also compose with it, by combining it with say, `(filter even?)` to get something that represents the process of incrementing everything, then removing odd numbers. Or you can put in things that aren't collections, like asynchronous channels, and get back a new channel with the values modified accordingly.

That's pretty much it.

What I think I love most about Clojure is that there are fantastic, esoteric, academic ideas that, when I read about them in a context like this for the first time, I a) do not understand them, and b) have no idea how they would be useful. Then I read an example or two, and suddenly it's apparent that the tool is really as simple as it can be--there's very little accidental complexity--and is extremely useful.

Re: Clojure 1.7 is now available

#16

Post by astine » Tue, Jun 30, 2015, 3:43 PM UTC

icey wrote: post #9

It would be great to see a refactor of some code using transducers to get a better sense of what they're useful for. From an abstraction standpoint, I can see the attraction; but I am having a tough time imagining how it would improve code in practice.

If you don't know Clojure, you should know that Clojure has a sort of generic collection type called a 'sequence'. Arrays, Lists and Lazy Sequences are data structures that implement the sequence interface. There is a standard set of functions, 'map', 'reduce', 'filter' that operates on that sequence interface and provide a common set of functions for different kinds of datatypes. This lets the programmer reuse code and idioms and makes programs easier to understand overall.

The problem is that there are datatypes, such as streams and channels, which are fundamentally sequence abstractions but for one reason or other don't implement the 'sequence' interface. You could wrap them in a lazy sequence but that can be complex and will introduce a performance penalty. When they wrote core.async, they the authors found themselves reimplementing 'map', 'reduce' etc, for channels.

Transducers are a way to provide sequence operations to any kind of collection split the part that interfaces with the collection from the operation. This way we can dispense with the old 'map', 'filter', etc and just use transducers for everything. Because they're implemented with reducers, they're faster as well.

Re: Clojure 1.7 is now available

#17

Post by sharms » Tue, Jun 30, 2015, 3:48 PM UTC

If you want to build a website in Clojure, I highly recommend checking out http://luminusweb.net - the documentation is amazing, and it incorporates nearly all of the best practices I have seen.

Making an API in Clojure using Swagger gives you a full, interactive UI and documentation for your API, while also having a schema which makes sure you know what is submitted and that it validates (i.e. is that a string or a number?)

Re: Clojure 1.7 is now available

#18

Post by jballanc » Tue, Jun 30, 2015, 3:50 PM UTC

icey wrote: post #9

It would be great to see a refactor of some code using transducers to get a better sense of what they're useful for. From an abstraction standpoint, I can see the attraction; but I am having a tough time imagining how it would improve code in practice.

"Processing documents with transducers" is probably one of the more interesting, yet still simple enough to be understandable, examples of transducers: (http://blog.juxt.pro/posts/xpath-in-transducers.html)

Re: Clojure 1.7 is now available

#19

Post by logicchains » Tue, Jun 30, 2015, 3:54 PM UTC

I'm really impressed by how backwards compatible it is. I just changed the Clojure version from "1.6.0" to "1.7.0" for one of my side projects, without updating any library versions, ran it, all the tests passed, and it seems to work perfectly. It also didn't break my Emacs setup, which is a breath of fresh air compared to how much work it was to get the Haskell tooling working with the new 7.10 GHC release (GHC-mod for instance still doesn't have a compatible release, although the trunk mostly works with 7.10). Similarly, even though it's months after the 7.10 release there are still libraries that don't support it, like reactive-banana-wx, whilst a couple of the Clojure libraries I'm using haven't been updated in over a year yet still work fine on 1.7, and none of the libraries I'm using break on 1.7.

To be fair, GHC and the Haskell ecosystem is far more complex than Clojure and its ecosystem/standard library. Nevertheless it's pleasant how easy Clojure was to upgrade (although of course this stability is nothing special: more conservative languages like Go and Java generally break almost nothing on upgrade).

Re: Clojure 1.7 is now available

#20

Post by kyllo » Tue, Jun 30, 2015, 4:00 PM UTC

pron wrote: post #5

27182818284 wrote: post #2

>Transducers are composable algorithmic transformations. They are independent from the context of their input and output sources and specify only the essence of the transformation in terms of an individual element. Because transducers are decoupled from input or output sources, The biggest thing holding me back from learning Clojure is that I fear it will take me a decade to become remotely competent in it.

It is one of the simplest and easiest languages around. The addition of transducers is an unfortunate case of Clojure "pulling a Haskell", valuing an elegant abstraction over ease of understanding and learning. Indeed, your comment alone shows that doing them (and especially giving them a high profile) was a mistake. Just because you can abstract something elegantly doesn't mean you should. No beautiful abstraction i…

I don't understand this argument. Clojure shouldn't have transducers because the word sounds scary? Programming language designers should avoid adding powerful, higher-order abstractions because they are hard to understand? This sentiment is incredibly anti-intellectual. And like you said, if you don't understand it you don't have to use it.