Hacker News Reader

Comment by vikingcaffiene | Hacker News Reader

The author makes compelling arguments but I respectfully disagree with their conclusion. Null exists for cases where you want to set the the absence of a value intentionally. It is literally the value of having no value. Undefined exists for cases where no value has yet been set. It's a subtle but important difference and allows a certain amount of nuance and expressiveness in ones code to communicate intent. I do think it's fair to say that a lot of devs don't use them that way. They _are_ for separate use cases though.

View on HN

In functional programming the Option type exists to make the 'literally no value' case more explicit.

https://en.m.wikipedia.org/wiki/Option_type

If you are using TypeScript (TFA mentions it), fp-ts provides a good functional programming layer. Although if you aren't already familiar with functional programming it's going to be hard as the documentation is rather lacking.

https://github.com/gcanti/fp-ts/blob/master/src/Option.ts

The Option type isn’t really something owned by functional programming. Union types exist just fine in imperative and even declarative programming.

And the magic sauce that makes Option nice to use is the type checker that can force you to handle the None case.

I would go even further that even if the semantics are a little clunky (wrap/unwrap) any programming language can implement Option.

True but you can’t restrict the type if your language is dynamic.

The option type also prevents you from accessing the value if it's absent. Something a C union cannot do. Is there any example of options in an imperative language that would predate ML (which AFAIK introduced Some/None as the variants of option)?

C can’t do that. But imperative programming can. Nothing about type based pattern matching is constrained to FP.

Not that I'm disagreeing with you in any way, but it's worth recognizing that imperative languages typically do pattern matching and type constraining in a declarative manner. So one could make an argument that what you're saying is only true because imperative languages are not forbidden from employing FP. If a language uses declarative constructs, then it's not a wholly imperative language.

I really don't think that FP should be able to take claim for this. Or, at the very least, I don't think the sort of evangelical FP should. Type pattern matching isn't all that different from virtual dispatch if you squint.

If the FP community wants to say that impure languages have been "doing FP" for decades then great! The religious war is over! We can happily have mixed paradigm languages and move on. But that's not what I'm seeing.

I like (explicit) nullability as syntactic sugar over Option/Maybe. Kotlin gets this right.

fp-ts had many niceties in it, but in Typescript, types are already non-nullanle by default; is there any reason to use Option<string> over string|null? You'd have the same exact type safety either way.

It's a bit high level in that the benefits aren't obvious until you buy into other functional concepts, but basically it's that Options can be layered i.e. Option<Option<string>> is possible. If you just use ordinary union types there's no way to express that.

As an aside, TypeScript is very unsafe by default, and still relatively unsafe with strict mode enabled. Stringent fp-ts usage bypasses these issues.

> still relatively unsafe with strict mode enabled

Is it? I have been using Typescript more and more these last few years, and lately haven't really experienced any issues where it's type system failed me.

To clarify, I'm not trying to argue against your point, genuinely curious to learn if fp-ts can really improve my code quality in production.

It is, for example accessing an array or record doesn't unionise the returned value type with undefined, though this particular gaping hole of unsafety is being addressed in 4.1 with a new flag.

Beyond that there's functions that throw/reject doing so outside the type system, something solved by Either/Option/similar types in fp-ts.

The biggest benefit of fp-ts though is that it makes you think functionally. If you're dead set against that, then there are plenty of other libraries that give you types/wrappers like these without having to use pipe/flow (two functions you'll want to use before anything else in fp-ts).

> Null exists for cases where you want to set the the absence of a value intentionally.

Only in Javascript though. In Typescript this would be clear from the fact that the type has the property.

Of course Typescript is not Javascript, but nobody should use plain JS anymore.

What if you want your property to have a default value, such as null?

null is not a very good default value in most cases though, since the operations you do with values of "real" types will not work on null. Therefore actually using your "default" value is pretty much guaranteed to be a bug, identical to using an uninitialized variable.

It would be better to just error out and not allow the uninitialized usage at all, but unfortunately that's not possible in Javascript.

That's the point though. I can easily do a null check to handle whether or not to process/use the value.

For instance, if I'm fetching some data I usually want to initialize the data variable as null for a couple of reasons.

1) null is not truthy, empty arrays and objects are

2) It shows that the variable is supposed to be filled, unlike undefined

If you want your property to have a default value, give it an actual default value, not the explicit absence of one (kind of defeats the point to set a default value of null).

It doesn't defeat the purpose of a default/initial value because it shows that it should be filled.

When I'm using hooks in React this is very common.

You must give an initial value, and at some point in the future you will update it.

By setting the value as null initially I can easily check whether the variable has been filled or not. This is most important for initially rendering the UI.

I think the parent comment was saying that you could always make that explicit.

> By setting the value as null initially I can easily check whether the variable has been filled or not

I don't think there's anything wrong with this but it does mean your variable can be in two states~, one where "it shows it should be filled" and one where the value is present and can be used.

You can use null for this if you want and most programmers will understand these states. You can also choose to make this even more explicit by creating a type that expresses this.

example in Kotlin but you get the idea (applies to any variable in any language)

    sealed class ThatVariableYouCareAbout {
     object ShouldBeFilled: ThatVariableYouCareAbout()
     data class HasBeenFilled(val x: String): ThatVariableYouCareAbout()
    }

    // usage
    fun test(thatVar: ThatVariableYouCareAbout) {
      if(thatVar is ShouldBeFilled) {
         //
      } else if(thatVar is HasBeenFilled) {

      }
    }

Seems overly verbose but that's the reality of the variable you're talking about. This represents those states you described. `null` is a crutch in most languages for representing this state and the cause of a lot of subtle bugs (people use it to reset/clear out values too which in reality could represent a different state depending on what you _really_ want the variable to represent).

All that being said, null is generally understood to have this meaning~ and I have/do use it but with an understanding that it's of lazyness/not wanting to be overly verbose (language consideration).

The case you are describing is very familiar to me (rendering UI with initial states through a framework like react) and having an explicit type for the initial state is the ideal, or at least the most explicit, solution.

Option works for 2-state variables like this

Reply on news.ycombinator.com