Hacker News Reader

Comment by nivertech | Hacker News Reader

Error Handling in Elm

https://twitter.com/nivertech/status/1413392990211657729

It looks like Maybe/Option is just a Booleans-in-disguise. As I'm in favor of banning Booleans (and if-statements), so it makes sense to ban Maybe/Option-s also.

View on HN

> It looks like Maybe/Option is just a Booleans-in-disguise.

This is a unique take. Care to expand?

Not the person you're asking, but I may have insight.

Realistically, it's no different, checking if something is null or None. Yeah, some languages have a lot of sugar around optional thanks to rich type systems.

Imagine the following pseudo rust code:

if let Some(x) = x {}

is not that different from

if x != null {}

Or any other type of boolean check.

I think you have to be around optional long enough to understand the benefits.

> Realistically, it's no different, checking if something is null or None.

That is correct. However, what languages with null lack is a way to say "See this String here? This is actually a String - not the absence of a String".

It is nonsense to encode both A and lack-of-A as A.

Yeah, and it's annoying. One of my most hated things about proto3 - is this string empty or just not set? (they added optional back now, but everything is already optional)

But it is different because you can't dereference x without the check. In other words, you can't really make an accident.

My language has maybe<T>, and I have automatic "re-wrapping" (not sure if there is a better term). where

For example, with

  record R { int x; }
  maybe<R> r;

I can access r.x yet the type is maybe<int>.

True. I'm just playing devil's advocate here. In unsafe rust, technically deref you can for types that have niche optimization.

Well, you can have nested options. Some(None) is different from a None

It also has nice ergonomics with bind, map and such. And the fact that a None is not even comparable to an 'a.

Oh, I'm not arguing about the usefulness of optional - I love them.

Mainly, there are 3-4 reasons for considering alternatives to using booleans:

1. Booleans are primitive types without rich domain-specific information or context. When using true/false, it can be more beneficial to employ more descriptive options such as AnsweredYes/AnsweredNo, PositiveResult/NegativeResult, LightsOn/LightsOff, or UserOnline/UserOffline. Mixing and matching booleans of different domain types can lead to errors that the compiler may not catch. For instance:

    bool isLightsOn = true;
    bool isUserOnline = false;
    bool isAdmin = true;

    if(isLightsOn && !isUserOnline && !isAdmin) {
      ...
    }

compare with Elixir:

    case {lights_status, connection_status, user_role} do
       {:lights_on, :user_offline, :unprivileged_role} -> ...
       ...
    end

The example above is basically a Decision Table [1].

While booleans can still be used in system code or libraries, it is advisable to avoid them in application code.

2. Preemptive pluralization [2] makes it easier to refactor code. Going from two options to three is simpler than transitioning from one option to two. Consider the following examples:

    bool isLightsOn;

    type LightsStatus = Bool

    type LightsStatus = LightsOn | LightsOff

Suppose there is a new requirement to support dimmed lights. In the former case, significant code refactoring is necessary. In the latter case, adding a new option to the sum type is straightforward, and the compiler assists in handling the changes:

    type LightsStatus = LightsOn | LightsOff | LightsDimmed

Similarly, let's examine another scenario:

    boolean isOnline;

    type ConnectionStatus = Bool

type ConnectionStatus = Online | Offline

The latter option can easily evolve into:

    type ConnectionStatus = Online | Offline | BadConnectivity

and later:

    type ConnectionStatus = 
        | OnlineMobile
        | OnlineFastInternet
        | Offline
        | BadConnectivity
        | IntermittentConnection
        | ConnectedToMeshnet

3. Booleans encourage the overuse of conditionals and branching, including nested branching. This can increase the cyclomatic complexity [3] of the code. It is important to manage cyclomatic complexity to keep the codebase maintainable and easier to reason about.

Also see "Get rid of those boolean function parameters" [4].

4. Booleans can indicate whether something occurred, but they lack both the necessary context and the timestamp indicating when the event took place. However, by transforming booleans into nullable or optional timestamps, one can achieve a rudimentary implementation of Domain Events or Event Sourcing.

   user_connected_at:   nullable(Timestamp)
   lights_turned_on_at: nullable(Timestamp)
   record_deleted_at:   nullable(Timestamp)

NOTE: I'm not advocating for the pattern above, but it's widely used because of the limitations inherent in booleans.

References:

[1] https://en.wikipedia.org/wiki/Decision_table

[2] https://www.swyx.io/preemptive-pluralization

[3] https://en.wikipedia.org/wiki/Cyclomatic_complexity

[4] https://mortoray.com/get-rid-of-those-boolean-function-param...

That's great, you just explained why ADTs are superior to booleans. My question was why are ADTs the same as booleans?

I didn't wrote that ADTs are the same as boolean, only that optional types (Maybe/Option) are the same.

For 2 reasons:

1. the 2-case, so it will be harder to refactor once you add additional cases

2. they're missing domain/context/intent (Why value is missing?)

So, Maybe/Option is an improvement over null/nil and boolean flags, and ADTs/FSMs are improvement over Maybe-s.

  > I'm in favor of banning Booleans (and if-statements)

I would love to hear your reasoning on this. I think that either I'm misunderstanding you, or one of us is crazy ))

I've usually seen it expressed as:

> instead of accepting a boolean argument, write a new function

Which can be expanded to

> instead of an if-statement, write a new function

You can't remove branching from software (otherwise, just create a jpeg), but you can structure your software in such a way that it appears not to branch.

I think it's weird, but I worked with someone like that and learned a few interesting things (for example, I usually do write a new function instead of adding an optional/boolean argument -- unless it makes things worse for the caller because the argument comes from outside the context/domain). But with all due respect to people like this, it's bananas to do it all the time.

https://news.ycombinator.com/item?id=35955938

Wow, I hope I never have to work with you or anybody who shares your opinions on this topic

Reply on news.ycombinator.com