hey guys, I’m doing some clojure study and yesterday I faced a simple problem. the problem says: you have to save to a file the number of characters from a text below is my solution

(defn char-counter [filename text]
  (spit filename
    (reduce +
      (map #(.length %)
           (str/split text #"")))))

(spit filename (count text)) ?

good @slipset , how to test that ?

we need to bind to a symbol the expression above, right

(defn counter [filename text] 
 (spit filename (count text)))

something like that, right ?

sure.

Note that this will count all characters, also “ “ and “\n”,

no worry ! my concern is more focused on test/design

(count (remove #{\ \\\n} text)) will not count “ “ nor “\n"

the key insight here I guess is that strings in clojure work like sequences, so any function working on a sequence works on a string.

ya ! that is right

how would you test ?

create some text and assert against (slurp filename) value

yes

I read many articles and almost everyone says (Isolate side-effects)

although, I’d consider the spit part rather uninteresting if I wrote this code, I’d be more concerned with the count bit.

how could that be applied on the function above

which mirrors what you’re saying.

> if I wrote this code, I’d be more concerned with the count bit how would be ?

(defn count-chars [text] (count (remove #{\ \\\n} text)))

This is the function I would test

ok, one function just to count the chars, and other function to save ?

( isolating the side effect, right ? )

and other function to combine both

Yes, and that other function would be kind of stupid

(defn count-and-write [filename text] (spit filename (count-chars text)))

which IMHO does not need testing

you run it once in the repl and see that it works.

I got your point !

why make count-chars public

why not private

I think outside the namespace, nobody will use that

things tend to be public in clojure

cool !

nice one

besides, when you decouple the logic from the side-effect, the logic tends to become more generic

count-chars might just be usefull, I’m sure apache-commons has something like that.

yeah !

and we are doing a pure-function that could be easily optimized

that is great !

How come:

(and (<= 0.1 1/10) (>= 0.1 1/10))
=> true
(= 0.1 1/10)
=> false

(== 0.1 1/10)
;; => true

@grav the docstring in = is really misleading claiming "compares numbers ... in type-independent manner". In reality there are different rules, see https://github.com/jafingerhut/thalia/blob/master/doc/other-topics/equality.md

@niwinz Ah - that was my next question 😉

@katox thanks for the pointer!

from http://clojure.org/reference/reader I find about keywords that "They cannot contain '.’ or name classes"

Still:

clj.user> (def my-map {:foo.bar "baz"})
;; => #'clj.user/my-map
clj.user> (:foo.bar my-map)
;; => "baz"
clj.user> :foo.bar
;; => :foo.bar
clj.user> 

nothing enforces that (atm)

didn't know about the dot, I use that all the time 😐

it’s also commonly used by hiccup and other templating tools that use hiccup-style formatting

true

the restriction makes sense for plain symbols since that clashes with package names, like foo.bar.baz, but :foo.bar.baz by itself has no special meaning in clojure

it's full of quirks, but I don't think it's considered important atm, maybe specs will come for this stuff but that's it

There has been (lots of) discussion on the clojure mailing list about non-readable keywords

The consensus seems to be that it’s a feature 🙂

yeah, I couldn't care less personally

https://groups.google.com/d/msg/clojure/Rc_b4_Da-KU/gWo9HDMWBQAJ

(keyword " ¯\\(ツ)_/¯") => ¯\(ツ)_/¯

keyword just doesn't care

non-readable keywords are super annoying when reading edn though

http://clojure.org/guides/faq#unreadable_keywords

reading double colon namespaced keywords like ::foo can also be tricky

:अपठनीय कीवर्ड का अस्पष्ट है

what is the rationale behind / best use of double colons btw ? metadata ?

I personally feel it's a bit hackish

@lmergen I guess they become valuable when you start using specs

what I mean is, why did spec choose double colons ?

it's not a spec thing, it's been in clojure from the start

right, I saw them a few times in other projects as well. I guess I'm asking my question in the wrong way. :)

how do I know whether or not I should use double colon or single colon ?

when designing, say, a library

I have to assume there is some best practice around them ?

depends: think about these like vars, you want to have them namespaced

aha that makes sense. so data / metadata is a good one

You never have to use :: at all

mainly brevity, ::foo it just syntactic sugar for :<current-namespace>/foo

It's just a tool for typing less to get qualified keywords

Using :: with an alias is pretty handy though to separate the namespaces in your code from the actual namespaces via indirection

If you say ::foo/whatever everywhere you can define what foo aliases exactly once at the top of the file (and easily change it)

has anyone tried using clojure 1.8 -Dclojure.server.repl stuff with nrepl and cider?

It won't work - nrepl is a totally different protocol

I suspected that, but could not find details (didn't look into that that much)

You could write a server repl accept function that talked nrepl but afaik no one has done so

The default socket server repl is just stream based

I see, thank you

If i have a library that depends on something that is not distributable, ie not on maven or anything, but the jar is available at a public url, is it possible for my library to download this jar from the url and add it to the classpath automatically whenever it's used? Or is this pretty much going to have to be up to the end user

you will have to first install it with mvn install-file to your local .m2/repository. or with mvn deploy-file to a locally accessible Maven repository

still struggling why the code below is considered bad I’m using one global symbol inside the save function. everyone I showed the code said to use the save-explicit but nobody gave me a real reason, only do not use globals. can anyone help me with that ? appreciate guys

(def filename “filename.txt”)

(defn save [text]
 (spit filename text))

(save “hello”)

(defn save-explicit [file text]
  (spit file text))

(save-explicit filename “hello”)

@oliv I think they mean to say that the save function you have declared is way less reusable then the save-explicit function. Globals are not all bad but most of the time it is better to make things an explicit argument to a function.

yeah ! agree that save function is way less reusable. but on my domain , suppose I don’t need the reusable save because all my use is to save on filename. I’m super lazy, YAGNI is my middle name 😄

in general, it’s good for functions to take explicit inputs and return an output

if functions rely on things other than the data they’re given as explicit inputs, they usually end up being harder to think about, maintain, and change over time

save-explicit is better because it says: this is all the information i rely on in order to work, it’s all right here, look at it

lets you worry less when you’re reading / thinking about the function

the world won’t catch fire if you use save for your own personal code fwiw

do whatever you like best 🙂

but imagine the simple situation i will call dependency hell suppose the function controller uses the save-explicit

(def file “hello.txt”)

(defn controller [request]
  (save-explicit file (:body request))

@jrheard ^^ in the above situation, the controller must change the signature to receive the save-explicit dependency

right ?

(defn controller [request file]
  (save-explicit file (:body request))

or, well, in the first example you gave your save-explicit call uses the global file variable so i don’t think that’s quite the same, but i see your point - yeah, there’s definitely a tension between “all functions should take all their data as explicit inputs” and “oh god now all of my functions take 300 inputs"

there’s no 100% right answer, your point is completely valid - do what makes the most sense in whatever situation you’re in imo

exactly

i’ve seen this specific topic debated in this channel many times and there are strong arguments on either side, it basically just kinda depends 🙂

yeah ! ok ! I’m very new on clojure and reading/watching talks a lot. it is unanimous that everyone advocates that ( explicit arguments/dependencies )

yeah, taking explicit args whenever reasonably possible seems to be a good habit

thx @jrheard . do you recommend a good talk/book that points that

hm, i can’t actually think of a good one off the top of my head - if one comes to me later today, i’ll definitely link to it! sorry 😅

oh, thank you @jrheard

if you can find a good talk or article / etc on pure functions, they’re basically the same idea

save-explicit is pure because it only relies on its inputs, save is impure because it relies on something in addition to its input

and well they’re both impure because they presumably write to a file, which is a side effect

but if you ignore that… 😄

yep ! and everyone advocates make side-effects explicit