## Where communities thrive

• Join over 1.5M+ people
• Join over 100K+ communities
• Free without limits
##### Activity
jolod
@jolod
I have thought about this, and I think I know what the components of such a kata would be. I think we should schedule a small workshop meetup where we sit and work out a good kata. :-) @magthe
Magnus Therning
@magthe
Sounds goot @jolod I'd be up for that!
jolod
@jolod
@magthe Limit of, say, 6 people?
jolod
@jolod
Magnus Therning
@magthe
Oh, I'd not see that one @jolod !
Magnus Therning
@magthe
Too bad only 3 of the katas actually exist :(
jolod
@jolod
@magthe Oh. :-/
jolod
@jolod
@magthe Here's some ideas for things to write katas around. 1a) Refactor to immutability. 1b) Refactor to use monads. 1c) Refactor to use monad transformers gasp. 2) Refactor to treat functions as "the points".
3) Refactor loop state to recursive state.
@magthe 1d) is of course refactor to free monad, and actually works in Python, kind of, as you know. Even though it in a way is the most advanced technique. :-)
jolod
@jolod
An example of 1a and 2 is my DoubleGraph presentation: https://github.com/jolod/presentation-doublegraph/blob/master/slides.md, maybe that could be reworked into a kata.
For 3 there are just endless examples. :-)
Magnus Therning
@magthe
I've also been thinking of refactor to effects (yes, free monads basically, but picking an effect lib might make it more real), refactor to tagless final, refactor to ReaderT.
Magnus Therning
@magthe
Then there are some other things, but maybe that's more suitable for exercises, that basically follow the idea of Advent of Optics: solve it with map/filter/fold, solve it with traversals (there's a lib for this, but the name escapes me now)
jolod
@jolod
Magnus Therning
@magthe
Yes, the goal would be to start with something not very FP and make it "more FP".
Along the lines of don't write F# as if it's C#, or don't write Scala as if it's Java.
Magnus Therning
@magthe
Drawing from my impressions of the Carp mob programming meetup, it might be easiest to use a non-refactoring Kata. There's a good chance that'll first lead to a working solution in need of refactoring.
jolod
@jolod
@magthe I think that depends a lot on the participants. Some people focus a lot of refactoring during the session.
Magnus Therning
@magthe
Yes, very true.
Jean-Louis Giordano
@Jell
OK I am very excited about the new generics proposal in Go
I've played with it for a few hours today
Jean-Louis Giordano
@Jell
could do a cross-over webinar with the Go West meetup group
jolod
@jolod
@Jell Great!
Jean-Louis Giordano
@Jell
I'm checking with Go West if that's of interest
Erik Svedäng
@eriksvedang
Cool. I’ve been writing Go today!
Magnus Therning
@magthe
As long as you fit in "e du go elle?" or calls Wadler "en go gubbe", om all for this 😁
No, of course I'm unreservedly in favour, @Jell
Jean-Louis Giordano
@Jell
:smile:
jolod
@jolod
"go.lambda" ;-)
Jean-Louis Giordano
@Jell
gonna share here as well: went berserk on Go generics during the weekend and tried to implement Clojure's transducers in Go
Side-by-side comparison:
(def in [1 2 3 4 5 6 7 8 9])
(def xform (comp (map (fn [x] (quot x 2)))
(take 5)
(map (fn [x] (* x 2)))
(map (fn [x] (* x 2)))
(map (fn [x] (* x 2)))))
(def out (into [] xform in))
in := []int{1,2,3,4,5,6,7,8,9}
xform := Compose(Compose(Compose(Compose(
Map(int,int,[]int)(func (x int) int { return x / 2 }),
Take(int,[]int)(5)),
Map(float32,int,[]int)(func (x int) float32 { return float32(x * 2) })),
Map(int,float32,[]int)(func (x float32) int { return int(x * 2) })),
Map(int,int,[]int)(func (x int) int { return x * 2 }))
out := into([]int{}, xform, in)
I think it's great because in go with generics:
1. it's possible to implement transducer
2. you really shouldn't :D
Veit Heller
@hellerve
looks great! are they streamable/lazy or do they realize every value right away (i.e. intermediate arrays)
Jean-Louis Giordano
@Jell
they do not realize intermediate arrays (like in Clojure), but in that first version I wrote they actually only work from and to arrays, I need to put a collection interface to make into more "generic"
(I mean, into only accepts arrays as in & out, xform doesn't care)
(ok rather, xform cares because you need to give the right type annotation when instantiating it, but you could replace []int with whatever type instead in the type annotations)
Veit Heller
@hellerve
neat!
Magnus Therning
@magthe
I found what I think is a rather good example of refactoring to FCIS. The original is in Python and I attempted a version in Haskell: https://gitlab.com/magus/sync-fcis-refactor
What do you think about it? Maybe it couybe used in a meetup, a group exercise, ...
Or maybe someone wants to contribute a version in another language? Clojure? OCaml? F#? Why not JavaScript or C#?
jolod
@jolod
Tiny poll: do you use qualified or unqualified imports in Haskell? (In most languages "import all" statements are shunned, but they are common practice in Haskell. Personally I generally import types and operators unqualified, and qualify everything else.)
Veit Heller
@hellerve
personally i qualify everything until it becomes ridiculous. if i import more than, say, 10 things, then i either import qualifiedly, or just import it all directly (though i don’t really like that all that much tbh)
jolod
@jolod
@hellerve When does it become ridiculous to qualify? :-)
Magnus Therning
@magthe

Organising the imports in Haskell sometimes feels rather silly.

Stuff like this

import Data.Conduit ((.|))
import qualified Data.Conduit as C

is a bit laughable, but feels necessary.

Veit Heller
@hellerve
@jolod sorry, unclear language: when it becomes ridiculous to list the individual functions to import (which is a different qualification than importing using qualified)
jolod
@jolod
Have any of you found import Mod as Foo (x,y) or import qualified Mod as Foo (x,y) useful (in real code)?
Veit Heller
@hellerve
i cant say ive used it very much