Clojurians Log v2

The irony here is that clojure.string/lower-case (and others) call .toString on their argument already so if they just called str instead, we’d get nil-safe behavior!

I think my problem is that I no longer think of Clojure’s nil-permissive behaviour as nil-safe.

I’d rather know about the problem than have it be masked.

And if I’m really just doing something tricky, I’d rather have it explicit in the code so I (and everyone else) knows what’s going on.

Yeah definitely gonna jump in here on the side of nil punning breaking down badly with interop.

seancorfield's examples of clojure.string behaving really badly with nil arguments has bitten me in the past.

Likewise Compiler.java likes to use nil punning in places to implicitly mean the Object type, and in others expects a concrete non-null java.lang.Class and so on and soforth...

I think I had an earlier rant in here about how nil doesn't even always make sense as a pun for anything because it's type indeterminate and you may not have a base element anyway...

Honestly for me the big win of core.typed the times I used it in anger was that after extended dinking with the type annotations it found a crapload of real programmer failures to deal with nil values correctly.

At this point I'm getting by with pre/postconditions that essentially assert either a hand-rolled structure type, a schema type or a spec where I have to explicitly state that nility is OK.

Meanwhile… https://twitter.com/cmeik/status/738576083671355393

HM, i cannot remember my last NPE either in clojure. But also, i don't see them so often in Java anymore. I would guess it is because after doing 5 years of Java almost daily i recognize the spots where they occurre most often and handle then accordingly. Or maybe I was just lucky 😄

what would be the alternative to nil punning in a dyn.typed lang?

@borkdude: Here's a ballad about lack of nil punning in Scheme dialects: https://ashwinram.org/1986/01/28/a-short-ballad-dedicated-to-the-growth-of-programs/

I don't offhand know about other alternatives, like abolishing nil.

Also, @ericnormand had a good article on this topic http://www.lispcast.com/nil-punning

If you want to gain a re-appreciation of Lisp, dynamic typing and Clojure, try working with Scala in a team for a couple of months. It helps. 🙂

Or Java

I feel like I’m a broken record here, but the more Kotlin I write, the less Clojure I feel like writing.

I’m sure the same would be true of other languages, but Kotlin’s just what I’m working with when I’m not using Clojure

I wonder if some confirmation / group bias is going on here and if I fall myself into it

I mean, I am sure I would prefer clojure over Java, without hesitation, but then, Kotlin, makes me wonder. I saw one of the developers give a talk about it on a java conference two years ago and was fascinated back then, but, as it was not nearly 1.0 I only took a short look.

@cfleming: I would try Kotlin too, won't be looking at Scala anymore. Too slow and complex.

Also he said that a lot of teams working for jetbrains are already switching to kotlin (most of them are free to choose the language they code in)

Yeah, they’re starting to use it heavily in IntelliJ itself

Scala breaks concentration flow. Clojure has a REPL. Kotlin is fast. Maybe both good remedies.

I read somewhere that they already have 500k LOC Kotlin across their various projects.

I do still end up waiting for Kotlin to compile - a REPL would be nice.

@cfleming: That's what I miss so much in Scala, a REPL that gives me some verification if things work the way they should.

without having to recompile all the time

Haha, thats what I just wanted to add, but then I look at kotlin and think where is my REPL? Möp, have to wait for compile / run tests..

Right, I end up using tests instead, which is not the same.

@cfleming: They are more reproducible though. You start with a clean state. No "REPL REPL, your state is a mess"

Yes. And what I tend to find is that when I test things in the REPL, I often don’t write unit tests afterwards, and then I break the code later.

That’s my fault, clearly, but the REPL encourages that.

@cfleming: also my experience

In clojure I adapted my workflow to this (after learning making heavily use of the REPL). I write tests for most of the stuff, but, if things dont work as expected I fire up the repl and figure out the right approach, and then put that into my tests. So still the REPL is a big part of my workflow, even using many more tests now

I really want to implement a wallaby.js type thing for Clojure.

hm, what is the advantage over test-refresh? @cfleming

It’s more immediate, and only runs the actual tests (not the test namespace) which have changed.

And you see the results right alongside the code.

Plus you get code coverage for free.

Again, in your editor.

Ok, i just saw the preview, agreed, that is nice feedback

Something like this should be possible with Lighttable for instance?

It reminds me of their inline evaluation

Not really, it needs to instrument the code that it executes in some way.

(s/instrument ...) 😉

It will run the tests corresponding to the code you have changed, since it has the coverage info.

Not that one 🙂

And again, looking at web stuff, the current state is this: http://karaframework.com/docs/overview.html, which does not even have a deployment story yet or this: http://www.yested.net/ which does not even have a kind of generator or description how to add the dependency to maven / gradle. Which is a sign of lack of experience in my case. Not to question the authors intent, I may be wrong here, but I wont touch them if I have much better alternatives

No, the tooling is bound to be immature compared to Clojure, especially for web work since it’s not JetBrains' main focus.

I don’t do web dev myself so have no idea what the tooling is like there.

Yea, on the other hand, if I wanted to do some android stuff I would definitly look for kotlin instead java.

or clojure

In clojure it is relatively easy to setup a backend and talk via websockets to the frontend and have it all conform to a spec now (for which I used schema before), sharing logic is easy, thanks to cljc and it all because of all the work that was done by a lot ofopen source contributors