Fork me on GitHub

Hey can you guys recommend any good tutorials for building a whole web app from start to finish with clojure/script? I feel like the vast majority of tutorials are either very specific to one topic, or are very trivial and essentially just get a basic server up with a hello world response. I was hoping for something similar to where they build a whole app including getting a server, database, and even basic authentication working. Then they hook it all up on the client side and demonstrate how to talk back and forth over the server and even show you how to do optimistic updates.


Can I destructure a lambda that uses #()


@urbanslug: You could with let but in that case (fn would be 2 characters shorter


So it seems simple_smile


Clojure’s map is not cool. Sucks that I can’t make it return another type.


@urbanslug: What would you want it to return?


@sveri: A map. into {} … did it.


I remember when starting with clojure I had these kind of thoughts too. Today map is perfectly fine as it is, given there is a mapv too. Are there languages that handle map differenlty?


is there a less ugly solution to 'force' evaluation of a sequence, similar to (into [] (map fn xs)) ? or is it actually a sign of bad design if this is an issue ?


@lmergen: Most of the times I just use mapv. Doing webstuff for instance will evaluate sequences anyway when passing them to the client or using them in a template. Also I like working with vecs more than with lazy seqs.


If you want map to return another type then you’re probably looking for reduce no?


I would argue that map and reduce are not about return types, but about the operations they excecute.


exactly, and a sequence or vector is about the representation


having said that, it's perfectly possible to build a reduce operation that converts from a lazy seq to a vector


@lmergen: This is true, but this has another problem, readability. Seeing a reduce operation I would expect some reduction. Walking through the code to see that it converts a lazy seq into a vec is therefore a code smell, from my POV.


yes exactly


i was just pointing out that it is possible


but it's definitely not the way to go

Chris O’Donnell12:04:07

@lmergen: You've basically described transducers. They split sequence operations into a transform step and a reduction step.


@codonnell: awesome, i didn't have the time to dive into them, so they always sounded a bit scary...

Chris O’Donnell12:04:08

the book clojure applied has a really nice introduction to them. that's what really made them click for me, personally.


but as with most things in FP, they always sound more complicated than they are simple_smile

Chris O’Donnell12:04:51

yeah, it's all about getting a simple model for them in your head before trying to understand the details


yes... and academics are not very good at choosing simple words to describe simple models simple_smile


hello. i got this little problem: function should put \n every nth char in string params: “K.K.”, 2 result: "K.\nK." my solution: (apply str (map (partial apply str) (interpose "\n" (partition 2 "K.K.")))) seem bloated. any tip how to do it easier way?


@prozz: I'd use flatten instead of the map


@rauh: indeed works


(apply str (flatten (interpose "\n" (partition 2 "K.K."))))


thanks for the tip 😉


sveri: reduce can create outputs larger or smaller than the input, and to claim it shouldn't seems very narrow minded to me. Similarly mapcat can produce a sequence shorter or longer than the input sequence. These are inherent properties of reduce and mapcat, they are key parts of what makes these useful functions, and I will continue using reduce and mapcat regardless of the size comparison of input and output collections.


perhaps this issue could be avoided if I do (def fold reduce)


and then proceed to use fold


@noisesmith: That was basically what I meant, I dont differ them on their return type, but on what they do.


this is the statement I was disagreeing with: "Walking through the code to see that it converts a lazy seq into a vec is therefore a code smell, from my POV.", perhaps I misinterpreted


@noisesmith: Ah ok, I thought you meant the other statement I meant before. I just meant that I would not want to see reduce being used to convert a lazy seq into a vec, while the content remains the same. That was everything.


sveri: oh, ok, yeah I would expect (into [] ...) and not a reduce


or just vec even


exactly, that was the whole point.


aha! sorry for the rant then


No problem, sometimes it is hard to understand what I write, it was my fault most probably.