4 ms·
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 cognitiv
by cle 10y ago
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 10y ago"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 http://eric.seidel.io/pub/nanomaly-icfp16.pdf
- dllthomas 10y agoThat is really cool! When will it be in GHC? :D
- wereHamster 10y ago> Where "null" really is better than an Option type. WAT? Give me an example.
- cle 10y agoperformance
- tome 10y agoThere's no reason it shouldn't be a typed null though. It doesn't have to be a tagged Option type.
- cle 10y agoI'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.
- premium-concern 10y agoThat's an extremely weak argument. Java's Optional is broken and should never be used.
- cle 10y agoIf that is true, then it's another example supporting my point.
- premium-concern 10y agoNo. Java messing things up as usual, doesn't have any broader impact on the usefulness of the concept. Error handling with null is wrong and broken, regardless of whether the null is "typed" or not. null might have some very limited other uses, but they will never compete with those structures designed for error handling, because they do something fundamentally different.
- cle 10y agoMy argument is practical, not theoretical. Platitudes and ideals are disposable when you have to actually build something.
- premium-concern 10y agoYawn. Java is the platform with NPEs and null checks everywhere. If that's your definition of practical, sure, go ahead.
- dllthomas 10y ago
- dllthomas 10y ago> 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#).