Option and null in dynamic languages

https://codewords.hackerschool.com/issues/one/option-and-null-in-dynamic-languages

by luu • 12 years ago

59 50 12 years ago

codewords.hackerschool.com

wsh91• 12 years ago

We need more approachable introductions to types--they're all over this issue. Good stuff.

NateDad15• 12 years ago

I;m sorry there wasn't more talk of Go, I think the author might like some of what Go has to offer.

For example, the comparison about maps at the bottom would benefit from seeing the way Go maps work.

There's the single assignment form:

    foo := myMap[key]

This returns the zero value of the value type in the map if the key doesn't exist in the map.

and the two valued assignment:

    foo, ok := myMap[key]

This returns true or false in ok based on whether the value exists, zero value for foo if it doesn't exist.

This is actually very like an option type, but what go is missing is the compilation-requirement that you check ok before using the value.... however, go does have the compilation requirement that the ok value gets used somehow, or it'll give you an unused variable compilation error. In practice, this works quite well as a more flexible option type for the simple either/or types (either there was a value or an error).

jmgao• 12 years ago

Go is quite possibly the worst possible language for this example. You don't have generics, so the best you can do with an option type is return an interface {}, and any error checking you have to do has to be done manually. The problem is not that there is no way to do it properly in other languages (well, except lua), the problem is that the most natural way to do it is wrong.

comex• 12 years ago

I think this is too harsh. Out of the languages mentioned in the article, at least one (JavaScript) has no builtin lookup-or-throw method, and another (Ruby) requires a method call that's significantly uglier than the normal [] syntax, slightly discouraging its use. I don't know enough about the others (besides Python) to speak for them. In comparison, Go's multiple-return lookup thingy might be less natural/obvious than straight usage of foo[bar], but not by much.

NateDad15• 12 years ago

Go has effectively built in option types - multiple returns... And almost every function that can fail uses them. That's what I was trying to say. No, you can't implement actual option types in any kind of reasonable way, but you don't need to.

stormbrew2• 12 years ago

The thing that's always annoyed me about the way go does this, where extra return values are treated somewhat specially to encourage you to actually check them, if your function returns only a success/failure condition you're either forced to return a dummy value for no reason and ignore it, or allow the condition to go unchecked.

Meanwhile, the actual concept of option type has been around for ages and could have been used instead of trying to twist MRV into it.

Thankfully, all the other newer languages are doing the right thing imo.

NateDad15• 12 years ago

Not sure what you mean by needing a dummy value if your function only returns success/failure. That's what a boring old error return is for.

    func foo() error

panzi• 12 years ago

Well, Go isn't a dynamic language.

NateDad15• 12 years ago

Heh, good point :)

Dewie9• 12 years ago

This returns the zero value of the value type in the map if the key doesn't exist in the map.

Wow, that's quite horrible (for a static language, anyway). So if my map returns `0`, I can't really be sure whether that is the zero-value (no value at this key), or that the value that I queried actually is `0`.

This returns true or false in ok based on whether the value exists, zero value for foo if it doesn't exist.

Better, but still unnecessarily error-prone.

however, go does have the compilation requirement that the ok value gets used somehow, or it'll give you an unused variable compilation error.

OK, I can see how that could alleviate the problem in practice: maybe in most contexts, there aren't anything more sensible to use the `ok` variable for than to check its value. In that case, the programmer will be alerted if he tries to use the `foo` variable without checking `ok` first.

ajuc5• 12 years ago

Wow, that's quite horrible (for a static language, anyway). So if my map returns `0`, I can't really be sure whether that is the zero-value (no value at this key), or that the value that I queried actually is `0`.

Replace "0" with null, and it's no different from Java maps.

finishingmove• 12 years ago

I could swear I read the exact same article somewhere else a couple of months ago.

Anyway, I fail to see how either raising an exception or returning None (which the author recognizes as Python's version of null/nil) is anything at all like an Option value (as opposed to "null-like")...

chcokr• 12 years ago

I sense a connection, for example, between Rust's `fn foo<T>() -> Result<T, E>` and Java's `void foo<T, E>() throws E` (this might be incorrect Java syntax). I'm not entirely confident though.

barosl• 12 years ago

I find Java's checked exception similar to Option type, because they are all part of the function's type. You cannot pass alone without checking the possible failure case.

masklinn• 12 years ago

Anyway, I fail to see how either raising an exception is anything at all like an Option value

The author asserts their similarity in that they completely differentiate lookup success and failure, there is no situation under which success and failure can be confused.

zallarak• 12 years ago

If a language makes it easy to conflate nil and absence, to write code that does not reliably distinguish between success and failure, then bugs are sure to follow.

This is why after working on large apps in Ruby and Python, I strongly prefer Python. Accessing a non-existent key in a Ruby dictionary returns nil, whereas in Python a KeyError exception is thrown.

If you store nil in a Ruby dictionary, then you can't test for membership unless you use hash.fetch.

Pxtl• 12 years ago

Yup. Python is how I learned to stop worrying and love exceptions.

nitrogen• 12 years ago

You can also use Hash#include?.

stevedt• 12 years ago

prefer hash.fetch(:key) over hash[:key]. fetch raises NoKeyError if key not in hash.

dschiptsov3• 12 years ago

Just None, like Just Nothing is nonsense.

If you have a special marker for something, just explicitly check for it each time.

dschiptsov3• 12 years ago

OK, lets make it long and explicit.

Asserting that an obscure, optional either-of type is some fundamental concept every single language has been overlooked is, of course, nonsense.

The fundamental concept is notion of "nothingness", "emptiness", what other languages call NIL. Without this a language would be very clumsy, like Math without zero.

The notion of empty vs. non-empty is captured in so-called "either-of" types. The most obvious example is '() - an empty list. Conceptually, it is a List, but it is also indicator of "emptiness", of "nothing inside".

A List is an "either-of type" itself, so it does not require any additional specialize type to capture the notion that it could be empty - it already has it.

Another example is so-called "C-strings". There is notion of end-of-string marker, so a string could be viewed as a list instead of an array of characters. In this case (of a list) we don't have define anything special for "empty string" - the notion of "just end-of-string marker" is good-enough.

Again. This Just/Nothing type in Haskell is nothing special or fundamental. It is an optional, non-essential construct.

tome• 12 years ago

The article explains exactly why it is useful to be able to distinguish `Nothing` from `Just Nothing`.

dschiptsov3• 12 years ago

Yeah, instead of having only "nothing" - NIL - they prefer to have "nothing-in-a-box", and "nothing-in-a-bag", and "nothing-in-a-suitcase". Nothing-in-a-container-of-this-kind.

Due to such over-abstraction madness for sake of abstraction they end up with Java or Javaesque Haskell code.

VeejayRampay• 12 years ago

I guess I would have written the Ruby version as

    def values_in(keys, dict)
      dict.slice(*keys).values
    end

Though I suppose it's not the point of the article.

Option and null in dynamic languages

Related Stories