> This is of course a textbook case for Haskells Maybe concept. You can have a type that is a Maybe Int, and that means it have a value or it can be Nothing. Thus, you encompass the edge case of not having the value available

If you encompass it this way. Literally nothing stops you from encoding this behavior in Haskell. Because the behavior you described is *if revenue is equal to zero, display it as N/A".

No magic monad will prevent this.

No, but it's the difference between implicit and explicit stupidity. All of us do implicit stupidity all of the time - it's human nature (or more accurately a side effect of working in a difficult field). When transformed into a choice between explicit stupidity, or doing things the right way, we instead usually choose to to do things the right way -- or at minimum do it the wrong way to test something out then change it to the write way. Being explicit is what makes that change likely to happen, rather than just be ignored.

No. No matter how much you dress it with words, technology is not magic. Monads are not magic. Haskell is not magic.

If your data and/or problem is modeled as "if 0 then N/A" no amount of "human nature implicitly explicitly transformed" will help you.

Dealing with non-existent data as opposed to "value = 0" is just as natural in Java, C++ or Javascript as it is in Haskell. And yet, that didn't help.

> You can create a type that can encompass all kinds of edge cases and information about them.

This is not unique to functional programming languages.

Haskell was definitely a trailblazer for this, but plenty of conventional languages support this now with relative ease.

Any language with a type system at all can create a Maybe type. The difference is that failing to handle the None case is a runtime exception in most languages where in Haskel/Rust it won’t compile.

I don’t know of any mainstream language that has bolted on that level of verification.

C.

  typedef struct{int filled; union{void* data;} val;} maybe;

How does that fail at compile time if you try to read a value when there is none?

Some of Dawson Engler’s work helps solve this problem, starting around [1]. In that, he shows us how to write custom compiler rules in a high-level language. These rules are sufficient to enforce that maybe type. In another paper, Engler (or one of his several talented students, can’t remember now) shows us how to automatically infer many of these rules.

[1] https://web.stanford.edu/~engler/mc-osdi.pdf

If you try to use it val directly, it fails. You must unpack it first.

To do something like x.get() in Scala when x is empty is a runtime error, not a compile-time error.

Scala3 and Kotlin.

You mean Scala 2. And likely even Scala 1 had this. (Scala 3 is still in development).

But Kotlin? Since when does Kotlin have pattern matching with exhaustive checks? Also it does not have an `Maybe a` / `Option[A]` type out-of-the box.

Kotlin will do exhaustive checks in a `when` block when it is an expression. You can add a `.let { }` at the end of the when statement if you want to enforce this and not really return anything.

    sealed class Communication
    data class Email(val emailAddress: String) : Communication()
    data class Shouting(val preferredName: String) : Communication()
    object HiveMind : Communication()

    fun exhaustiveWhen(comm: Communication) {
        // not exhaustively checked (will compile)
        when (comm) {
            is Email -> println("sending email to ${comm.emailAddress}")
        }

        // *is* exhaustively checked (error at compile time)
        //  must add HiveMind or 'else' branch
        val result = when (comm) {
            is Email -> println("sending email to ${comm.emailAddress}")
            is Shouting -> println("HELLO, ${comm.preferredName}!")
        }

        // *is* exhaustively checked
        when (comm) {
            is Email -> println("sending email to ${comm.emailAddress}")
            is Shouting -> println("HELLO, ${comm.preferredName}!")
        }.let {  }
    }

Sure. But that doesn't look helpful to me as it works only sometimes…

Even the syntax can be made less awkward[1] this look still like a wonky hack to me where the user can do way to much wrong.

[1] https://proandroiddev.com/til-when-is-when-exhaustive-31d69f...

Kotlin distinguishes between nullable and not-null references, which is an alternative to the maybe type. It serves roughly the same purpose, to replace runtime errors with compile-time verification that you haven't missed a corner case.

It's not an alternative for a Maybe Monad. It's an orthogonal concept.

Whether a type is nullable or not is a property of the type. This creates more or less two mirror universes of types, and you can't mix even "the same" types from that incompatible universes.

An Option type is on the other hand side a distinguished parametric type on its own (I wrote `Maybe a` / `Option[A]` for a reason). It can "wrap" arbitrary other types without "infecting" those with the nullability property. Being a proper parametric type makes `Maybe` / `Option` also "just a type constructor". Therefore it can be composed with other types and type constructors according to common rules. `Maybe` / `Option` doesn't require any special rules in the language (which would make the language more difficult to learn and use)!

Also `null` is very different form `Empty` / `None`: A null value can still "sneak in" through arbitrary references and cause run-time errors if one has to interoperate with a "null unsafe" language or system (and that's more or less "the whole universe" out there). A `None` can not "sneak in" as it can be only assigned to something of `Option` type. Sure this doesn't solve the "null problem" as such but one can at least distinguish the cases where the model value is really optional, and the cases where one needs to deal with `null`s coming (potentially) form the outside world. In the one case one will use the Option type throughout the rest of the program, in the other case one will preform some null-check as early as possible and "unwrap" the underlying none-null value to work with it directly thereafter.

that prevents you from assigning null to a non-nullable reference. does it also error if you dereference a nullable reference without first checking if it's null?

Ive noticed other languages with this feature, they call them optional types, you can pass in a null or a type value.

/s slightly, maybe more snarky, but seriously, optional types are way overhyped. Null objects are far more useful than optionals. Optionals tend to leak all over the show.

The point of optionals is that they leak, and leak visibly. You cannot use an optional where a non-optional is expected, whereas in C nothing will stop you from writing `x->y` when x is, or might be, NULL. Thus the optional (and non-optional) types turn null pointer errors into compiler errors.

If you wish to reduce "leakiness", you can dispatch on the null-ness of the variable; Swift lets you write `if let x = x { /* x is non-optional in here * / }`, which binds a non-optional value inside the braces, and `guard let x = x else { return } /* x is non-optional now * /` which binds a non-optional value after the braces. So as soon as you consume an optional value, you are free to "un-leak" it and extract its value (if it has one) immediately.

I upvoted you because I think it's unfair that you are being downvoted while contributing to the discussion, that said you are completely wrong. Without Optional/Maybe nulls leak everywhere except you have no idea where they are. This leads programmers to engage in defensive programming for all references since there is nothing to help them understand what they should expect to be null in some cases. Optional/Maybe encourages good data modelling by making values that might be missing very clear. It encourages a style of programming that eliminates these issue via better modelling or by rejecting bad data earlier.

For example consider a network response that in a JS app might be passed around as an opaque object. In a language like Swift this is infeasible, you have to transition from the network serialized version to concrete models at the network layer. If you encounter mismatches in the expectation of what is optional you have to handle it here at the edge of the program. This enables massively safer code and makes reasoning about your program much simpler if anything.

As a concerete example say an API response tells you if a user is verified(for some domain specific definition of "verified"), additionally you want to know when they were verified maybe to give them a hint when they need to do it again. You coudl model this as:

    {
      "verified": false,
      "verified_at": null
    }

before they have verified and

    {
      "verified": true,
      "verified_at": "2020-02-24T15:31:12Z"
    }

after they have verified.

In Swift this would then be modelled as

    struct Users {
        let verified: Bool
        let verifiedAt: Date?
    }

However this introduces an Optional which complicates code that needs to deal with users who are verified or not. Instead you could model the same thing and avoid this issue as:

    {
      "verification_status": {
        "status": "unverified"
      }
    }

for the unverified case and

    {
      "verification_status": {
        "status": "verified",
        "at": "2020-02-24T15:31:12Z"
      }
    }

for the verified case. In Swift this can be nicely modelled without any Optionals using an enum

    enum VerificationStatus {
        case unverified
        case verified(Date)
    }

    struct User {
        let verificationStatus: VerificationStatus
    }

Better optional value visibility leads to better data modelling.

Nulls leak exactly as badly as optionals, except it's additionally impossible to tell where nulls have leaked to.

Actually, nulls leak worse than optionals, because it's impossible to tell where nulls have leaked to (so you end up forgetting to filter out a null at a interface where you would have decided to filter out a maybe).

I don't understand. In this situation an optional type is a reasonable solution to the problem: None => N/A, Some(0%) => 0%.

Only if you are speaking of Scalia?

>Scalia

:)

Swift has this as well, but calls them “Optional”. The concept is definitely useful!

Also Java has Optional<T> and C# has Nullable<T>.

That's not important in practice. What's important is that null infects all reference types in Java and C#, whether you asked for it or not. Just today I've spent a half an hour looking for a null dereference error - which the type system should've warned me of but didn't. The sad fact is, neither Java nor C# are fixable, because no new feature will fix the broken, null-unsafe code already written. All because of this billion dollar mistake that should've had no place in a GCed language but was blindly copied over from C++. The sooner Java gives way to Kotlin and completely fades into obscurity, the better.

C# 8.0 introduced "Nullable Reference Types" (https://devblogs.microsoft.com/dotnet/embracing-nullable-ref...), which, if enabled, can help solve this problem.

> was blindly copied over from C++.

From C! AFAIK C++'s references can not be null!

The big difference is that nullability is the standard in Java and C# while in Swift it's the other way round, it's non-nullable unless you clearly indicate it's not.