This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-01-26
Channels
- # aatree (6)
- # admin-announcements (2)
- # aws (1)
- # beginners (46)
- # boot (341)
- # braid-chat (3)
- # cider (20)
- # clara (1)
- # cljs-dev (3)
- # cljsjs (7)
- # cljsrn (73)
- # clojure (63)
- # clojure-art (4)
- # clojure-dev (3)
- # clojure-russia (83)
- # clojurescript (77)
- # core-async (12)
- # core-matrix (2)
- # cursive (9)
- # data-science (1)
- # datomic (14)
- # dirac (3)
- # emacs (9)
- # hoplon (3)
- # immutant (8)
- # ldnclj (80)
- # luminus (13)
- # mount (7)
- # off-topic (4)
- # om (288)
- # onyx (20)
- # overtone (5)
- # pedestal (10)
- # perun (3)
- # proton (103)
- # quil (1)
- # re-frame (3)
- # reagent (13)
- # ring-swagger (7)
- # yada (43)
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. 😄
'cuz right now I get CompilerException java.lang.IllegalArgumentException: Unable to resolve classname: composer-class, compiling:
Oh, I did find this: https://stackoverflow.com/questions/9167457/in-clojure-how-to-use-a-java-class-dynamically
@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..?
@ghadi thank you, that explains possible motivation, looking at the actual code… was this really used?
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.
@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?
@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: 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: 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
@sveri: you can combine the sequence elements into a sequence of pairs (tuples) using map and then reduce the result.
@clojurebot: (seq? (list 1 2 3))
@stuartsierra: it's /clj
thanks @bronsa
All this was to demonstrate to @mbertheau that lists are sequences, unlike the other collection types.
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])
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
denik: some ideas at https://gist.github.com/stuarthalloway/b6d1c8766c747fd81018
I actually prefer cond
s (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.
@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