undefined | Better HN

0 pointsHasnep5mo ago0 comments

I think that's less likely to happen in Gleam because using 0 as a sentinel value would be unidiomatic, but I agree that's a very dangerous design choice.

0 comments

throwawaymaths5mo ago

luckily no gleam software ever has to interact with outside systems (software or otherwuse) that might make a choice unidiomatic to gleam.

in case it wasnt clear: a zero share tx being a tombstone is a stock accounting convention, not a choice of that particular software project.

HasnepOP5mo ago

You'd just do the same thing you do in any language, you parse the incoming data into a format that's more idiomatic, e.g. in Gleam

    type Record {
      NShares(n: Int)
      ZeroTheAccount()
    }
    
    fn parse_record(n: Int) -> Record {
      case n {
        0 -> ZeroTheAccount()
        _ -> NShares(n)
      }
    }

Then you don't have to worry about mixing up the two :)

throwawaymaths5mo ago

no. you're mistaken. the error came about because the code calculated shares to give out as an average over certain set of values but in the particular business cycle there were no entries to average. a divide by zero error would have crashed and either triggered review or nothing would have happened. instead, dividing by zero was happily calculated as zero and everyone got a zero share disbursement, which meant "zero all the accounts". this is not an inbound data problem. this is a scenario where if someone had programmed it in gleam, gleam would have happily calculated an (incorrect) average of zero and everyone would have lost all their shares.

to wit: anything that calculates an average over non-fixed data cardinality for business logic is potentially at risk for a seroious logic error in gleam.

what's worse is this is a nonobvious error. llms will likely make it a lot. a code review is likely to miss it.

what's even worse is that the author refuses to acknowledge this and digs deeper in (because, well, its a "principled" choice that got made and now to change is breaking and it breaks a core "feature" of the language). 1/0 = 0 is fine for a language like idris which is used for theorem proving but never used for real world things. It's inappropriate for deploying when, for example, real money might be at stake.

1 more reply

j / k navigate · click thread line to collapse

0 comments

throwawaymaths5mo ago

luckily no gleam software ever has to interact with outside systems (software or otherwuse) that might make a choice unidiomatic to gleam.

in case it wasnt clear: a zero share tx being a tombstone is a stock accounting convention, not a choice of that particular software project.

HasnepOP5mo ago

You'd just do the same thing you do in any language, you parse the incoming data into a format that's more idiomatic, e.g. in Gleam

    type Record {
      NShares(n: Int)
      ZeroTheAccount()
    }
    
    fn parse_record(n: Int) -> Record {
      case n {
        0 -> ZeroTheAccount()
        _ -> NShares(n)
      }
    }

Then you don't have to worry about mixing up the two :)

throwawaymaths5mo ago

to wit: anything that calculates an average over non-fixed data cardinality for business logic is potentially at risk for a seroious logic error in gleam.

what's worse is this is a nonobvious error. llms will likely make it a lot. a code review is likely to miss it.

1 more reply

j / k navigate · click thread line to collapse