Re:Why I Prefer Dynamic Typing Over Static Typing (2017)
by klmr on Tuesday February 19, 2019 @11:19AM
(#19200005)
> The thing for me is the type system shouldn't decide whether or not a certain piece of information is critical to the system.
No, that is in fact the stated purpose of the type system. If you don’t want to make such a decision statically, you mark a field appropriately (e.g. via an Option type).
Re:Why I Prefer Dynamic Typing Over Static Typing (2017)
by SkyPuncher on Tuesday February 19, 2019 @11:43AM
(#19200254)
I understand that's the stated purpose. I'm demonstrating how I feel types can pretty much become useless when integrating with an outside system.
If everything is optional, then you might as well not use a type system in the first place.
Re:Why I Prefer Dynamic Typing Over Static Typing (2017)
by klmr on Tuesday February 19, 2019 @12:22PM
(#19200724)
Again, there’s virtually never a reason to make everything optional/variant. It’s a conscious design choice and should be used judiciously (otherwise the API becomes difficult to use, and the same is true in a purely dynamic system).
Possibly. If it's a key part of the application, like Credit Card processing or auth - absolutely. If it's simply auxiliary or supplemental information - probably not. The thing for me is the type system shouldn't decide whether or not a certain piece of information is critical to the system. That typically falls to deeper logic in the system. If the type system isn't deciding, then it's pretty much meaningless (as everything would be optional).
For example, I'm using a Stripe JS integration to allow customers to manage credit cards in app. Stripe messes up or changes something without me paying attention. Instead of returning a complete object, Stripe starts returning only the credit card ID.
This isn't a big deal if we simply need to know that a record exists. We can still tell the user has a card and we have an ID to attempt a transaction against server side. We might not be able to display details about the card, but users could still submit a transaction (likely against their last used card).
However, it is a big deal in a credit card management interface. Without supplementary data, all of the cards would look exactly the same and the UI might break if expected fields aren't present.
----
I don't want my type system deciding what the use case is or how important one case is compared to the other. The actual implementation needs to decide if it has the information it needs to do its job.