3 ms·
maybe you get the sunshine case out of the door quicker. But beware new-year or leap years. Or daylight saving change. Or non-ascii. I mean, who would ever car
by mro_name 5y ago
maybe you get the sunshine case out of the door quicker. But beware new-year or leap years. Or daylight saving change. Or non-ascii.
I mean, who would ever care about fringe cases when you can have continuous delivery instead?
- DeathArrow 5y agoWell, if it works when you deploy, maybe you get lucky and the bug will arrive after you've moved to another company. :D
- goto11 5y agoI don't see how this is different between type systems. No type system I know of guarantee you handle leap years correctly.
- mro_name 5y agoin real life nobody will guarantee you anything. But treating dates and surnames alike doesn't help robustness either. Or separate types for metric distance and imperial distance might have prevented mars(?) lander losses. Or for sea levels referenced to Rotterdam or Le Havre might have prevented some bridges to have differing levels.
- mro_name 5y agoI apologise for the misleading example "leap year".
- goto11 5y agoI'm a fan of static typing, but if people think it will protest them from logical errors like forgetting about DST, then they are actually worse off.
- reuben364 5y agoI guess; in the sense that it frees cognitive load from reasoning about properties of your program that are easily computed to think about properties that aren't. Even then, maybe thinking about the former primes you to reason about the latter. But even if the compiler tells you what the type of something should be, you ultimately have the synthesize something of that type.
- mro_name 5y agothink of the metric/imperial example above. The distance isn't just a number. Holds for most other things, too. Typed is key. Be it either static or dynamic.