4 ms·

> What do you do when you don't know a value? I use an explicit value to represent the absence of something specific like :id-unknown which is much more useful

> What do you do when you don't know a value? I use an explicit value to represent the absence of something specific like :id-unknown which is much more useful and safer than just throwing nil in there when a project scales. If something is nil in Clojure, you have to ask why is it nil? The answer is not always simple. It could be a bug, it could be legit missing data, a number of things. A simple typo in Clojure can give you nil. You don’t want to interpret that the wrong way.

8ytecoder 8y ago
Well, now this id-unknown would be your new null and on top of it it changes by the data type as well.
- hellofunk 8y ago
  I disagree. A keyword is not a null. And nil is a different “type” than something not nil anyway.
- maxilulu 8y ago
  It will not crash the program and is domain specific. Definitely an improvement over nil.
  - MaxBarraclough 8y ago
    Certainly not. If you are missing the code to specifically handle a null value, you hope you get a noisy explosion, not a runaway train in your program's logic. Fail-fast is a virtue. This (anti-)pattern has a Wikipedia page, complete with Criticism section. https://en.wikipedia.org/w/index.php?title=Null_object_pattern&oldid=837181279#Criticism https://en.wikipedia.org/w/index.php?title=Null_object_patte... Incidentally, Objective-C does something like this out-of-the-box. Unlike Java, where invoking a method on null causes an exception to be thrown, or C++, where you just get good old undefined behaviour, Objective-C 'defaults' to doing nothing. This is described in the Wikipedia article. Strikes me as a very bad idea.
    - elcritch 8y ago
      Well in terms of system stability I’ve usually found OS X and Obj-C GUIs to be much more stable than on any other platform. Objective C’s null handling could well be part of that. If so, what’s better for GUIs then?
      - MaxBarraclough 8y ago
        As I said, explicit fail-fast behaviour is what you want. It's far better that a bug manifest noisily and immediately, than that it go unnoticed. At the risk of just re-stating myself: In Java, if you attempt to invoke a (non-static) method on a null reference, it throws a `NullPointerException`. This is exactly what you want: it's immediately obvious to the developer, and to a user. No further damage can occur as a result of the bug. (Ignoring broader questions of exception-handling, of course.) Java pretty consistently adopts this philosophy of runtime checks everywhere, even on production builds. C#/.Net does the same. It's a valuable feature for software correctness. (Java's choice of exception name is curious given that Java has references and not pointers, but still, they have the right idea.) C++ is the opposite: if you invoke a non-static method (or 'member-function') on `null`, you get 'undefined behaviour'. Anything could happen. Hopefully the program will crash with something akin to a 'segfault', but maybe it will do something disastrous. Unlike Java, the C++ philosophy is generally performance first, and it does few runtime checks for you. C++ has its reasons, but this approach is extremely unhelpful for software correctness; it can make both bug-detection, and bug-hunting, much harder. (Incidentally, GCC and Clang feature a `-fsanitize=null` flag which gives you Java-style runtime checks, presumably with a moderate runtime performance cost. This isn't in the C++ standard, though.) Objective-C is somewhere in the middle: you don't get undefined behaviour, but neither does the system tell you when you've got a null-dereference bug. It just silently carries on, and you're left assuming that your code is working fine. There's nothing at all special about GUI code. Fail-fast is still what you want. There could be any number of technical or non-technical reasons you've found OS X GUI applications to be more stable. Null handling is just a tiny piece of the picture.
        elcritch 8y ago
- Tcepsa 8y ago
  I believe the point is that IF the problem with nil is that when it shows up you can't be sure whether it was on purpose (to indicate an "empty" value) or on accident (because an error in the code caused a variable to not get bound). By introducing a separate identifier (e.g. :id-unknown) to explicitly handle the empty-value case, it frees up nil to solely signify improperly bound variables. [EDIT: Emphasis]

8ytecoder 8y ago

Well, now this id-unknown would be your new null and on top of it it changes by the data type as well.

hellofunk 8y ago
I disagree. A keyword is not a null. And nil is a different “type” than something not nil anyway.
maxilulu 8y ago
It will not crash the program and is domain specific. Definitely an improvement over nil.
- MaxBarraclough 8y ago
  Certainly not. If you are missing the code to specifically handle a null value, you hope you get a noisy explosion, not a runaway train in your program's logic. Fail-fast is a virtue. This (anti-)pattern has a Wikipedia page, complete with Criticism section. https://en.wikipedia.org/w/index.php?title=Null_object_pattern&oldid=837181279#Criticism https://en.wikipedia.org/w/index.php?title=Null_object_patte... Incidentally, Objective-C does something like this out-of-the-box. Unlike Java, where invoking a method on null causes an exception to be thrown, or C++, where you just get good old undefined behaviour, Objective-C 'defaults' to doing nothing. This is described in the Wikipedia article. Strikes me as a very bad idea.
  - elcritch 8y ago
    Well in terms of system stability I’ve usually found OS X and Obj-C GUIs to be much more stable than on any other platform. Objective C’s null handling could well be part of that. If so, what’s better for GUIs then?
    - MaxBarraclough 8y ago
      As I said, explicit fail-fast behaviour is what you want. It's far better that a bug manifest noisily and immediately, than that it go unnoticed. At the risk of just re-stating myself: In Java, if you attempt to invoke a (non-static) method on a null reference, it throws a `NullPointerException`. This is exactly what you want: it's immediately obvious to the developer, and to a user. No further damage can occur as a result of the bug. (Ignoring broader questions of exception-handling, of course.) Java pretty consistently adopts this philosophy of runtime checks everywhere, even on production builds. C#/.Net does the same. It's a valuable feature for software correctness. (Java's choice of exception name is curious given that Java has references and not pointers, but still, they have the right idea.) C++ is the opposite: if you invoke a non-static method (or 'member-function') on `null`, you get 'undefined behaviour'. Anything could happen. Hopefully the program will crash with something akin to a 'segfault', but maybe it will do something disastrous. Unlike Java, the C++ philosophy is generally performance first, and it does few runtime checks for you. C++ has its reasons, but this approach is extremely unhelpful for software correctness; it can make both bug-detection, and bug-hunting, much harder. (Incidentally, GCC and Clang feature a `-fsanitize=null` flag which gives you Java-style runtime checks, presumably with a moderate runtime performance cost. This isn't in the C++ standard, though.) Objective-C is somewhere in the middle: you don't get undefined behaviour, but neither does the system tell you when you've got a null-dereference bug. It just silently carries on, and you're left assuming that your code is working fine. There's nothing at all special about GUI code. Fail-fast is still what you want. There could be any number of technical or non-technical reasons you've found OS X GUI applications to be more stable. Null handling is just a tiny piece of the picture.
      - elcritch 8y ago
Tcepsa 8y ago
I believe the point is that IF the problem with nil is that when it shows up you can't be sure whether it was on purpose (to indicate an "empty" value) or on accident (because an error in the code caused a variable to not get bound). By introducing a separate identifier (e.g. :id-unknown) to explicitly handle the empty-value case, it frees up nil to solely signify improperly bound variables. [EDIT: Emphasis]