{"id":1872,"date":"2012-08-20T10:15:26","date_gmt":"2012-08-20T14:15:26","guid":{"rendered":"http:\/\/scientopia.org\/blogs\/goodmath\/?p=1872"},"modified":"2012-08-20T10:15:26","modified_gmt":"2012-08-20T14:15:26","slug":"nulls","status":"publish","type":"post","link":"http:\/\/www.goodmath.org\/blog\/2012\/08\/20\/nulls\/","title":{"rendered":"Nulls"},"content":{"rendered":"

So, my post on monads apparently set of a bit of a firestorm over my comments about avoiding null pointer exceptions. To show you what I mean, here’s a link<\/a> to one of the more polite and reasonable posts.<\/p>\n

Ok. So. Let me expand a bit.<\/p>\n

The reason that I think it\u2019s so great that I don\u2019t get NPEs when I use an option with something like Option isn\u2019t because it makes me a super-programmer who’s better than the lowly slime who deal with NPEs. It’s because it changes how that I write code, in a way that helps me avoid making mistakes – mistakes that I make because I’m just a fallible idiot of a human.<\/p>\n

There are two fundamental things about an option type, like what we have in Scala, that make a huge difference.<\/p>\n

First, it narrows<\/em> the field of errors. When I’m programming in Java, any call that returns a pointer could return a null. The language makes no distinction between a function\/expression that could return a null, and one that can’t. That means that when I get an NPE, the source of that null pointer could be anything<\/em> in the dynamic slice leading to the error. With an option type, I’ve got two kinds of functions: functions that always<\/em> return a non-null value, and functions that sometimes return a non-null value, and sometimes return a None. That’s incredibly valuable.<\/p>\n

Second, it forces me to explicitly deal with the None case. In Java, programmers constantly build code without null checks, because they know<\/em> that a function won’t return null. And then it does, and ker-splat. With an option type, I have no choice: I have to explicitly deal with the potential error case. Sure, I can forcibly code around it – in Scala, I can use Option.get, which will turn into an error analagous to an NPE. But it forces me to make that choice, and make it explicitly<\/em>.<\/p>\n

Even if I’m going the stupid, brute-force route and assuming that I know, without fail, that a function is going to return a non-null value… Consider an example:<\/p>\n

\n   Java: <\/em>:\n  T g = f.doSomething()\n  g.doSomethingElse()\n\n   Scala:<\/em>\n  val g: Option[T] = f.doSomething()\n  g.get.doSomethingElse()\n<\/pre>\n
 The scala case has to explicitly<\/em> deal with the fact that it’s dealing with a potentially empty value, and using a statement that asserts the non-emptiness.<\/p>\n
 But in reality, if you’re a decent programmer, you never<\/em> use .get<\/code> to directly access an option. (The only exception is in cases where you call the .get<\/code> in a context dominated by a non-empty test; but even then, it’s best to not, to avoid errors when the surrounding code is modified.)   In real code, you pretty much always explicitly de-option a value using a function like getOrElse<\/code>:<\/p>\n
\nval f: User = getUser(\"markcc\").getOrElse(new User(\"markcc\"))\n<\/pre>\n
 As I hope it has become plain, the point of avoiding NPEs through option-like type structures isn’t that somehow it makes the entire category of unexpected result value disappear. It’s that it changes the way that you code to distinguish where those errors can occur, and to force you to deal with them.<\/p>\n
 I think that ultimately, things like this are really just manifestations of the good-old static vs dynamic type wars. Type errors in a dynamically typed language are really just unexpected value errors. Strong typing doesn’t stop you from making those errors. It just takes a bunch of common cases of those errors, and converts them from a run-time error to a compile-time error. Whether you want them to be run-time or compile-time depends on the project your working on, on your development team, and on your personal preferences.<\/p>\n
 I find in practice that I get many<\/em> fewer errors by being forced to explicitly declare when a value might be null\/None, and by being required to explicitly deal with the null\/None case when it might occur. I’ve spent much less time debugging that kind of error in my year at foursquare than in the 15 years of professional development that I did before. That’s not because I magically became a better programmer a year ago when I joined foursquare. It’s because I’m using a better tool that helps me avoid mistakes.<\/p>\n","protected":false},"excerpt":{"rendered":"
So, my post on monads apparently set of a bit of a firestorm over my comments about avoiding null pointer exceptions. To show you what I mean, here’s a link to one of the more polite and reasonable posts. Ok. So. Let me expand a bit. The reason that I think it\u2019s so great that […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[54],"tags":[],"class_list":["post-1872","post","type-post","status-publish","format-standard","hentry","category-programming"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/s4lzZS-nulls","jetpack_sharing_enabled":true,"jetpack_likes_enabled":true,"_links":{"self":[{"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/posts\/1872","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/comments?post=1872"}],"version-history":[{"count":0,"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/posts\/1872\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/media?parent=1872"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/categories?post=1872"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/tags?post=1872"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}