4 ms·

This is why I can't help but mentally roll my eyes when people say that static typing makes programming slower. It makes writing the happy path slower, but is

This is why I can't help but mentally roll my eyes when people say that static typing makes programming slower. 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.

l0b0 3y ago
> It makes writing the happy path slower, but is writing the happy path _programming?_ Most managers and even some programmers seem to think so. Build the thing with no quality control, ship it, deal with the fallout, repeat. Bad programmers think this is normal, good programmers ensure that any fallout is rare.
- smif 3y ago
  I don't know if it's necessarily bad programmers. Think about this analogy, there's a blacksmith that can make swords but if you want it done well, it's gonna take more time/money. That same blacksmith can choose to take on customers that insist that he make the sword quicker and cheaper (and probably shittier). 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?
  - MereInterest 3y ago
    One problem with this mentality is that customers need to search more and more to find blacksmiths that provide anything other than cheap swords. They may reasonably conclude that this is just the nature of swords, and that there’s no such thing as a sword that withstands more than one or two blows. Eventually, even people who want good swords accept that they won’t be able to find a blacksmith who makes them, and settle for cheap swords instead. In effect, https://en.wikipedia.org/wiki/The_Market_for_Lemons https://en.wikipedia.org/wiki/The_Market_for_Lemons
    - smif 3y ago
      That's a fair point, but I don't think it's a problem with the blacksmith per se. You can't really expect every blacksmith to hold themselves to an arbitrary high standard and turn down work when they're possibly one or two missed payments away from financial ruin. 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?
jim-jim-jim 3y ago
Funnily enough, languages with sufficiently advanced type systems can focus almost exclusively on the happy path thanks to functor/applicative/monad. -- 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 in Haskell, compared to a much longer explicit error checking equivalent in Go etc.
- robertlagrant 3y ago
  What does that do?
  - jim-jim-jim 3y ago
    It's more general than this, but in this example it's a chain of three functions, f, g, h, each of which can fail in the same way. The precise failure behavior is encoded in the types themselves, so there is no need to check for it explicitly in the code. If `f` doesn't work, then `g` won't run, and the failure will be handled as expected by the functions' return types. Maybe they'll return an error message or maybe they'll be a "null" sort of value; the types will tell you, but the chaining syntax itself will always be the same. 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.
    - robertlagrant 3y ago
      Thanks! It's hard to imagine how this would work in a complex example that has multiple error paths, but I understand what you mean in the case of same types/one error case. Railway Oriented Programming and all that.
eweise 3y ago
plus modern statically typed languages have type inference so I don't buy the argument that the happy path is faster in dynamically typed languages.
lixtra 3y ago
> It makes writing the happy path slower, but is writing the happy path _programming?_ 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.
- beoberha 3y ago
  This is an interesting example. There are plenty of rules that must be followed when building a home. Equating type checking to a home being able to withstand a tank is a poor example IMO due to the potential of the scenario actually occurring. You’re going to have type checking errors. You’re never going to have someone coming at your home with a tank. A much better example is a significant amount of rain or wind. You might have that storm once every few years but you’ll be glad you built it to withstand it when it comes. 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.
- IshKebab 3y ago
  The dynamic type checking analogy of house building is eyeballing support dimensions and then rebuilding walls when they fall down. Fine for a shed, but if it's a building I'm living in I would like a structural engineer to do some calculations to check it's ok before I use it. Maybe that's the difference between programming and software engineering! Engineers care if their stuff breaks.
  - pjmlp 3y ago
    Software Engineers that took a proper engineering degree care as well.
- pjmlp 3y ago
  "If a builder builds a house for someone, and does not construct it properly, and the house which he built falls in and kills its owner, then that builder shall be put to death." -- 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.
Ennea 3y ago
I think writing the happy path can be a very important part to programming, yes. I know some programmers who don't need to see immediate results when writing their software, but me personally? I can't really do without it. It helps keep my drive up being able to prototype things quickly, and helps shape the software I am writing, too. Low level languages feel unwieldy to me. Things that are relatively easy in languages like Python get more complex, but I suppose it's also the lack of experience with such languages. Where do I start, though, when doing anything feels so slow to me? :) Difficult problem for sure...
harha_ 3y ago
It depends on what you're doing and also your subjective opinions. If you are writing software with a decent amount of lines and it's even somewhat important, you obviously want the typing benefits. On the other hand, if you're prototyping something personal and don't care about minor type errors in the slightest, it's nice and quick to do the job with javascript or python 3.
crabbone 3y ago
> This is why I can't help but mentally roll my eyes when people say that static typing makes programming slower. 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.

l0b0 3y ago

> It makes writing the happy path slower, but is writing the happy path _programming?_ Most managers and even some programmers seem to think so. Build the thing with no quality control, ship it, deal with the fallout, repeat. Bad programmers think this is normal, good programmers ensure that any fallout is rare.

smif 3y ago
I don't know if it's necessarily bad programmers. Think about this analogy, there's a blacksmith that can make swords but if you want it done well, it's gonna take more time/money. That same blacksmith can choose to take on customers that insist that he make the sword quicker and cheaper (and probably shittier). 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?
- MereInterest 3y ago
  One problem with this mentality is that customers need to search more and more to find blacksmiths that provide anything other than cheap swords. They may reasonably conclude that this is just the nature of swords, and that there’s no such thing as a sword that withstands more than one or two blows. Eventually, even people who want good swords accept that they won’t be able to find a blacksmith who makes them, and settle for cheap swords instead. In effect, https://en.wikipedia.org/wiki/The_Market_for_Lemons https://en.wikipedia.org/wiki/The_Market_for_Lemons
  - smif 3y ago
    That's a fair point, but I don't think it's a problem with the blacksmith per se. You can't really expect every blacksmith to hold themselves to an arbitrary high standard and turn down work when they're possibly one or two missed payments away from financial ruin. 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?

jim-jim-jim 3y ago

Funnily enough, languages with sufficiently advanced type systems can focus almost exclusively on the happy path thanks to functor/applicative/monad. -- 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 in Haskell, compared to a much longer explicit error checking equivalent in Go etc.

robertlagrant 3y ago
What does that do?
- jim-jim-jim 3y ago
  It's more general than this, but in this example it's a chain of three functions, f, g, h, each of which can fail in the same way. The precise failure behavior is encoded in the types themselves, so there is no need to check for it explicitly in the code. If `f` doesn't work, then `g` won't run, and the failure will be handled as expected by the functions' return types. Maybe they'll return an error message or maybe they'll be a "null" sort of value; the types will tell you, but the chaining syntax itself will always be the same. 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.
  - robertlagrant 3y ago
    Thanks! It's hard to imagine how this would work in a complex example that has multiple error paths, but I understand what you mean in the case of same types/one error case. Railway Oriented Programming and all that.

eweise 3y ago

plus modern statically typed languages have type inference so I don't buy the argument that the happy path is faster in dynamically typed languages.

lixtra 3y ago

> It makes writing the happy path slower, but is writing the happy path _programming?_ 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.

beoberha 3y ago
This is an interesting example. There are plenty of rules that must be followed when building a home. Equating type checking to a home being able to withstand a tank is a poor example IMO due to the potential of the scenario actually occurring. You’re going to have type checking errors. You’re never going to have someone coming at your home with a tank. A much better example is a significant amount of rain or wind. You might have that storm once every few years but you’ll be glad you built it to withstand it when it comes. 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.
IshKebab 3y ago
The dynamic type checking analogy of house building is eyeballing support dimensions and then rebuilding walls when they fall down. Fine for a shed, but if it's a building I'm living in I would like a structural engineer to do some calculations to check it's ok before I use it. Maybe that's the difference between programming and software engineering! Engineers care if their stuff breaks.
- pjmlp 3y ago
  Software Engineers that took a proper engineering degree care as well.
pjmlp 3y ago
"If a builder builds a house for someone, and does not construct it properly, and the house which he built falls in and kills its owner, then that builder shall be put to death." -- 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.

Ennea 3y ago

I think writing the happy path can be a very important part to programming, yes. I know some programmers who don't need to see immediate results when writing their software, but me personally? I can't really do without it. It helps keep my drive up being able to prototype things quickly, and helps shape the software I am writing, too. Low level languages feel unwieldy to me. Things that are relatively easy in languages like Python get more complex, but I suppose it's also the lack of experience with such languages. Where do I start, though, when doing anything feels so slow to me? :) Difficult problem for sure...

harha_ 3y ago

It depends on what you're doing and also your subjective opinions. If you are writing software with a decent amount of lines and it's even somewhat important, you obviously want the typing benefits. On the other hand, if you're prototyping something personal and don't care about minor type errors in the slightest, it's nice and quick to do the job with javascript or python 3.

crabbone 3y ago

> This is why I can't help but mentally roll my eyes when people say that static typing makes programming slower. 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.