This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (2)
- # alda (4)
- # beginners (15)
- # boot (89)
- # cljs-dev (88)
- # cljsrn (75)
- # clojure (149)
- # clojure-belgium (16)
- # clojure-france (2)
- # clojure-greece (6)
- # clojure-russia (108)
- # clojure-spec (39)
- # clojure-taiwan (3)
- # clojure-uk (7)
- # clojurescript (70)
- # css (3)
- # cursive (17)
- # data-science (2)
- # datascript (7)
- # datomic (41)
- # dirac (3)
- # hoplon (12)
- # instaparse (1)
- # juxt (3)
- # lambdaisland (9)
- # mount (4)
- # off-topic (6)
- # om (71)
- # om-next (4)
- # onyx (22)
- # other-languages (56)
- # perun (15)
- # proton (6)
- # re-frame (32)
- # reagent (42)
- # specter (34)
- # spirituality-ethics (7)
- # tmp-json-parsing (5)
- # untangled (13)
- # vim (4)
- # yada (6)
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
I think my problem is that I no longer think of Clojure’s nil-permissive behaviour as nil-safe.
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.
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.
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 😄
@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/
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. 🙂
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)
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.
@cfleming: That's what I miss so much in Scala, a REPL that gives me some verification if things work the way they should.
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..
@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.
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
It’s more immediate, and only runs the actual tests (not the test namespace) which have changed.
It will run the tests corresponding to the code you have changed, since it has the coverage info.
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.
Yea, on the other hand, if I wanted to do some android stuff I would definitly look for kotlin instead java.