It makes writing the happy path slower, but is writing the happy path _programming?_
By the time you have a program which is complete and (at least mostly) bug free, the static typing has saved you hundreds of hours.
The happy path is just fine for many cases.
Your home isn’t built to withstand a determined attacker with a tank. But we live in a happy world and a lot of stuff exists because people can cut corners.
Good managers/programmers know where they can be sloppy and where they have to be super careful.
The beauty of technical debt is that it only has to be repaid in case of success.
I’m being generous tbh. In my experience, though I work on pretty critical software, the unhappy path is a fairly critical path and must have some intentional barriers built before being shipped to customers.
Maybe that's the difference between programming and software engineering! Engineers care if their stuff breaks.
-- Hammurabi's Code, Babylon 1755–1750 BC
Modern construction law isn't as brutal, still liabilities will be questioned if corners were cut, and brought to court.
In many cases, programming is still at the level of driving chariots with steam engines.
--
It seems that this comment is controversial and I'm not sure why. I'm referring to the ability to do something like
h <=< g <=< f
It's far more common to see this chaining done with `do` blocks but I wanted to keep it all on one line.
This lends itself to a clean and optimistic sort of programming. You just write what you want to happen, chained within the broader context of some exception that might occur. So I agree with the parent that static typing makes things faster and easier, but I would argue that most unhappy paths don't require unique attention, and that it's language smell to make you care about them.
> It makes writing the happy path slower, but is writing the happy path _programming?_
He's not gonna be the one using the sword and he can make it clear up front about the tradeoffs. If it shatters in use and the customer gets maimed, oh well, they were warned. Sometimes the market is flooded with people who just want cheap swords made fast and the blacksmith needs to pay the bills too right?
In effect, https://en.wikipedia.org/wiki/The_Market_for_Lemons
I would say if their society can grant them the safety to turn down work for cheap swords at their discretion without the risk of having their life ruined through a down period that is lacking high-quality work orders, then maybe you might have a case for also holding the blacksmiths accountable to a higher standard of work.
Accepting and taking on the risks associated with highly selective work orders has it's own intrinsic value and should be rewarded somehow. If it's not, then why would anyone do it?
No sane person says that. Also, static typing is not a thing (or at least, what you call "static typing" doesn't mean anything).
Type checking can be static. And in this context it means that it happens before the program is run, so it doesn't affect the speed of the program.
Your conjectures about how static typing (but probably actually checking) saves time developing is also nonsense. Static checking is helpful for analyzing programs, of course, but isn't the primary driver behind program quality, not even the second most important one. But, most importantly, quality typically only adversely affects the time to market. Working towards more correct programs will make the whole process slower and more expensive. Perhaps, at some very bottom of the quality pyramid you can find examples of the opposite -- when the program is so bad that it actually negatively impacts time to market and that metric can be improved by marginal effort in quality control... but if you are out of the swamp, this doesn't work anymore, and any increase in quality will negatively impact ttm, cost, number of employees needed etc.