4 ms·
If we take `cleanliness = number of valid states / number of total states`, then using DateTime vs String is strictly cleaner. Yes, there are still many invali
by 1penny42cents 6y ago
If we take `cleanliness = number of valid states / number of total states`, then using DateTime vs String is strictly cleaner.
Yes, there are still many invalid states within a strong type and static typing is just one form of reducing complexity. I'm actually much more interested in cleanliness of design and architecture, but the String vs DateTime or Enum vs String examples are easy ways to illustrate the idea.
- wellpast 6y agoTo be clear I’m saying that static typing makes things more complex. If the original simple argument were true, then everyone would introduce static typing, it would be a no-brainer.
- hderms 6y agoThere's a certain size threshold for applications where a statically typed language becomes extremely valuable. Static proofs that things are "connected" properly become very valuable, even if, as you say, the benefits aren't universal. Constraints sometimes simplify things, sometimes they increase complexity, but it's hard to argue that large systems with many authors would be universally better if they were unable to use static types to constrain programs.
- cetra3 6y agoI've found rust really helps out with this, enforcing some strict rules around types. I had to implement a `Lowercase` type which is just a string that can only be lowercase (for case insensitive searches). After implementing standard traits like `Into` and `Deref`, it just acted as a standard string. That way I could guarantee at compile time that things are lowercase, but still have the flexibility of strings. Another common idiom I have seen is to compose finite state machines using enums. You can only create a particular state from another state etc..