Fork me on GitHub
#other-languages
<
2016-06-03
>
seancorfield00:06:38

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!

cfleming00:06:26

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

cfleming00:06:03

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

cfleming00:06:32

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.

arrdem03:06:01

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

arrdem03:06:26

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

arrdem03:06:12

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...

arrdem03:06:52

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...

arrdem03:06:55

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.

arrdem03:06:32

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.

sveri05:06:57

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 😄

borkdude06:06:13

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

tjg07:06:25

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

tjg07:06:19

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

borkdude07:06:20

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. 🙂

cfleming07:06:17

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

cfleming07:06:51

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

sveri07:06:47

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

sveri08:06:13

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.

borkdude08:06:30

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

sveri08:06:05

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)

cfleming08:06:39

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

borkdude08:06:54

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

cfleming08:06:04

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

cfleming08:06:23

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

borkdude08:06:45

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

borkdude08:06:56

without having to recompile all the time

sveri08:06:00

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..

cfleming08:06:12

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

borkdude08:06:45

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

cfleming08:06:21

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.

cfleming08:06:38

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

borkdude08:06:58

@cfleming: also my experience

sveri08:06:03

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

cfleming08:06:30

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

sveri08:06:27

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

cfleming08:06:53

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

cfleming08:06:01

And you see the results right alongside the code.

cfleming08:06:44

Plus you get code coverage for free.

cfleming08:06:51

Again, in your editor.

sveri08:06:08

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

sveri08:06:22

Something like this should be possible with Lighttable for instance?

sveri08:06:32

It reminds me of their inline evaluation

cfleming08:06:45

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

borkdude08:06:02

(s/instrument ...) 😉

cfleming08:06:12

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

cfleming08:06:19

Not that one 🙂

sveri08:06:08

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

cfleming08:06:51

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

cfleming08:06:13

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

sveri08:06:50

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

sveri08:06:12

or clojure

sveri08:06:49

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