7 ms·

For statically typed languages this is definitely an issue, but for dynamic languages less so. In Python, I wouldn't use an optional value, x is None seems

by ant6n 11y ago

For statically typed languages this is definitely an issue, but for dynamic languages less so. In Python, I wouldn't use an optional value, x is None seems to be just fine. I'm still waiting for std::optional for C++.

lmm 11y ago
It's only not an issue in dynamic languages in the sense that you have the same issue anyway without null because you have no type safety at all.
- kazinator 11y ago
  You have a ton of type safety in Python, which is one reason why Python programmers are cranking out large bodies of working code representing all kinds of applications that Just Work. "No type safety at all" means you can misuse a value of one type using an operation that is appropriate for a different type, and some nonsensical behavior silently occurs (or perhaps some nonportable behavior that you sneakily intended). This characterizes assembly languages, certain machine-oriented languages like BCPL, and some immature dynamically typed languages which omit run-time-type checks (the type information is there, but not checked, so that string_length happily tries to operate on an integer, so that a type problem occurs in the interpreter's kernel itself.)
  - lmm 11y ago
    Python has some safety checks that are missing in other languages, and this is a good thing. But it's misleading to call them "type safety", because they aren't connected to anything that can be meaningfully called a type system - all those checks happen at the value level (e.g. you can make a particular integer amenable to string_length, by monkeypatching the relevant methods onto it).
astral303 11y ago
boost::optional and call it a day. http://www.boost.org/doc/libs/1_59_0/libs/optional/doc/html/index.html http://www.boost.org/doc/libs/1_59_0/libs/optional/doc/html/...
- ant6n 11y ago
  Well, for now we're using something like template<class T> using std::optional = boost::optional<T>;
dragonwriter 11y ago
In dynamically typed languages, there are still problems with flat Null/Nil/None that are addressed by optional values (the biggest comes when you use multiple operations that can return null but the single null value loses the source of the null; using optional values these often are differentiated easily as being either an "outer" null -- e.g., None -- or an "inner" null -- Some(None).) In fact, the example in the article of the Ruby K/V store illustrates this problem. If optional values were used instead of an ambiguous nil for both cases, there would be two distinct results: * Some(nil) -- or something of similar shape -- where there is a value for the key, and it is nil, * nil where there is no value. Obviously, the typesafety issue doesn't exist for dynamic languages, but the composability/API quality issues do -- from the numbered issues in the article, I'd say at least #s 2, 3, 4, and 7 apply to dynamic languages in general.
- nycticorax 11y ago
  But as the writer mentions, optionals are a lot like lists with either zero or one elements, so it seems like many of these issues could be dealt with by simply returning a list, which would have zero elements if (in that example) the key was missing, or one element is the key was present. (And that single element would be nil if that was the value for that key.)
  - dragonwriter 11y ago
    Sure, lists make a decent "poor man's Maybe"; and many dynamic languages have facilities that make that a decent solution. In dynamic OO languages, there's some Maybe/Optional-specific operations you might want to have to more clearly express certain patterns which make it with having specific types.
seertaak 11y ago
Assuming x is not a boolean, I think not x would be sufficient in the case of Python.
- dragonwriter 11y ago
  in Python (even for non-Booleans) not x is not equivalent to "X is not None", since empty lists, zero, etc., are not truthy in a Boolean context.
  - seertaak 11y ago
    Ok, yeah, you're right -- I forgot those other cases. Thanks for the clarification.
fixermark 11y ago
"Python: What You Gain In Prototyping Efficiency And Speed, You Lose In Having To Exhaustively Unit Test Every Line Of Executable Code, Because the Interpreter Cannot Tell You That You Typo'd A Function Name Until It Tries And Fails To Call It At Runtime(TM)" ;)

by ant6n 11y ago

lmm 11y ago

It's only not an issue in dynamic languages in the sense that you have the same issue anyway without null because you have no type safety at all.

kazinator 11y ago
You have a ton of type safety in Python, which is one reason why Python programmers are cranking out large bodies of working code representing all kinds of applications that Just Work. "No type safety at all" means you can misuse a value of one type using an operation that is appropriate for a different type, and some nonsensical behavior silently occurs (or perhaps some nonportable behavior that you sneakily intended). This characterizes assembly languages, certain machine-oriented languages like BCPL, and some immature dynamically typed languages which omit run-time-type checks (the type information is there, but not checked, so that string_length happily tries to operate on an integer, so that a type problem occurs in the interpreter's kernel itself.)
- lmm 11y ago
  Python has some safety checks that are missing in other languages, and this is a good thing. But it's misleading to call them "type safety", because they aren't connected to anything that can be meaningfully called a type system - all those checks happen at the value level (e.g. you can make a particular integer amenable to string_length, by monkeypatching the relevant methods onto it).

astral303 11y ago

boost::optional and call it a day. http://www.boost.org/doc/libs/1_59_0/libs/optional/doc/html/index.html http://www.boost.org/doc/libs/1_59_0/libs/optional/doc/html/...

ant6n 11y ago
Well, for now we're using something like template<class T> using std::optional = boost::optional<T>;

dragonwriter 11y ago

In dynamically typed languages, there are still problems with flat Null/Nil/None that are addressed by optional values (the biggest comes when you use multiple operations that can return null but the single null value loses the source of the null; using optional values these often are differentiated easily as being either an "outer" null -- e.g., None -- or an "inner" null -- Some(None).) In fact, the example in the article of the Ruby K/V store illustrates this problem. If optional values were used instead of an ambiguous nil for both cases, there would be two distinct results: * Some(nil) -- or something of similar shape -- where there is a value for the key, and it is nil, * nil where there is no value. Obviously, the typesafety issue doesn't exist for dynamic languages, but the composability/API quality issues do -- from the numbered issues in the article, I'd say at least #s 2, 3, 4, and 7 apply to dynamic languages in general.

nycticorax 11y ago
But as the writer mentions, optionals are a lot like lists with either zero or one elements, so it seems like many of these issues could be dealt with by simply returning a list, which would have zero elements if (in that example) the key was missing, or one element is the key was present. (And that single element would be nil if that was the value for that key.)
- dragonwriter 11y ago
  Sure, lists make a decent "poor man's Maybe"; and many dynamic languages have facilities that make that a decent solution. In dynamic OO languages, there's some Maybe/Optional-specific operations you might want to have to more clearly express certain patterns which make it with having specific types.

seertaak 11y ago

Assuming x is not a boolean, I think not x would be sufficient in the case of Python.

dragonwriter 11y ago
in Python (even for non-Booleans) not x is not equivalent to "X is not None", since empty lists, zero, etc., are not truthy in a Boolean context.
- seertaak 11y ago
  Ok, yeah, you're right -- I forgot those other cases. Thanks for the clarification.

fixermark 11y ago

"Python: What You Gain In Prototyping Efficiency And Speed, You Lose In Having To Exhaustively Unit Test Every Line Of Executable Code, Because the Interpreter Cannot Tell You That You Typo'd A Function Name Until It Tries And Fails To Call It At Runtime(TM)" ;)