Is your programming language unreasonable? (2015)

So this essentially means there can never be a NULL object assigned to anything... how is this possible? is it avoided by throwing exceptions instead of returning NULL?

Re: Is your programming language unreasonable? (2015)

#5

Post by bollu » Sat, Oct 10, 2020, 10:29 AM UTC

gitgud wrote: post #4

> " 4. Objects must always be initialized to a valid state. Not doing so is a compile-time error. " So this essentially means there can never be a NULL object assigned to anything... how is this possible? is it avoided by throwing exceptions instead of returning NULL?

You use sum types / optional / Maybe / Option / whatever your language calls them. Such a value can have two states: 'None', where it calls no value, and 'Some(t)',where it carries a value 't'.

For example, a division function could return (1) 'None' for 'div(20, 0)' because division-by-zero is undefined, and return (2) 'Some 10' for 'div(20, 2)' because 20/2 is defined and is equal to '10'.

Re: Is your programming language unreasonable? (2015)

#6

Post by mbogun » Sat, Oct 10, 2020, 10:33 AM UTC

bollu wrote: post #5

gitgud wrote: post #4

> " 4. Objects must always be initialized to a valid state. Not doing so is a compile-time error. " So this essentially means there can never be a NULL object assigned to anything... how is this possible? is it avoided by throwing exceptions instead of returning NULL?

You use sum types / optional / Maybe / Option / whatever your language calls them. Such a value can have two states: 'None', where it calls no value, and 'Some(t)',where it carries a value 't'. For example, a division function could return (1) 'None' for 'div(20, 0)' because division-by-zero is undefined, and return (2) 'Some 10' for 'div(20, 2)' because 20/2 is defined and is equal to '10'.

Three is a great article about option tyle in the context of F# here: https://fsharpforfunandprofit.com/posts/the-option-type/

Re: Is your programming language unreasonable? (2015)

#7

Post by danielinoa » Sat, Oct 10, 2020, 10:35 AM UTC

gitgud wrote: post #4

> " 4. Objects must always be initialized to a valid state. Not doing so is a compile-time error. " So this essentially means there can never be a NULL object assigned to anything... how is this possible? is it avoided by throwing exceptions instead of returning NULL?

Not quite. There can be a null value if the object type allows for it, think Optional. What you can't have is an undefined object, as you could in Javascript for example.

Re: Is your programming language unreasonable? (2015)

#8

Post by rootsofallevil » Sat, Oct 10, 2020, 10:38 AM UTC

> I don’t care what my language will let me do, I care more about what my language won’t let me do.

I think this is the best summary of the article. In short, please protect me from my own stupidity and/or laziness.

Re: Is your programming language unreasonable? (2015)

#9

Post by Smaug123 » Sat, Oct 10, 2020, 10:41 AM UTC

gitgud wrote: post #4

> " 4. Objects must always be initialized to a valid state. Not doing so is a compile-time error. " So this essentially means there can never be a NULL object assigned to anything... how is this possible? is it avoided by throwing exceptions instead of returning NULL?

If you forget everything you ever learned about programming, and then I ask you for an integer, you're never in a million years going to reply "null"; the existence of "null" is something you had to learn. A language could simply not have a concept of "null". Even an OO language could have no concept of "null".

In practice, it's useful to be able to answer "I'm sorry, Dave, I can't do that". Some languages do that by silently and implicitly allowing this special value "null" in a return type. Some languages allow you to throw an exception (again without ever having declared that this is something you might do). But some languages take one of those approaches and make it explicit: in the two cases, you have the "option"/"maybe" type, or checked exceptions. Either of these explicit methods let a function declare that it may fail, and moreover the language forces you to handle the possibility of failure in any function which may fail.

The "reasonability" comes from the fact that the language forces you to be explicit about the possibility of failure, rather than implicitly allowing all functions to fail.

Re: Is your programming language unreasonable? (2015)

#10

Post by nullsense » Sat, Oct 10, 2020, 10:42 AM UTC

gitgud wrote: post #4

> " 4. Objects must always be initialized to a valid state. Not doing so is a compile-time error. " So this essentially means there can never be a NULL object assigned to anything... how is this possible? is it avoided by throwing exceptions instead of returning NULL?

>So this essentially means there can never be a NULL object assigned to anything... how is this possible?

I believe Crystal doesn't let anything be null either. It's quite interesting.