12 ms·

I'm gonna be honest, I had never understood the "strict type" argument until right now. Seriously, since everything I work in is denoted as "cents" from backend

I'm gonna be honest, I had never understood the "strict type" argument until right now. Seriously, since everything I work in is denoted as "cents" from backend to frontend, I personally had never understood the need so I'm part of today's lucky 10,000th.

sneak 4y ago
I'm also in the camp that believes that functions or methods that take more than 2-3 (positional) arguments should really take a structure with named keys to avoid this. Humans are bad at lists. Seeing functions with 5-6 positional arguments makes my skin crawl even if they have strong types.
- deleted 4y ago
  [deleted]
- disgruntledphd2 4y ago
  Try to avoid looking at any scientific/data science code then. Almost every function has 6+ arguments.
JohnBooty 4y ago
Seriously, since everything I work in is denoted as "cents" from backend to frontend, I personally had never understood the need This matches my experience. Obviously actual strict typing has its benefits, but as far as developer ergonomics are concerned, IME you can get about 95% of the benefits just by following a convention of including unit names in identifier names. It's easy to see why this Ruby code might fail: def launch_rocket(distance) # what units are we expecting? end launch_rocket(42) But this is virtually impossible to screw up, and reduces developer cognitive load: def launch_rocket(distance_km:) # blahblahblah end # not happening unless developer consumes a large number # of drugs distance_miles = 42 launch_rocket(distance_km: distance_miles)
- Swizec 4y ago
  Easy! # not happening unless developer consumes a large number # of drugs distance_miles = 42 launch_rocket(distance_km: distance_miles*1.6) Aaaand we're off by 0.3924km. Enough to fit 4 football fields with a few meters left over. Oopsies Units are hard. Never under-estimate the ability of programmers to think they're converting but get it slightly wrong.
  - deleted 4y ago
    [deleted]
  - sgtnoodle 4y ago
    It's within a significant digit of the specified distance, though. A few football fields of error seems pretty good to me for 42 miles. What's the required accuracy and precision for this rocket launching system?
    - Swizec 4y ago
      Well if it’s a boom rocket for war, the expected precision these days is the size of a car if not smaller. I think even dumb gravity bombs in ww2 were more precise than “a few football fields”
    - Symbiote 4y ago
      Russia has been criticised and ridiculed for bombing civilian targets when they are presumed to be aiming for military targets a block away.
  - JohnBooty 4y ago
    I qualified my answer with a "95%" because yeah, I think it's good enough about that often. If we're launching physical rockets then yeah, I would agree that that is probably not a job for dynamic typing.
- fr0sty 4y ago
  > [follow] a convention of including unit names in identifier names. appending units to identifiers helps, but it relies on a developer's eyeballs to spot any errors. It would be infinitely preferable if the type system would simply enforce this for you and developers not have to expend cycles reasoning about this stuff themselves.
denton-scratch 4y ago
You don't need "strict typing" to handle money; in the old (COBOL) days, we used BCD to represent monetary amounts with arbitrary precision. When they took away BCD, we were stuck, if we wanted to build a system that could represent a large sum correctly in both dollars and yen. COBOL was pretty good for dealing with money.
- monocasa 4y ago
  BCD doesn't really make it easier. Fixed point can, but that's ultimately a typing thing that works just fine in binary as well.
  - denton-scratch 4y ago
    You're right; but COBOL BCD types allowed arbitrary precision, and it was super-easy to debug data; the hex represention was the same as the decimal representation.
- lifeisstillgood 4y ago
  Could you expand on BCD? What made it good for multi-currency work? (a quick google did not help, managed to lead to examples of COBOL manipulating the first five letters of the alphabet ...)
  - lalopalota 4y ago
    BCD = Binary Coded Decimal
  - fsckboy 4y ago
    BCD is simply "work in base ten on a base two digital computer". What made it good is that it enforces a discipline with the same pattern of rounding errors as base ten arithmetic on pencil and paper. This was particularly attractive when computers were new and replacing "doing it by hand". Bankers were nervous about the new systems screwing everything up, and they wanted the new system to demonstrate it would produce the exact same results as the old system. To give an illustrative example, what's 2/3 of a dollar? 66 cents or 67 cents, one or the other, choose the same one you would choose with pencil and paper. Now add 33 cents, did you "overflow" the cents and need to increment the dollars? Yeah, you can achieve the same thing with binary by constantly checking ranges of numbers, but the difference is, BCD when you screw up your code produces errors similar to adding numbers by hand, errors recognizable by your non computer literate accountant; binary screwups will produce a different unrecognizable pattern of errors. the way it worked was pretty straightforward, just like 4 bits is hex 0-F and 8 bits is 0x00 to 0xFF, a BCD byte is 00-99 and you just never have the patterns for A-F. This was enforced in hardware, in the CPU/ALU in terms of multi-currency, same thing, you'll see the same familiar rounding problems as traditional pencil and paper currency changing systems. Also the same set of issues extends to fixed point implementations of "floating point"/"decimal fraction"/"rational number" systems more common in engineering. 1/3 is a .33333.... repeating fraction; 1/5 is .2, no repeat, because 2x5=10 base 10. In binary, 1/5 is a repeating decimal, not good for comparing results, rounding, etc. And you can easily see that the same issue does apply to currency too (it was my example above with 67 cents), it's just a bit less visible because it's less common to use extended fractional amounts.
xg15 4y ago
This bug could easily happen in a typed language though. function deduct(int cents) { ... } int dollars = ... deduct(dollars); You need something like (Apps) Hungarian notation [1] as a minimum - or even better, subtypes of primitives like in Go to represent units in a typesafe way. [1] https://en.m.wikipedia.org/wiki/Hungarian_notation https://en.m.wikipedia.org/wiki/Hungarian_notation
- snotrockets 4y ago
  I think you’re confusing expressiveness of types with static/dynamic typing (the latter are also typed!) An expressive type system would allow you to define both a cent and dollar types, s.t. assignments of those types to each other without conversion would fail. In a way, it is a way to have the computer validate apps Hungarian rather than trusting the programmer (well, it’s more, but for this argument). Go’s type system is anachronistic, compared to what modern language provides (but then, all of go is anachronistic on purpose. The usefulness of this purpose not to be discussed here).
  - xg15 4y ago
    Ah, my bad there. That was what I meant with subtypes, but you're right, things have moved further there already. Sorry for the misinfo!
    - stavros 4y ago
      Yeah, defining "dollars" and "cents" (and over units) types are actually a really good solution for this, it means that you can never pass a value of one unit when the function expects another.
  - shepherdjerred 4y ago
    > The usefulness of this purpose not to be discussed here This is a fantastic bit to tack on for divisive topics, I'm stealing it.
- metafunctor 4y ago
  You should define separate types for “cents” and “dollars”. And, probably operations to convert between the types.
lxe 4y ago
Strict types have little to do with this. Unless your type system validates bounds , this sort of things happens regardless of types.
- mrkeen 4y ago
  At the very least, strict types: 1) make you do the check 2) only require you to do the check once
onion2k 4y ago
That won't always work unfortunately, particularly if you have to work globally. For example the fiscalization requirements for cash reporting in Germany specify that all of your transactiona have to be done to 6 decimal places (for things like discounts.)
scaredginger 4y ago
Somewhat in the spirit of that xkcd issue, may I commend you for adapting your opinions in the face of new evidence. It's a great quality to have

sneak 4y ago

I'm also in the camp that believes that functions or methods that take more than 2-3 (positional) arguments should really take a structure with named keys to avoid this. Humans are bad at lists. Seeing functions with 5-6 positional arguments makes my skin crawl even if they have strong types.

deleted 4y ago
[deleted]
disgruntledphd2 4y ago
Try to avoid looking at any scientific/data science code then. Almost every function has 6+ arguments.

JohnBooty 4y ago

Seriously, since everything I work in is denoted as "cents" from backend to frontend, I personally had never understood the need This matches my experience. Obviously actual strict typing has its benefits, but as far as developer ergonomics are concerned, IME you can get about 95% of the benefits just by following a convention of including unit names in identifier names. It's easy to see why this Ruby code might fail: def launch_rocket(distance) # what units are we expecting? end launch_rocket(42) But this is virtually impossible to screw up, and reduces developer cognitive load: def launch_rocket(distance_km:) # blahblahblah end # not happening unless developer consumes a large number # of drugs distance_miles = 42 launch_rocket(distance_km: distance_miles)

Swizec 4y ago
Easy! # not happening unless developer consumes a large number # of drugs distance_miles = 42 launch_rocket(distance_km: distance_miles*1.6) Aaaand we're off by 0.3924km. Enough to fit 4 football fields with a few meters left over. Oopsies Units are hard. Never under-estimate the ability of programmers to think they're converting but get it slightly wrong.
- deleted 4y ago
  [deleted]
- sgtnoodle 4y ago
  It's within a significant digit of the specified distance, though. A few football fields of error seems pretty good to me for 42 miles. What's the required accuracy and precision for this rocket launching system?
  - Swizec 4y ago
    Well if it’s a boom rocket for war, the expected precision these days is the size of a car if not smaller. I think even dumb gravity bombs in ww2 were more precise than “a few football fields”
  - Symbiote 4y ago
    Russia has been criticised and ridiculed for bombing civilian targets when they are presumed to be aiming for military targets a block away.
- JohnBooty 4y ago
  I qualified my answer with a "95%" because yeah, I think it's good enough about that often. If we're launching physical rockets then yeah, I would agree that that is probably not a job for dynamic typing.
fr0sty 4y ago
> [follow] a convention of including unit names in identifier names. appending units to identifiers helps, but it relies on a developer's eyeballs to spot any errors. It would be infinitely preferable if the type system would simply enforce this for you and developers not have to expend cycles reasoning about this stuff themselves.

denton-scratch 4y ago

You don't need "strict typing" to handle money; in the old (COBOL) days, we used BCD to represent monetary amounts with arbitrary precision. When they took away BCD, we were stuck, if we wanted to build a system that could represent a large sum correctly in both dollars and yen. COBOL was pretty good for dealing with money.

monocasa 4y ago
BCD doesn't really make it easier. Fixed point can, but that's ultimately a typing thing that works just fine in binary as well.
- denton-scratch 4y ago
  You're right; but COBOL BCD types allowed arbitrary precision, and it was super-easy to debug data; the hex represention was the same as the decimal representation.
lifeisstillgood 4y ago
Could you expand on BCD? What made it good for multi-currency work? (a quick google did not help, managed to lead to examples of COBOL manipulating the first five letters of the alphabet ...)
- lalopalota 4y ago
  BCD = Binary Coded Decimal
- fsckboy 4y ago
  BCD is simply "work in base ten on a base two digital computer". What made it good is that it enforces a discipline with the same pattern of rounding errors as base ten arithmetic on pencil and paper. This was particularly attractive when computers were new and replacing "doing it by hand". Bankers were nervous about the new systems screwing everything up, and they wanted the new system to demonstrate it would produce the exact same results as the old system. To give an illustrative example, what's 2/3 of a dollar? 66 cents or 67 cents, one or the other, choose the same one you would choose with pencil and paper. Now add 33 cents, did you "overflow" the cents and need to increment the dollars? Yeah, you can achieve the same thing with binary by constantly checking ranges of numbers, but the difference is, BCD when you screw up your code produces errors similar to adding numbers by hand, errors recognizable by your non computer literate accountant; binary screwups will produce a different unrecognizable pattern of errors. the way it worked was pretty straightforward, just like 4 bits is hex 0-F and 8 bits is 0x00 to 0xFF, a BCD byte is 00-99 and you just never have the patterns for A-F. This was enforced in hardware, in the CPU/ALU in terms of multi-currency, same thing, you'll see the same familiar rounding problems as traditional pencil and paper currency changing systems. Also the same set of issues extends to fixed point implementations of "floating point"/"decimal fraction"/"rational number" systems more common in engineering. 1/3 is a .33333.... repeating fraction; 1/5 is .2, no repeat, because 2x5=10 base 10. In binary, 1/5 is a repeating decimal, not good for comparing results, rounding, etc. And you can easily see that the same issue does apply to currency too (it was my example above with 67 cents), it's just a bit less visible because it's less common to use extended fractional amounts.

xg15 4y ago

This bug could easily happen in a typed language though. function deduct(int cents) { ... } int dollars = ... deduct(dollars); You need something like (Apps) Hungarian notation [1] as a minimum - or even better, subtypes of primitives like in Go to represent units in a typesafe way. [1] https://en.m.wikipedia.org/wiki/Hungarian_notation https://en.m.wikipedia.org/wiki/Hungarian_notation

snotrockets 4y ago
I think you’re confusing expressiveness of types with static/dynamic typing (the latter are also typed!) An expressive type system would allow you to define both a cent and dollar types, s.t. assignments of those types to each other without conversion would fail. In a way, it is a way to have the computer validate apps Hungarian rather than trusting the programmer (well, it’s more, but for this argument). Go’s type system is anachronistic, compared to what modern language provides (but then, all of go is anachronistic on purpose. The usefulness of this purpose not to be discussed here).
- xg15 4y ago
  Ah, my bad there. That was what I meant with subtypes, but you're right, things have moved further there already. Sorry for the misinfo!
  - stavros 4y ago
    Yeah, defining "dollars" and "cents" (and over units) types are actually a really good solution for this, it means that you can never pass a value of one unit when the function expects another.
- shepherdjerred 4y ago
  > The usefulness of this purpose not to be discussed here This is a fantastic bit to tack on for divisive topics, I'm stealing it.
metafunctor 4y ago
You should define separate types for “cents” and “dollars”. And, probably operations to convert between the types.

lxe 4y ago

Strict types have little to do with this. Unless your type system validates bounds , this sort of things happens regardless of types.

mrkeen 4y ago
At the very least, strict types: 1) make you do the check 2) only require you to do the check once

onion2k 4y ago

That won't always work unfortunately, particularly if you have to work globally. For example the fiscalization requirements for cash reporting in Germany specify that all of your transactiona have to be done to 6 decimal places (for things like discounts.)

scaredginger 4y ago

Somewhat in the spirit of that xkcd issue, may I commend you for adapting your opinions in the face of new evidence. It's a great quality to have