This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (14)
- # boot (83)
- # cider (13)
- # cljsrn (4)
- # clojure (240)
- # clojure-argentina (1)
- # clojure-berlin (2)
- # clojure-canada (1)
- # clojure-dusseldorf (1)
- # clojure-greece (2)
- # clojure-india (2)
- # clojure-japan (2)
- # clojure-russia (23)
- # clojure-taiwan (2)
- # clojure-uk (12)
- # clojurescript (138)
- # cursive (6)
- # datomic (36)
- # hoplon (245)
- # jobs-discuss (35)
- # lein-figwheel (4)
- # melbourne (2)
- # off-topic (1)
- # om (26)
- # om-next (2)
- # onyx (23)
- # proton (8)
- # quil (1)
- # re-frame (9)
- # ring-swagger (2)
- # untangled (10)
- # yada (6)
Hi, I'm going to give a brief Clojure introduction (20/30 mins) in a local meetup. Any advice about what to tell, reference slides etc? Audience are devs, both backend and frontend, various languages. Main goal I think should be to try raise interest on it
@mbarbieri: cognitect has on their github a gorilla repl project: https://github.com/cognitect/clojure-lab/
@seancorfield: one could maybe argue that having
(reverse “hello”) => “olleh” be the default would be a better solution than having a surprising default which is a wee bit faster
I also guess that if Clojure were implemented in terms of protocols, you’d have IReversible (which does exist in Clojurescript) which could be extended to java.lang.String at a slight performance penalty
@slipset: I believe there’s a strong argument that "everyone" shouldn’t be forced to pay for "someone" else’s performance — so
reverse being "as fast as possible" on sequences at the expense of needing
clojure.string/reverse is reasonable.
That’s probably more applicable to other core functions than to
reverse but I suspect if Rich had the chance to "do over" there would be no core functions that worked on strings (except "by accident") and all the string functions would be in
I see your point, but it'd be interesting to see some benchmarks. Also in cljs it seems to me that we're already dispatching on type, so including string shouldn't be that much of a penalty.
But you want functional compatibility between Clojure and ClojureScript so that you can reuse code via cljc files. Having
reverse work on strings in ClojureScript but not Clojure would be a dangerous trap.
If you think it's a worthwhile change -- in both languages -- you should advocate to Clojure/core about it. But unless I'm misreading some of their comments about string handling vs collection handling, I don't think they'll accept it.
The issue is that a lot of collection functions work on strings-as-sequences but produce sequences as results. Consider
map for example, which takes any collection as input but produces a sequence:
(map inc [1 2 3]) is
(1 2 3), not
[1 2 3]. Same with
filter and many others. Clojure isn't a type-preserving language (in the same way that Scala's collections library aims to be).
If you argue that
(reverse "Hello") should produce
"olleH", then it's reasonable to argue that
(map Character/toUppercase "Hello") should produce
"HELLO" -- but that's starting down the path of changing a lot of functions...
(map char-func some-string) preserves the type of the collection (`String`) then folks will argue that
(map some-func some-vector) should also preserve the type and produce a vector and so on.