[cle]

There is a real cost to properly modeling your domain in the type system. You have to conform with the constraints of the type system, there is higher cognitive overhead, it can cost more up-front (which can cause missed deadlines), etc.

Also, there are cases where using strings is more appropriate than using enums. Where passing a blob is preferred over guaranteeing the correctness of the blob's structure. Where "null" really is better than an Option type.

And conversely, there are companies who hire crappy developers or don't give their good developers enough time to learn the idioms and best practices of their tools.

[KMag]

"Dynamic Witnesses for Static Type Errors* ("or ill-typed programs usually go wrong)"[0] by Eric Seidel et. al. discusses a prototype for a system that searches for concrete examples of ill-typed inputs that break a program, in order to aid novice programmers with type errors at compile time.

[0]http://eric.seidel.io/pub/nanomaly-icfp16.pdf

[dllthomas]

That is really cool! When will it be in GHC? :D

[dllthomas]

> there is higher cognitive overhead

In my experience, the opposite is the case. If I can offload some checks to my tooling, I don't have to be constantly performing them mentally. And with type inference at a repl, I can ask about the shape of things that can't possibly run yet (though I don't think I get that with C#).

[wereHamster]

> Where "null" really is better than an Option type.

WAT? Give me an example.

[cle]

performance

[tome]

There's no reason it shouldn't be a typed null though. It doesn't have to be a tagged Option type.

[cle]

I'm talking about practical reasons to use null.

Theoretically it's not necessary, but given real-life constraints, there are most definitely times when null is more appropriate than e.g. Java's Optional.

[tome]

I agree! I'm just saying there's no theoretical reason for null not to be typed (which is quite different from Optional).

[cle]

Then we agree :). From a correctness perspective, nulls are awful.

My point was not specifically aimed at typed nulls and compiler optimization, it was that there will always be practical constraints that force us to compromise static guarantees in order to get things done in a reasonable amount of time. As software engineers, our problems are first practical before they are theoretical.

[premium-concern]

That's an extremely weak argument. Java's Optional is broken and should never be used.

[cle]

If that is true, then it's another example supporting my point.

[dllthomas]

Could you expand on this?