Fork me on GitHub
#clojure
<
2016-01-26
>
munro00:01:14

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. 😄

bradford01:01:09

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

bradford01:01:39

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

munro01:01:01

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

jimmy02:01:46

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 {{ }}

munro02:01:39

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

munro02:01:33

@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

jimmy02:01:40

@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.

mksenzov02:01:47

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..?

ghadi02:01:36

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

ghadi02:01:46

to produce nice errors, for example

mksenzov03:01:27

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

ghadi03:01:57

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

mksenzov03:01:43

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

mbertheau09:01:48

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?

mpenet09:01:17

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

sveri10:01:17

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.

bronsa10:01:07

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

sveri10:01:39

@bronsa: Thanks, that makes sense simple_smile

bronsa10:01:44

@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..

borkdude10:01:16

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?

sveri10:01:49

you can somehow enable font resizing with the mouse wheel

sveri10:01:01

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

sveri10:01:08

I see if I can find it @borkdude

sveri10:01:51

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

sveri10:01:18

Works in windows and with IntelliJ 15

borkdude10:01:15

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

cfleming10:01:20

@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.

cfleming10:01:04

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

cfleming10:01:45

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

sveri10:01:19

@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.

cfleming10:01:36

@sveri: Ah, I see - interesting.

cfleming10:01:07

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

sveri10:01:54

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

mbertheau11:01:07

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

bronsa11:01:23

collections can be transformed into sequences

mbertheau11:01:49

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

hans11:01:38

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

jaen11:01:27

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

Lambda/Sierra13:01:54

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

bronsa13:01:36

and it also takes a while to reply, dunno why

Lambda/Sierra13:01:14

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

bronsa13:01:36

good point

sveri13:01:34

@hans thanks, @bronsa also pointed this out

denik21:01:14

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

(do
  (defn paths
    ([x] (paths [] x))
    ([out x]
     (cond
       (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 #{:1.1.3.1}}}}
                  :1.2}}
            :2}]
    (paths g)

    ))

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

denik21:01:19

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

denik21:01:29

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

ghadi21:01:20

favor protocols over conditional or instance checks

ghadi21:01:52

no for clarity/design

ghadi21:01:18

conditionals aren't "webscale" 😉

jaen22:01:44

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.

jaen22:01:07

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

jaen22:01:11

Is something wrong with me?

rickmoynihan22:01:11

@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

arohner23:01:36

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