Fork me on GitHub

so, I have a conceptual dilemma that tails on rick's definition of simple. if a codebase has multiple ways to do the same thing, it wouldn't be more complex, because they're not interleaving, just more redundant stuff. what I'm trying to apply this to is templating languages, it seems wrong to say (for [x things] (+ "<li>" x "</li>")) is simpler than "<li ng-repeat='x in things'>{{ x }}</li>", because they do the same thing. is there an objective way to argue that the former is better? my best argument is less code, but it's not as sharp as simpler. 😄


Heya! Any wisdom on how I (new class-name) when class-name is provided at runtime?


'cuz right now I get CompilerException java.lang.IllegalArgumentException: Unable to resolve classname: composer-class, compiling:


@nxqd: hey! was gonna say that's definitely better because more things can be done with the abstract representation than the compiled html


It's a bad argument btw. It's because of lisp power that hiccup can pretty much abstract html to pure clojure function and data. Regarding other languages, they dont have this power, so they need to introduce another things to get it done. In this case, it's ng-repeat and {{ }}


nxqd: I'm just caught up with simple meaning less things. I think I just need to let go that definition


@nxqd: that's what I'm trying to get at, it would take a lot more code for the templating engine to work, and to map functions & scope into the engine. but I believe it would still be as simple, just not as minimal/portable/powerful


@munro: you are right, it does take effort to make it look such elegant. I find that if we look at code as text, the parser and ast and stuffs would be much easier to deal with in lisp rather than other languages.


Looking at the clojure.test I was curious what were the benefits of defining ‘is’, ‘deftest’ and others as macros. I guess there should be some, b/c it feels like extending macros is a more painful exercise than dealing with just functions. I am new to the subject, so perhaps it is something obvious..?


mksenzov: with a macro you can collect information about the code itself


to produce nice errors, for example


@ghadi thank you, that explains possible motivation, looking at the actual code… was this really used?


Assertion Failed, (= (you-ran-this) [but-got :that])


curious; for some cases, like function calls it is really neat, for others… meh expected: (= 2 3) actual: (not (= 2 3)) but I got it now, thanks again


Is there a general consensus that argument order isn't particularly consistent in clojure, especially in regard to using -> and ->>? For example map takes the collection as the second argument and select-keys takes it as the first. Or is it just that neither of the two possible orders is really more general/useful in practice?


it usually is kind of consistent, when it takes a function as argument it usually comes first, otherwise the "context" (thing to operate on) is first


Hi, how would I reduce over two collections the same time? So that I get access to the to the same element of both collections at once? Assuming both collections have the same size.


(reduce (fn [ret [e1 e2]] ..) (map list c1 c2))


@bronsa: Thanks, that makes sense simple_smile


@mbertheau: functions that operate on sequences take the seq as last argument map, filter, take .. functions that operate on collections take the collection first conj , assoc..


I'm giving a workshop in an hour and I want to do it with Cursive. Is there a way to increase the font in the REPL window?


you can somehow enable font resizing with the mouse wheel


and using this in the REPL will increase it's font size


I see if I can find it @borkdude


editor->general->change font size...with mouse wheel


Works in windows and with IntelliJ 15


it might be me, but I can't find that in OSX's Intellij


@borkdude: @sveri: Using the mouse wheel is a last resort since you have to do it for all editors individually and it’s not persistent.


@borkdude: Settings-&gt;Editor-&gt;Colors &amp; Fonts-&gt;Console Font


@borkdude: You used to have to restart the REPL but I believe that’s no longer necessary.


@cfleming: I agree, just wanted to give quick help. And when livestreaming I find it better to use the mousewheel, as after a restart I have my normal font size back and dont have to switch back and forth between live streaming and "normal" coding.


@sveri: Ah, I see - interesting.


@sveri: Have you tried presentation mode? You can set the settings for that independently, and then use it for livestreaming.


@cfleming: No, never, as I intend to use intellij as always, just need a larger font size for some folks with small displays


@bronsa: Hmm, that gets in the way since collections are sequences, right?


collections can be transformed into sequences


@bronsa: Hmm, thanks for the insight! I'll pay attention to that in the future simple_smile


@sveri: you can combine the sequence elements into a sequence of pairs (tuples) using map and then reduce the result.


Oh, reduce is not variable arity? I thought it would follow map with regard to that.


@clojurebot: (seq? (list 1 2 3))


and it also takes a while to reply, dunno why


All this was to demonstrate to @mbertheau that lists are sequences, unlike the other collection types.


good point


@hans thanks, @bronsa also pointed this out


Hi! I’m looking for a function to get all paths into a nested datastructure

  (defn paths
    ([x] (paths [] x))
    ([out x]
       (seq? x) (do (prn :seq x out) (mapcat (partial paths out) x))
       (set? x) (do (prn :set x out) (map (partial paths out) x))
       (map? x) (do (prn :map x out) (paths (into out (keys x)) (vals x)))
       :else (do (prn :else x out) (conj out x))

  (let [g #{{:1 #{{:1.1 #{:1.1.2
                          {:1.1.3 #{:}}}}
    (paths g)


;; => (([:1 :1.2] (([:1 :1.1 :1.1.3 :]) [:1 :1.1 :1.1.2])) [:2])


the keys and their order in the result is fine but I don’t want the wrapping empty data structures around them


if paths stays unchanged I would need a flatten function that flattens all but the deepest coll


favor protocols over conditional or instance checks


no for clarity/design


conditionals aren't "webscale" 😉


I actually prefer conds (or even better, core.match) unless the conditional logic has to be extensible from outside. Then my first choice would be multimethods anyway.


I probably would use protocols only when I need to interface with something like component or such.


Is something wrong with me?


@jaen: no hard and fast rule - but if you're dispatching on type protocols make that very clear - and I'd always prefer a protocol to a multi-method for type based dispatch on the first argument... If you want extensibility obviously you'd choose protocols or a multi-method - but even if you don't need extensibility if you're dispatching on type for more than two or three cases I find its often worth putting a protocol in... Like everything though I think there's a series of trade offs - e.g. sometimes you don't want to have to coin another name in your program


are there any projects to use datascript in a redis-like thing?