> But the caller still needs to deal with the empty type.
Yes, the caller has to deal with it. The caller in this case is, in my example, the function that takes the user inputs. But every subsequent part of the application (in my example the sorting/email function) does _not_ have to deal with it anymore.
So essentially: you only have to deal with errors at the boundaries of your application - and after that, the rest of your code (usually the vast majority) just works without checking for errors again and again.
So to answer your summary:
> A compiler can’t solve the problem of preventing the class of bug you’re talking about, hence why there always needs to be some code that handles cases like empty files or lists
Yes. The difference is: do you want to handle these case all over again in each function of your code base... or just once at the boundary.
Ok, well I agree with that assessment. I just don’t think the article has made the case that the methods he talks about simplify handling these things at the boundary in some special way.
There are numerous ways, even in dynamically typed languages to use abstraction to raise the level of such errors and handle them in a single place.
For instance let’s take ruby. Rails has a “.blank?” Function that wraps up handling empty strings, lists, nils, etc. So if I use that abstraction, I’ve raised up having to check all those issue in every function, instead now I need to ensure the “blank?” function does what’s its supposed to.
So there’s definitely value in abstraction, and in moving certain classes of errors up the layers in the application. And yes I can see how some fancy uses of type systems (in this case Haskell) can make this work. The grandparent article seems to leave it there.
This parent article though seems to muddle things with the idea that parsing can do even better, and that’s were I think the idea is half baked.
Just to put a nail on it, a previous commenter above spells it out
“And some of those simpler solutions do come from the dynamic programming world. For example, ‘You can then go further and remove the more primitive operations, only allowing access to the higher level abstractions,’ is another excellent way to make illegal states unrepresentable. And you don't need shiny new programming languages or rocket powered type systems to do it. I was really rather disappointed that that section of the article gave a nod to Dijkstra, but completely failed to mention Alan Kay's The Early History of Smalltalk[1], which was, to an approximation, several thousand words' worth of grinding away on that point.”
So I feel like maybe we all were confused by what the article was suggesting, if indeed it suggested anything concrete at all.
> The grandparent article seems to leave it there.
I think the article unfortunately just assumes that you are already familiar with using an advanced statically typed language and draw the conclusion about the advantages automatically.
I am actually very familiar with advanced statically typed languages, however the article isnt trying to make the case that such languages have any advantages. (Another debate entirely) It’s instead making the case that adding “parsing” to such languages helps deal with some certain set of bugs, but it still seemed pretty non specific and doesn’t seem to cover any new ground in any interesting way frankly.
> But the caller still needs to deal with the empty type.
Yes, the caller has to deal with it. The caller in this case is, in my example, the function that takes the user inputs. But every subsequent part of the application (in my example the sorting/email function) does _not_ have to deal with it anymore.
So essentially: you only have to deal with errors at the boundaries of your application - and after that, the rest of your code (usually the vast majority) just works without checking for errors again and again.
So to answer your summary:
> A compiler can’t solve the problem of preventing the class of bug you’re talking about, hence why there always needs to be some code that handles cases like empty files or lists
Yes. The difference is: do you want to handle these case all over again in each function of your code base... or just once at the boundary.