I think the elephant in the room that this article doesn’t directly address is “Do the programs you write have many types of data which should never be substituted?”. If all the types in your program really are strings, and you’re just moving text around you would likely be hindered by types. If by contrast you have many different kinds of integer that should not be mixed like weight and account balance you might really benefit from stricter types.
If all the types in your program really are strings, and you’re just moving text around you would likely be hindered by types.
I’ve yet to work on a useful program where the data’s representation as a “string” was the highest level of meaning that could be assigned to that data. As soon as you get past writing a toy you will start to have to differentiate between what different string values mean, and then we are talking about types–and arguably at precisely the point where we can start to leverage the power of a (good) type system. Speaking as someone who writes Clojure as his day job, it’s clear to me that this is why core.typed exists, and why there is so much activity around clojure.spec (and schema before it)–it’s obvious that “everything is a string” (or in the case of Clojure, “everything is a map”) isn’t good enough to represent the kind of data we work with as professional programmers (and the jury is out on whether or not clojure.spec is up to the task).
So while that’s not to suggest that we always need a sophisticated type system–or that we aren’t sometimes hindered when forced to use a type system like Java’s–I think it’s fair to say that it is rarely, if ever, the case that we don’t have more meaning assigned to the values in our program above and beyond than their encoding as low-level storage representations.
I think another good example of this situation is algorithmic code - the structure one would like to express (e.g. sortedness, sub-solution optimality, graph acyclicity) is often beyond what the type system can represent. You end up with numeric arrays / matrices / edge lists without much further type structure.
At the opposite end is either unit-heavy code (as in your example) or structure-heavy code (e.g. configs / ASTs / requests), both of which significantly benefit from what a typical type system offers.
If all the types in your program really are strings, and you’re just moving text around you would likely be hindered by types.
Could you give an example of such a program? I deal with strings relatively often, but the bulk of the logic in my programs (client-side JavaScript) benefit quite a bit from types (via TypeScript).
I think the elephant in the room that this article doesn’t directly address is “Do the programs you write have many types of data which should never be substituted?”. If all the types in your program really are strings, and you’re just moving text around you would likely be hindered by types. If by contrast you have many different kinds of integer that should not be mixed like weight and account balance you might really benefit from stricter types.
I’ve yet to work on a useful program where the data’s representation as a “string” was the highest level of meaning that could be assigned to that data. As soon as you get past writing a toy you will start to have to differentiate between what different string values mean, and then we are talking about types–and arguably at precisely the point where we can start to leverage the power of a (good) type system. Speaking as someone who writes Clojure as his day job, it’s clear to me that this is why
core.typedexists, and why there is so much activity aroundclojure.spec(andschemabefore it)–it’s obvious that “everything is a string” (or in the case of Clojure, “everything is a map”) isn’t good enough to represent the kind of data we work with as professional programmers (and the jury is out on whether or notclojure.specis up to the task).So while that’s not to suggest that we always need a sophisticated type system–or that we aren’t sometimes hindered when forced to use a type system like Java’s–I think it’s fair to say that it is rarely, if ever, the case that we don’t have more meaning assigned to the values in our program above and beyond than their encoding as low-level storage representations.
I think another good example of this situation is algorithmic code - the structure one would like to express (e.g. sortedness, sub-solution optimality, graph acyclicity) is often beyond what the type system can represent. You end up with numeric arrays / matrices / edge lists without much further type structure.
At the opposite end is either unit-heavy code (as in your example) or structure-heavy code (e.g. configs / ASTs / requests), both of which significantly benefit from what a typical type system offers.
Could you give an example of such a program? I deal with strings relatively often, but the bulk of the logic in my programs (client-side JavaScript) benefit quite a bit from types (via TypeScript).