Anyone familiar with getting spurious No such var errors? Might have to do with Clojure 1.10+ error reporting Hard to verify since this project uses 1.10+ fearures, so I can't tentatively downgrade so easily

doesn't sound familiar to me re 1.10 error reporting

repro? fuller msg? environment?

is there a way to tell leiningen to have a profile which ignore some files in src and dependencies?

I'm not sure, but :exclusions is not about it?

I'm not sure but I'll try, thank you!

Hello guys, anyone familiar with clojure machine-head? Trying to connect to Azure Iot Hub, but getting this error: Execution error (EOFException) at java.io.DataInputStream/readByte (DataInputStream.java:267).

Hi! Say I intentionally throw during testing but don’t want the stacktrace in the test output is that possible somehow (w/ lein test/`clojure.test`)? hope that makes sense?

There's (is (thrown? ArithmeticException (/ 1 0))) and

(is (thrown-with-msg? ArithmeticException #"Divide by zero"
                      (/ 1 0)))

Hope that helps!

ah yes! thanks @olical

Is there a guide or tutorial or some kind of explanation to why we should use seq for non-empty checks? I feel like I'm missing something, because semantics of (not (empty? ...)) are clear, and semantics of seq requires deep knowledge of it's behavior and truthiness semantics... Which I know, but don't understand why it is advertised as preferred approach. I also remember there where some discussions on slack awhile ago where Alex Miller suggested to use nils instead of empty vectors, and just use (when xs ...), and I'm interested to know why is this approach considered better, because without this check you might get surprising behavior when conjing will add to beginning instead of end

I kinda agree. I saw that @ghadi mentioned that empty? might get a counted check in the future in which case (not (empty? will be necessary again. It feels like seq is kinda using the implementation details of empty?

the reason that (seq x) is preferred over (not (empty? x)) is because empty? is implemented as (not (seq x))

so (not (empty? x)) is just (not (not (seq x)))

right. which was my point about implementation details leaking out. When empty? gets more complicated looking at ICounted then using implementation details is bad, no?

implementation details?

I don't buy not-not argument, it's implementation detail

@vlaaad yeah, I don't really either

I just know that's a reason that is often given

http://clojure-log.n01se.net/date/2009-02-19.html#10:24a has some discussion that rich eventually jumps into

my suggestion to @vlaaad earlier is primarily due to the use case in that context - the stuff he is doing is collection stuff. In that case, lean on nil and polymorphic collection fns and avoid using empty collections at all. If you're in more of a seq context, then lean on seq.

in general in Clojure avoid making stuff to hold a "place" - if you do that Clojure's design will lead you to code that is simultaneously easier to read, has fewer branches, and is more performant.

this applies to putting nil values in maps (just omit), making empty collections (conj or assoc into nil instead), etc

if you are working with collections (not sequences), forcing a seq just to check emptiness is not efficient

the advice to use (seq x) as a terminating predicate is primarily of use when working with sequences, where you are going to force the sequence anyways to walk it (and sequences cache that so the additive cost is negligible)

that is all my own internalized "best practice", so not trying to speak for Rich in any way here, fyi

I understand what you say about advising to use (seq x) where I am going to force sequence anyway, but can you elaborate more on "avoid making stuff to hold a place"? Is (let [x (blah->possibly-empty-vec blah)] (when-not (empty? x) ...)) somehow a place and (let [x (blah->non-empty-vec-or-nil blah)] (when x ...)) is not?

I also worry about conjing into nil: I'd usually prefer to work on vectors, not lists, and conjing into nil produces a list

ah right, I actually was thinking of (conj) for that one

of those two examples you give, I definitely prefer the latter

wouldn't you rather avoid constructing an empty vector (which takes time and consumes memory) and also write (when x ...) vs writing (when-not (empty? x) ...)?

but (identical? [] []) returns true, what is taking time here?

I've seen a lot of code that contorts itself to use empty? because it's perceived as more literate than seq -- but seq is a fundamental function and idiom, not some advanced feature

identical? does not work on vectors -- it happens that the compiler interns the empty vector

Clojure rewards you again and again for not making stuff. nils are cool. I like nils. I disagree with Hoare. :)

good point

I just realized I also prefer blah->non-empty-vec-or-nil 🙂

if you're going to write stuff like (when x ...) though, you are committing to a philosophy and it requires some amount of discipline to return nil and not []

I am all in on that

but make sure everyone in your team agrees ;)

yeah, this approach should apply to all the codes

same thing on omitting attributes from maps when the value is nil

if you're taking that approach (again, I'm all in), then you need to be careful to avoid adding those attributes when you create the maps in the first place

and aware of external libs/systems that might give you maps like that

generally, I think it's rarely worth stripping stuff out of maps if you get them from someone else

@ghadi Agree on seq being fundamental idiom, but empty? is still more literate, and a function to check if coll is empty in clojure core seems pretty fundamental as well, I don't see an argument here in favor of seq

these are functions that apply in different worlds

I always prefer an empty collection over a nil. Also, I wrote my own function (not-empty? x)

For example, clojure.java.jdbc will give you maps with nil values if the column in the database was null. But in next.jdbc, at least on master, there's next.jdbc.optional/as-maps that will give you maps where nil values are omitted.

in some sense, jdbc is just surfacing sql here, so it makes total sense

(the default as-maps is still nil values from null columns)

sql nulls are inherently overloaded

Yeah, right, different worlds. nil instead of [] for the win

@vlaaad if you are writing seq-oriented code (using ->>, map, filter, etc), seq makes total sense and I think the language designer has been quite clear that it is the proper idiom for checking whether the seq has at least one element or not

I usually use transducers instead of lazy sequences wherever I can for performance reasons

transducers aren't always faster

nothing wrong with using lazy seqs where it makes sense

hmm, I thought they are, with exception of mapcat fully realizing intermediate steps...

past blathering on this topic recorded here: https://clojure.org/guides/faq#transducers_vs_seqs

if you're only going to use 5 values, then it's a lot faster to use lazy seqs

there may be a misconception that seq and empty? are opposites

maybe I misunderstand you?

replies in thread