This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-04-01
Channels
- # aatree (3)
- # admin-announcements (2)
- # beginners (42)
- # boot (142)
- # cider (12)
- # cljsrn (11)
- # clojure (126)
- # clojure-greece (2)
- # clojure-poland (7)
- # clojure-russia (81)
- # clojure-uk (10)
- # clojurescript (81)
- # component (27)
- # core-typed (2)
- # cursive (18)
- # euroclojure (1)
- # gorilla (1)
- # hoplon (85)
- # immutant (2)
- # jobs (3)
- # leiningen (2)
- # off-topic (49)
- # om (151)
- # onyx (19)
- # parinfer (3)
- # re-frame (36)
- # reagent (2)
- # spacemacs (5)
- # untangled (32)
- # yada (9)
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 https://www.meteor.com/tutorials/blaze/creating-an-app 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.
@adamkowalski: check out Yogthos' blog. He also has a couple books on the matter. http://yogthos.net/posts/2014-07-15-Building-Single-Page-Apps-with-Reagent.html
thank you!
@urbanslug: You could with let
but in that case (fn
would be 2 characters shorter
@urbanslug: What would you want it to return?
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.
I would argue that map and reduce are not about return types, but about the operations they excecute.
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.
@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...
the book clojure applied has a really nice introduction to them. that's what really made them click for me, personally.
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
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?
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
aha! sorry for the rant then