On 10/21/16, 10:40 AM, "Colin Fleming" <clojure@googlegroups.com on behalf of colin.mailingl...@gmail.com> wrote:
> Honestly, the easiest solution to my problem is probably just to use Kotlin, > which was > designed by JetBrains for almost exactly my use case, has great IDE support, > and has > a lot of smart people working full-time on it. And, to be fair, Kotlin has as a design goal to help address Java’s NPE issue. Whereas Clojure has, as part of its design, idiomatic nil-punning. If you’re doing a lot of Java interop, Kotlin is going to be a better fit. As for Typed Clojure, we’ve tried it a few times and the problems cited by CircleCI and by yourself are why we’ve given up on it each time. I will say, in Typed Clojure’s defense, that it gets better and better each time I try it so it’s definitely going in the right direction – but it is a very hard problem to solve! Pretty much the only time I ever see NPEs is when my Clojure code touches Java interop. And, yes, that can mean numeric ops (since those are implemented directly in Java) and string manipulation (again, implemented on top of Java). As an experiment, I tried a version of clojure.string where nil was always treated as “” and it does indeed avoid the NPEs but it comes at a performance cost (calling str or adding nil conditions). In the domain in which I work, nil -> “” is pretty much universally the right thing so it’s a cost we’re considering swallowing, for the extra simplicity it would bring to our code (i.e., creating a drop-in replacement of clojure.string that implements all of the functions with added str calls as needed – many can be handled mechanically). We don’t do much numeric work so we don’t hit NPEs in that Java interop boundary very often. There tho’ there is almost no argument that nil -> 0 would be the “right thing” so suffering NPEs instead of some NonNumericArgumentException thing isn’t such a horrible trade off. Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood On 10/21/16, 10:40 AM, "Colin Fleming" <clojure@googlegroups.com on behalf of colin.mailingl...@gmail.com> wrote: I tried it a couple of years ago, and my impressions were more or less the same as CircleCI's here. I found the type annotation burden much higher than using a typed language such as Kotlin, the type checking was very slow and the boundary between typed and untyped code was really onerous. Ambrose has done some great work recently though, so I should check it out again. However my general feeling is that retrofitting something like Typed Clojure onto an existing language is always going to be more difficult and fraught with problems than having a language which was designed with the types in mind in the first place. Another possibility which I haven't had time to explore properly is Allen Rohner's spectrum. Honestly, the easiest solution to my problem is probably just to use Kotlin, which was designed by JetBrains for almost exactly my use case, has great IDE support, and has a lot of smart people working full-time on it. However that has a couple of problems: 1) it would make me sad and 2) I would no longer be dogfooding Cursive all the time, which is a valuable source of finding bugs during development. But at least I'd be spending all my time on developing Cursive features, and not chasing NPEs or investigating all this. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
