4 ms·

This reasoning here is severely mistaken. Static typing does not change the complexity dynamics of your programming model. It's a mere tool. If I statically t

This reasoning here is severely mistaken. Static typing does not change the complexity dynamics of your programming model. It's a mere tool. If I statically type to DateTime I can still be wildy baffled to see a transaction take place in the future. Or even more baffled when at first glance the DateTime looks correct (ie in the past and recent) but to find out later when I get the support phone call that we incorrectly tallied the balance. Static typing just restricts where I can put my shoes in my closet. If I find a need to sort all the "righties" together -- for example, to figure out how many lefties I'm short -- static typing makes things more complex -- because it will disallow this innovation. Complexity is a count of concepts in your model, not a count of instances and not a count of state possibilities, which in any real world system are going to be endless no matter how much you waste time with static proofs.

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 ago
  To 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 ago
    There'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 ago
  I'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..

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 ago
To 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 ago
  There'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 ago
I'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..