Live data from Hacker News

Twenty five thousand dollars of funny money

rachelbythebay.com

71–80 of 175 posts

Re: Twenty five thousand dollars of funny money

#71
post #51

Had they had unit tests, this would never have gotten that far. Have unit tests!! Could you do other things with those credits, like use them in the cafeteria or resell them? Why were they so frantic to close the loophole?

No, the credits could only be used to run ads. However, the ads were run publicly, and competed in ad auctions with campaigns from actual customers paying actual money.

If employees had a $25k ad budget, that would mean increasing the demand for ad placement by $25k, which could actually affect the ad campaigns of real customers - definitely not ideal.

Re: Twenty five thousand dollars of funny money

#72

Earlier quoted context omitted.

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.

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 ...)

BCD = Binary Coded Decimal

Re: Twenty five thousand dollars of funny money

#73

Earlier quoted context omitted.

Yep. But that function will accept type RobotUuid = string; const bar: RobotUuid = “abc…”; foo(bar); This is what duck typing is and specifically my curiosity about being able to de-duck on demand.

Yeah just means you have to rely on linting and your ide to catch those errors. And hopefully the rest of your team does the same thing. Tho I suppose if it is really important you can put an assert there but I'm not familiar with that wrt typescript, maybe the transpiler would kill that? I've done the occasional type checking in that way in similar languages, it is kind of self documenting too. 90% of the time duck…

> Yeah just means you have to rely on linting and your ide to catch those errors. And hopefully the rest of your team does the same thing.

Yes, and that’s roughly what TypeScript is: a linter that everyone on your team is running.

Re: Twenty five thousand dollars of funny money

#74

Critical things come with critical stickers: Transformer boxes, Nuclear waste, Highly acidic compounds, High energy lasers, choking hazards. The oldest debate: should there be a money primitive in the type system? I mean, availability breeds use, use breeds awareness, awareness breeds or enforces proper use. A currency/money type would be a pretty clear label to ward off a whole suite of stupid bugs like the one desc…

or just units of measure a more general solution than what you're suggesting, implemented by languages like F#

https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...

Re: Twenty five thousand dollars of funny money

#75
post #48

Earlier quoted context omitted.

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

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 s…

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!

Re: Twenty five thousand dollars of funny money

#76

Earlier quoted context omitted.

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…

Nope, this will lead to the same problem that the OP has discovered, viz., that a dependency update creates silent errors. Unless the argument is a keyword, but everyone is too lazy for that.

Yeah, to me the moral of the story was write more tests.

Re: Twenty five thousand dollars of funny money

#77

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.

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…

The case you claim requires drugs will happen eventually even if everybody is sober. I've seen it many times, and I doubt I'm the only one. Somebody is tired, or they get the computer to perform some bulk change and get it wrong, or they are doing some rote transformation and they miss a case.

If you want to do a bit better, a simple way of handling it is to provide a separate type that handles the abstract quantity (distance, money, etc. - you'd probably want to be cleverer about money if you deal with multiple currencies though), and ensure that values of that type can be converted to and from numbers only when the units are explicitly specified.

So then you end up with functions that consume a distance looking something like this:

    void launch_rocket(Distance distance) {
        call_ancient_fortran_routine(get_miles_from_distance(distance));
    }
And functions that create distances looking something like this:

    launch_rocket(create_distance_from_km(100));
What you now can't do is create a value that's of one unit, and pass it to something that expects another unit - the issue doesn't really arise, as Distance values themselves don't have specific units. They are a black box that somehow encodes a distance, and you specify the units used explicitly when initializing and you specify the units desired explicitly if retriving an actual number.

(Turning a distance into a number would ideally be a rare case, though sometimes you'd need it. You'd provide maths functions for all operations required, so you'd hopefully rarely need the number for calculation purposes. For displaying in any UI, there'd be a function to convert it to a string that respects the user's locale and distance unit preferences. And so on.)

Re: Twenty five thousand dollars of funny money

#80
post #51

Had they had unit tests, this would never have gotten that far. Have unit tests!! Could you do other things with those credits, like use them in the cafeteria or resell them? Why were they so frantic to close the loophole?

To be pedantic, you would need integration tests to catch this. Both of the units (probably) worked just fine. So:

Have unit tests and integration tests!!

:)

Post reply on HN