Where are the unit tests?
Oh I’m sure there are unit tests for new func and old func that test them separately just fine. The if statement is probably thought of as a temporary switchover kind of thing.
Twenty five thousand dollars of funny money
31–40 of 175 posts
Re: Twenty five thousand dollars of funny money
#32I understand this whole scenario is simplified for story's sake but, if there's old_func and new_func, and the new_func call in the else was added that morning, why would the same error of new_func getting the wrong amount of arguments happen weeks before?
I suspect the new function was an attempt to fix whatever was the backend problem (because before it would work the second time, but give the correct $250).
Re: Twenty five thousand dollars of funny money
#33I'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
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)
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)Re: Twenty five thousand dollars of funny money
#34I'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.
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.
Re: Twenty five thousand dollars of funny money
#35Where are the unit tests?
People writing unit tests for internal tools? A lot of companies don't even having tests for production code.
Especially yes. A unit test would have caught this instantly.
It is code that deals with $'s... something you'd really want to test, since it'll cost the company money.
Instead, you've got multiple engineers writing code multiple times (my euphemism for fixing buggy code), which also costs the company money.
Re: Twenty five thousand dollars of funny money
#36I understand this whole scenario is simplified for story's sake but, if there's old_func and new_func, and the new_func call in the else was added that morning, why would the same error of new_func getting the wrong amount of arguments happen weeks before?
I wondered that. I thought the bug had been around for a while; I suppose the morning checkin was a failed fix for the pre-existing bug.
Re: Twenty five thousand dollars of funny money
#37>I say bare numbers can be poison in a sufficiently complicated system
Indeed. It's interesting that the de facto solution to this is to key value pairs, where sometimes the key can be an array (e.g. json, xml, etc), and then one can (kinda) infer units from the key. But even this is insufficient, because inevitably the value is pulled out and it's context is lost.
This is, I think, a(nother) powerful argument for immutable values, and accreting structure losslessly with pointers. Like in Clojure. In general we our runtime should support values that have monotonically increasing amounts of metadata added to them during runtime, for example units, or more paths, such that any user of the value can interrogate that structure and find out what it meant to the last people to read or write the value.
Re: Twenty five thousand dollars of funny money
#38Earlier quoted context omitted.
type RobotName = string; function foo(r: RobotName) {} ?
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 typing is what you want.
Re: Twenty five thousand dollars of funny money
#39I think I like the duck typing in TypeScript more than I dislike it. But I still wish I could say “this function accepts a type called RobotName. It’s a string, but so is RobotUuid, and we don’t want that. So only accept, strictly, objects typed as RobotName.”
This is actually one of the nice features about OCaml that comes in handy when you have a function that takes two arguments of the same type but don't necessarily need to make a whole new type for each of them. They are called Labelled Arguments [0] and when you call the function, the label has to be the same. I've found that using it can clean up code because it ensures that variables share the name across the codebase as well as making sure arguments don't get mixed up.
Re: Twenty five thousand dollars of funny money
#40I put myself in this very position with some cache expiration times.
Almost everything in the server-side that is related to times for a particular client uses milliseconds. Of course, redis’s `SETEX` does not. It uses seconds.
The data got quite stale. But, much like this post, other bugs were uncovered and usefully fixed.