Ironically I ran into an issue where I was receiving "" instead of nil which caused some interesting behaviour.
For those who find these things interesting, this was for capturing criteria in the UI which was sent to the server to filter. The behaviour was: - form is nil, server ignores the query - enter some text, server sends the top N matching records - delete the text, you get the first top N records I am sure you have guessed, but the cause was HTML input fields start off as nil, enter something and then delete it and you get an empty "". The server was checking (not (nil? criteria)) rather than (seq criteria)....there is a reason (seq ....) is idiomatic :-). On 21 October 2016 at 19:39, Sean Corfield <s...@corfield.org> wrote: > 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. -- 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.
