One more tip: If you're ever designing an API like this, instead of:
time.sleep(300)
Put your units in the method name:
time.sleep_seconds(300)
Likewise, if you're making a .length() method where the units are at all ambiguous (like the length of a string), name your units. Bad: str.len(). Good: str.len_chars() / str.len_utf8_bytes(). (I'm looking at you, Rust!)
That doesn't really seem better, because the fact that the unit is seconds is only obvious if you happen to be looking at the function signature in the header or somesuch. This is because C typedefs are type aliases, not newtypes. If seconds were instead a struct with a single int field, or something like that, then that would help a little. To really solve this problem, you need information hiding, which C doesn't have except through questionable hacks.
What's a "character"? A codepoint? A glyph? Is "fi" a single character? How about "ß"? "Ȣ"? "IJ"?
When programmers get answers to these questions wrong, the code that they write ends up being broken for someone out there. And they do get it wrong if their native culture instills a wrong kind of "common sense" about scripts. Which is precisely why we need more stuff like str.len_utf8_bytes() - because it forces the person writing it to consider their assumptions.
Yep. I think about this stuff a lot and I still mess this up all the time. I’ve come to realise that string.length in javascript is a footgun. Basically every time I use it, my code is wrong when I test with non-ascii characters.
I’ve spent the last decade writing javascript and I’ve never once actually cared to know what half the UTF16 byte length of a string is.
The only legitimate uses are internal in javascript (since other parts of JS make that quantity meaningful). Like using it in slice() or iterating - though for the latter we now have Unicode string iteration anyway.
I don't know these, someone who does could properly tell you.
The implementation could fallback to "glyph" or "codepoint" (don't know what those are exactly) if it is unsure. Mostly right is better than nearly always wrong (= returning number of bytes) IMHO.
> How about "ß"?
That's one character.
> When programmers get answers to these questions wrong, the code that they write ends up being broken for someone out there.
So? Returning the number of bytes would also be wrong.
Renaming len to len_glyphs will just result in most programmers typing more and some accidentally using len_utf8_bytes (returns the number of bytes?) where len_glyphs would be less wrong.
I would always make a local variable for things like this, to avoid magic numbers (especially if a function signature has several numeric arguments). Then you can explicitly put the units in the variable name, e.g. duration_s = 300 and pass that. It's fine if the signature tells you the units, but it doesn't help anyone reading the code if you have poll_file_descriptors(read_descriptors, write_desciptors, 300).
You have to read the documentation. But you need to do that in order to be able to use the API properly anyway.
The point the article is making is not about making it easier to write a line of code, but about making it easier to read a line of code. Given that most lines of code are read many more times than they are written, this is a good thing to focus on.
"Programs must be written for people to read, and only incidentally for machines to execute."
― Abel and Sussman, Structure and Interpretation of Computer Programs, 1984
Being forced to read the documentation carefully every time you call the method is really bad UX though. And the approach in the article (let ms = 5; sleep(ms);) can be wrong. Maybe the method is actually taking microseconds not milliseconds and this causes a bug. I can also imagine linters (or other humans) fighting this style, since it’s longer, and something you have to actively do every time you call the method.
Putting the units in the method name (when you can) fixes all of this. Sleep_milliseconds(5) is impossible to misuse or leave undocumented.
This is where Objective C brings subtle magic with mid-function name arguments. Sure it's crazy verbose but insanely readable:
printFile(file: File)withDelayInSeconds(delaySeconds: int)andPrintColor(PrintColor: UIColor)
It’s actually just an obj-c method call. There’s no temporary builder object (or associated class) that needs to be implemented and instantiated like you’d need for a builder.
I've heard of some Ada coding standards that require this in all variable names. It must have made the code awfully clumsy, but as the examples in OP show, it can be made nice. So the general advice is good. I'm slightly disappointed that the Haskell library didn't use a newtype, e.g. threadDelay (Microseconds 300).
Haskell has a couple libraries that would be great here; either the excellent time library, or the very powerful dimensional library with full statically typed SI units. Of course for something as core as threadDelay, a newtype is more appropriate as you say.
Another approach (used somewhat by Python, at least for time units) is use SI units or some other standard or convention, and be willing to use floating point numbers for measurements. That was considered bloat in the old days, but reasonable general purpose computers these days almost always have FPU hardware.
"Native" Ada way would be to declare units in types and require explicit casts (also, you can prevent casting to unsupported types, so no retrieving Int64 from hypothetical Duration_Nanoseconds
I prefer using timedelta (or TimeSpan for the .NET crowd) but I’ve run into a somewhat funny resulting problem: often these time values are read in from a config file, so now people need to know/remember the serialized time span format. Like what is “00:50”? Is it fifty minutes? Seconds?
You don't have to use the default serialization format. You can have `timeout_seconds = «int»` or `timeout = «int»s` in your config file, store it internally as timedelta, and convert when you read the file.
Sure, we got used to the format. I have a gist that among other things lists all of the cases, including the harder ones such as "10ms", or "3 days".
FWIW, in "TimeSpan for the .NET crowd", you would write "00:00:50" for (zero hours, zero minutes and) fifty seconds. Hours, minutes and seconds cases are easy now that we know the format.
Yes, you can omit some of the zeros, but your comment above makes the case that for clarity, you should not.
Though you don't actually need to enforce keyword arguments, any good IDE will give you the (positional) arg names if you mouseover or w/e, so as long as the positional arg is named `timeout_ms` instead of `timeout` it should still be fine.
I think the problem is a bit more nuanced, but i don't have a perfect answer.
This is fine but relying on an IDE for code reviews really sucks. I'd much prefer to be able to do it on github. And it sucks for any language which infers types :( Scala is in particular awful for reviewing on github
I'm not sure why but I have a visceral, negative response to this. It might be the best solution, but it definitely /feels/ like the worst of all the worlds.
time.Second*1 gets the same value; it's not overloaded. Well, ok, so what actually happens is that time.Second is a time.Duration, and Duration*int yields Duration (and int*Duration yields Duration).
But the value of time.Second is actually a Duration with value 1000000, IIRC -- it's microseconds. It's just the type that's special, and the int handling here is general over a lot of types.
The illustration is wrong, but the claim is correct; multiplication between units and scalars is just as associative as you'd expect. Multiplying one kilowatt by an hour gives you exactly the same result as multiplying 1 by a kilowatt-hour.
2 * 3 * time.Second is the same whether you group 2 * (3 * time.Second) or (2 * 3) * time.Second (namely, the implicit grouping under left-associativity).
You wouldn't normally write time.Sleep(time.Second * time.Second) because your units wouldn't work out. (Apparently you can write that in Golang; it's just very sketchy and results in a 30-year sleep.)
But from a mathematical point of view, the relationship between a unit and its coefficient is that you're multiplying them together. Why would it be weird to overload the multiplication operator to represent multiplication?
Is it? In most languages you do something like `time.Sleep(1 * 1e6)` instead at which point it could be a second, a few minutes, a day, who really knows?
I'm just not seeing any major downsides of this, keep in mind `time.Second` isn't the only one of its kind, you have millisecond, minute, hour, etc etc.
Rust has a similar-ish API for durations, Duration::from_milis(1000) or Duration::from_secs(1) in the type system, and the method can just take a Duration struct and transform it into whatever internal representation it wants.
There is a Duration::new() constructor that's more ambiguous, but it's your choice as a dev to be ambiguous in this instance, and code review should probably catch that.
Yeah, Rust is one of the few languages that gets it right! And before they had the `Duration` type with `thread::sleep(d: Duration)`, there was `thread::sleep_ms(ms: u32)`, which is also unambiguous.
Actually taken almost verbatim from the report summarizing a real and subtle bug (distributed across multiple files) in code written by definitely-not-novices.
Duration of a month in seconds? Before you balk at the idea, there exists a definition of a constant month duration for accounting stuff. I you hate dates - and yourself - try accounting, there's mind boggling stuff that makes the engineer mind recoil in absolute terror.
Alas, no. It's because ActiveSupport's duration arithmetic is not distributive under conversion.
The expression on the left hand side advances time (as a domain object) by exactly a month, then converts the result to integer unix time. The expression on the right adds 2629746¹ to the current unix time.
The conversion becomes dangerously magical in the presence of shared code that accepts both object and integer representations of time & duration. A consumer from one part of a system can inadvertently obtain different results to another unless they use identical calling conventions.
[1] this is 1/12 of the mean length of a gregorian year²
Oh wow. This is totally make sense when you think about it, but something that'll never cross my mind when casually checking the code. I guess this is why python's timedelta doesn't have month unit as the length of a month is highly context dependent.
huh? it's us millenials who decided that all dynamic typing was immoral and wrong. Back in the day Gen-Xers on HN and slashdot were talking about how great common lisp and ruby were.
I’m not a Go developer, but I understand that from a type and mathematical theory perspective Go’s time.Duration is extraordinarily awful, because of Go’s simplistic type system.
int64 * Duration → Duration and Duration * int64 → Duration both make sense, but I gather this only works with constants. For other values, I believe Go only gives you Duration * Duration → Duration which is just wrong, wrong, wrong, requiring that one of the two “durations” actually be treated as though unitless, despite being declared as nanoseconds.
In the end, it’s probably still worth it, but it’s a case of Go trying to design in a certain way for ergonomics despite lacking the type system required to do it properly. I have found this to be a very common theme in Go. Also that it’s often still worth it, for they’ve generally chosen their compromises quite well. But I personally don’t like Go very much.
All that, and yet I don't see a single example of what would be "correct", or an example language that does it better. This just comes off as poorly thought out rant.
In my opinion, it is well designed. First of all, who is multiplying time.Duration against itself? I've been programming Go for a few years basically every day, and I've only ever seen the package constants used by themselves, or with untyped constant. I think it's a great syntax, better than any example in the article, as you don't have mystery numbers.
To call it out specifically: this does not include `duration * duration = duration`
Go is currently allowing that, which makes `delaySecs * time.Second` a billion times larger than it appears to intend. I've personally run across code that has this kind of flaw in it... at least several dozen times. It's the kind of thing that's only noticed when it misbehaves visibly while someone is watching it.
(I read a lot of other-teams' code, which is in various states of quality and disarray)
And it’s not just that Go allows that, but that that’s actually the only general way of doing it, as Go only allows duration * scalar in constant context (which is admittedly all most people do with durations, which is why I say it’s still probably better than Go did it this way, given their deliberately limited type system).
What they're suggesting is that `time.Duration` should not be an int64.
1 second * 1 second = 1 second²
1 meter * 1 meter = 1 meter²
1 meter / 1 second = 1 m/s
Those are not user errors, those are physical values. A physical value is two things:
- a scalar (int64, float, ...)
- a unit (meter, second, inches, ...)
If the type system of your programming language does not allow you to define units, this should at least be a structure with a scalar and an enum, and functions to cast from one unit to another (if possible).
I would argue it is actually three things: a scalar, a unit, and an indication of error – which is at least another scalar, but there are multiple ways of expressing error, so it might require more than just a single scalar (such as an interval and the probability the actual value lies within that interval.)
> If the type system of your programming language does not allow you to define units, this should at least be a structure with a scalar and an enum
Ideally more than just an enum – Newton = kg*m*s^-2 (equivalently kg^1*m^1*s^-2) – which suggests a set of pairs (unit and exponent).
Yes, thank you for the precisions, this just make my point stronger: int64/float are very ill-suited to represent such values.
And it's especially true for time units.
For example, "how many seconds is one month?" does not make sense, but "how many seconds is january/february/march?" does make sense. The unit "month" does not really exist, each calendar month is its own unit.
And "february" is not even a "stable" unit because sometimes it's 28 days, sometimes it's 29 days. Even a minute can some rare times be 61 seconds.
This is why in physics, we use seconds multiplied by powers of 10 and nothing else.
To my knowledge, there is not a single programming language that differentiate a "scalar" and a "quantity" (scalar, unit, error).
The provided example is pretty rough, and I'm sure it's occurred in the wild. Sure, put the units in the variable name, and it encourages this kind of mistake, because time.Duration is not "seconds", it is a duration. The variable name should match the API of time.Sleep, which takes a duration. The variable should be named delay. A variable named delaySecs is the same kind of maintenance headache as a variable named "two_days_ago = 2.days.ago" in ruby.
The variables used for accepting and parsing input are the ones that should have units in them in this example. Although if you need a delay specified, it's valuable to be explicit and robust in the input
and accept a string time.ParseDuration understands. Then you don't have this units problem in your variable naming at all, allows easier input of wider ranges of values by the operator, and makes input validation (if only a subset of durations are allowed) more concise and consistent.
I've seen a lot of code at my last job in Go where all duration variables included their units. It was amazingly bad Go code (it was built in part of the projects PoC by new Go devs) but it doesn't help that for the most part it did work.
Time was honestly our biggest source of bugs by far. Although adding time.Time ended up being more problematic than durations which were mostly only constructed like that in tests
One alternative is rust Duration, which makes you spell out all your arithmetic operations. But this is exactly the approach taken by go time.Time, so the part about the type system being incapable or whatever is kinda misguided. https://doc.rust-lang.org/std/time/struct.Duration.html
Once you go beyond constants (which in practice means literals, I think, but I’m not conversant enough in Go to be confident), Go requires that you multiply Duration by Duration—you can’t multiply it with a scalar outside of constants. In other words, as soon as a scalar multiple becomes a parameter rather than a constant, you can’t just do `n * duration`, but have to do something more like `Duration(n) * duration`, which is obviously physically wrong for a system of units, because the unit should be time squared, not time.
As for languages doing it better, approximately every single language that has strong static typing and uses dedicated types for times does it better. Rust is the one I’m most familiar with and comfortable with.
You seem to be confusing the Duration type with Duration values. Yes, if you insist on using a typed value, instead of an untyped constant, then that value needs to be type Duration.
But Duration(1) is way different than time.Second. honestly it just sounds like you don't know the language, and aren't willing to learn it. Go is not Rust. Things are different, that doesn't mean Go sucks.
The entire purpose of the distinction that I’m remarking on is that Duration * Duration → Duration is mathematically utterly incorrect, and especially super misleading when the base quantity for the unit is nanoseconds rather than seconds, yet that is what Go requires, beyond constants, which it special-cases. To be sure, with durations, the distinction doesn’t matter much because arithmetic performed is with constants, and that’s why I say that Go is probably still better with this wonky unit scheme than with entirely unitless quantities, but there are plenty of situations where you will want to multiply durations by typed numbers, and so you’re forced to do the mathematically-ridiculous `Duration(n) * duration` rather than `n * duration`.
You’re looking at this from the application perspective, where with the specific example of durations constant multiplication is certainly far, far more common. But you’re discounting library concerns, where it would not be out of the ordinary to receive a time.Duration and an int64 from parameters or a struct or similar.
This is also pretty typical of the trade-offs Go makes: it focuses on making things nice for the application writer, mostly pretty successfully, but at the regular cost of pain and with serious typing compromises for the library writer.
I mean in their defense I see almost nobody doing this right... Like to do full SI you really need 7 rational numbers, maybe a sort of inline “NaN” equivalent for when you add things with incommensurate units... you might also want display hints for preferred SI prefixes (might just be a dedicated format type), and while you're at it you might as well use a Decimal type instead of doubles, oh and probably these numbers should have an uncertainty in them, so probably you want a modular system where you can mixin units or mixin uncertainty and you can start from a base of doubles or decimals or, hell, you start experimenting with continued fractions...Sigh. The real world is complicated.
Every implementation of units is secretly trying to be Moment.js, basically.
Company i worked for 20 years ago had commercial engineering modelling program that did all physical types correctly and did scaling for user but it was fairly unique in scope and like you say almost all programming languages fall short here and it had its own quirks.
All you need is a language that actually incorporates units of measure into the type system - i.e. you can define units orthogonal to types (including relationships between units), and then you can specify both the unit and the underlying numeric type in a declaration.
C++11's std::duration manages just fine without that much scope bloat. operator* for two durations is simpley not defined so will lead to a compile error.
my 2c, I think the issue is simply in the name collision of units and the constants. (ie, "seconds" and time.Seconds) .
In reality most programming languages do not have units what so ever (built into the language, maybe tacked on as a library after the fact). They have int64s, a unitless value that just keeps track of whole numbers of whatever it semantically means to the developer. If we want to truly have units in values then we either need 1st class language support (including syntactical support) or a rich library that doesnt just "put units in [symbols]". One could probably make it happen with a type that keeps track of units
Like many things with Go, its approach seems reasonable and simple at first, but allows you to accidentally write code that looks right but is very, very wrong. For example, what do you think this code will do?
Now I insist on using the durationcheck lint to guard against this (https://github.com/charithe/durationcheck). It found a flaw in some exponential-backoff code I had refactored but couldn’t easily fully test that looked right but was wrong, and now I don’t think Go’s approach is reasonable anymore.
The type of this is `time.Duration` (or int64 internally), not `time.Second` (which is a const with a value).
I agree, though, that this is not quite sound, because it can be misused, as shown above with `time.Sleep(delaySecs * time.Second)`.
In Kotlin you can do `1.seconds + 1.minutes` but not `1.seconds * 1.minutes` (compilation error), which I quite like. Here is a playground link: https://pl.kotl.in/YZLu97AY8
Certainly, but for that the type system should be rich enough to support unit designators.
I know how to implement that in Haskell, and that it can be implemented in C++ and Rust. I know how to logically implement that in Java or Typescript, but usability will suck (no infix operators).
Go tends to cover such things by incorporating them directly in the language. But then it tends to not cover them at all because it would "overcomplicate" the language...
For a good example of what it looks like when somebody does bother to do it, see F# units of measure.
This looks to me like the semantics are good but the implementation details are broken. 1 * time.Second * time.Second semantically reads to me as 1 second. If time.Second is some numeric value, that’s obviously wrong everwhere unless the type system reflects and enforces the unit conversion.
> 1 * time.Second * time.Second semantically reads to me as 1 second.
Which is wrong, 1s * 1s = 1s².
For example, the force of gravity is expressed in m/s² and describe an acceleration (m/s / s, aka a change of velocity per time units, where velocity is a change of distance per time units).
But assuming your comment is not a joke. You probably want to convert minutes to seconds in order to work with the same units, then add the scalar parts together.
That's how you deal with different quantities: convert to same unit, add values.
This is analog to fractions: 1/2 + 1/4 = 2/4 + 1/4 = (2+1)/4 = 3/4.
In basic middle school math it’s common to multiply different units as a basic conversion mechanism. Multiplying by the same unit is semantically equivalent to “x times 1 is identity(x)”, and other cross-unit arithmetic implies conversion to ensure like units before processing. A typed unit numeric system would imply that to me. It would not imply I’m multiplying the units, but rather the scalar value of the unit.
> In basic middle school math it’s common to multiply different units as a basic conversion mechanism
EDIT: Yes, you multiply the units `2m * 2s` : you first multiply the units to get: `m.s`. This is what I say: you convert everything to the same units before doing the calculations.
> Multiplying by the same unit is semantically equivalent to “x times 1 is identity(x)”
This is wrong.
1kg * 1kg = 1kg² period.
What you're saying is `2kg * 1 = 2kg`, which is right, because `1` is a scalar while `2kg` is a quantity. This is completely different than multiplying 2 quantities.
> It would not imply I’m multiplying the units, but rather the scalar value of the unit.
That's where you're wrong. When doing arithmetic on quantities, you have 2 equations:
x = 2kg * 4s
unit(x) = kg * s = kg.s
scalar(x) = 2 * 4 = 8
x = 8 kg.s
Or
x = 5m / 2s
x = (5/2) m/s
x = 2.5 m/s
There is a meaning to units and the operation you do with them. `5m / 2s` is 5 meters in 2 seconds, which is the speed `2.5 m/s`.
`2m + 1s` has no meaning, therefore you can't do anything with the scalar values, and the result remains `2m + 1s`, not `3 (m+s)`.
Units can be expressed in terms of other units, and you can arbitrarily pick one unit as a base and then express the rest in it. But the key word here is "arbitrarily".
If multiplying by the same unit yield the same unit, then how did you compute area or volume in school?
Wait, would you really expect 1m * 1m to be anything other than 1m²? When does it ever happens that you want to multiply to non-unitless[1] measurements and not multiply the units???
I expect 1 * m = 1m, and 1 * m * m = 1m because applying a unit doesn’t inherently have a value of that unit associated with it. (1 m) (1 m) obviously equals 1m^2, but ((1 m) m) is not the same expression.
If you look upthread, there was a mention of F# unit types. Taking off my programmer hat and returning to my middle school anecdote which also evidently made no sense: expression of a unit without a value is (or should be to my mind, based on my education) a cast, not a computation of N+1 values.
- 1 is unitless
- 1 * m casts the value to a value 1 of unit m = 1m
- 1 * m * m casts the value 1 * m = 1m to 1m then casts 1m to m which = 1m
Admittedly my educational background here might be wildly unconventional but it certainly prepared me for interoperable unit types as a concept without changing values (~precision considerations).
> If you look upthread, there was a mention of F# unit types.
And the syntax is `3<unit>` not `3 * unit`
- 1 is a scalar
- 1m is a quantity
- 2 * 1m "casts" 2 to a meter, but really this is just multiplying a quantity by a scalar
- 2 * 1m * 1m "casts" 2 to meter², multiplying 2 quantities then by a scalar
I insist, `1 * m` does not make sense. This is not a valid mathematical expression, because a unit can never be on its own without a value.
> expression of a unit without a value is (or should be to my mind, based on my education) a cast
There is no casting in math. Mainly because there is no types, only objects with operations. A vector is not a scalar and you can't cast it into a scalar.
A quantity is not a scalar either, and you can't cast one into another.
A quantity is an object, you can multiply 2 quantities together, but you can't add them if they are different. You can multiply a quantity to a scalar, but you still can't add a scalar to a quantity.
Well, yeah, F# represents this at the type level. Which I’ve said elsewhere in the discussion is preferable. Not knowing Go, but knowing it only recently gained generics, I read multiplying by `time.Seconds` (which does not have a visible 1 associated with it) as perhaps performing an operator-overloaded type cast to a value/type with the Seconds unit assigned to it. I’ve since learned that Go also does not support operator overloading, so I now know that wouldn’t be the case. But had that been the case, it isn’t inconceivable that unitlessValue * valuelessUnit * valuelessUnit = unitlessValue * valuelessUnit. Because…
> I insist, `1 * m` does not make sense. This is not a valid mathematical expression, because a unit can never be on its own without a value.
Well, if you insist! But you seem to be imposing “mathematical expression” on an expression space where that’s already not the case? Whatever you may think of operator overloading, it is a thing that exists and it is a thing that “makes sense” to people using it idiomatically.
Even in languages without overloading, expressions which look like maths don’t necessarily have a corresponding mathematical representation. An equals infix operator in maths is a statement, establishing an immutable fact. Some languages like Erlang honor this, many (most? I strongly suspect most) don’t! I couldn’t guess without researching it also treat infix = statements as an expression which evaluated to a value.
The syntax of infix operators is generally inspired by mathematical notation, but it’s hardly beholden to that. The syntax of programming languages generally is not beholden to mathematical notation. Reacting as if it’s impossibly absurd that someone might read 1 * time.Seconds * time.Seconds as anything other than 1 * 1s * 1s is just snobbery.
Not knowing Go, I focused on the syntax and the explicit values, and tried to build a syntax tree on top of it. I’m not a fan of infix operators, and I am a fan of lisps, so my mental syntax model was (* (* 1 time.Seconds) time.Seconds)), which still doesn’t “make sense” mathematically, but it can make sense if `*` is a polymorphic function which accepts unquantified units.
> Not knowing Go, but knowing it only recently gained generics, I read multiplying by `time.Seconds` (which does not have a visible 1 associated with it) as perhaps performing an operator-overloaded type cast to a value/type with the Seconds unit assigned to it.
This sums up your incomprehension. `time.Seconds` is just a constant. An integer with the value `1_000_000` meaning 1 million of nanoseconds.
In an expression of the form `a * b` you should always read `a` and `b` as constants. This is true for EVERY programming language.
> it isn’t inconceivable that unitlessValue * valuelessUnit * valuelessUnit = unitlessValue * valuelessUnit.
It is. For example, what would be the meaning of this:
struct Foo {
// ...
}
2 * Foo
Valueless unit (or any type) is just not a thing, not in math, not in any programming language.
> But you seem to be imposing “mathematical expression” on an expression space where that’s already not the case? Whatever you may think of operator overloading, it is a thing that exists and it is a thing that “makes sense” to people using it idiomatically.
Operator overloading works on typed values, not "valueless" types. In some programming languages (like Python), class are values too, but why implement `a * MyClass` when you can write `MyClass(a)` which is 100% clearer on the intent?
Using operator overloading for types to implement casting is just black magic.
> expressions which look like maths don’t necessarily have a corresponding mathematical representation
Programming languages and the whole field of Computer Science is a branch of mathematics. They are not a natural language like english or german. They are an extension of maths.
> An equals infix operator in maths is a statement, establishing an immutable fact.
An operator only has meaning within the theory you use it.
For example:
`Matrix_A * Matrix_B` is not the same `*` as `Number_A * Number_B`
`1 + 2` is not the same `+` as `1 + 2 + 3 + ...`
`a = 3` in a math theorem is ont the same `=` as `a = 3` in a programming language (and that depends on the programming language)
As long as the theory defines the operators and the rules on how to use them, it does not matter which symbol you use. I can write a language where you have `<-` instead of `=`, and the mathematical rules (precedence, associativity, commutativity, ...) will be the same.
> Reacting as if it’s impossibly absurd that someone might read 1 * time.Seconds * time.Seconds as anything other than 1 * 1s * 1s is just snobbery.
First, that's not what I said. You should read that as `scalar * constant * constant` because reading that as `scalar * unit * unit` does not make sense nor in math, nor in any programming language.
If caring about readability and consistency is snobbery, then so be it.
> Not knowing Go, I focused on the syntax and the explicit values, and tried to build a syntax tree on top of it.
And the syntax is pretty explicit, because it's the same as math or any programming language: `scalar * constant * constant`. This is why using math as a point of reference is useful, you can easily make sense of what you're reading, no matter the syntax.
> I am a fan of lisps, so my mental syntax model was (* (* 1 time.Seconds) time.Seconds))
I still read this as `(* (* scalar constant) constant))`. And I expect your compiler/interpreter to throw an error if `time.Seconds` is anything without a clear value to evaluate the expression properly.
And I would expect to read `(* (* 1 (seconds 1) (seconds 1)))` as `scalar * quantity * quantity`, and I would expect to get square seconds as an output.
Anything else would not be correct and have little to no use.
All unit conversions are actually multiplications by the dimensionless constant 1, i.e., no-ops.
Let's say that you want to convert `2 min` into seconds. You know that `1 min = 60 s` is true. Dividing this equation by `1 min` on both sides is allowed and brings `1 = (60 s) / (1 min)`. This shows that if we multiply any value in minutes by `(60 s) / (1 min)`, we are not actually changing the value, because this is equivalent to multiplying it by 1. Therefore, `2 min = 2 min * 1 = 2 min * (60 s) / (1 min) = 2 * 60 s * (1 min) / (1 min) = 120 s`. We didn't change the value because we multiplied it by 1, and we didn't change its dimensionality ("type") because we multiplied it by a dimensionless number. We just moved around a dimensionless factor of 60, from the unit to the numerical value.
I think that you misremember, or didn't realize that to convert minutes into seconds, you were not multiplying by `60 s` but by `(60 s) / (1 min)` which is nothing else than 1.
You can just do `1 * time.Second + 2 * time.Minute` to do that. Adding times works intuitively. It's multiplying durations that gives you accelerations.
That’s similar to Crystal. All numbers have built in methods to convert them to a Time::Span object.
So I could have a function that takes a Time::Span instead of an Int, like:
def sleep(num : Time::Span)
# do something here
end
Go's time package is famously horrible. First they didn't expose any monotonic clocks only wall time. Then after some public outages, like time travelling backwards for Cloudflare they were forced to act. In the end they managed to fold monotonic clocks into into the original type to cling on to the "Go just works" mantra, but adding even more edge cases.
> RRDNS is written in Go and uses Go’s time.Now() function to get the time. Unfortunately, this function does not guarantee monotonicity. Go currently doesn’t offer a monotonic time source (see issue 12914 for discussion).
In swift I quite like DispatchTimeInterval's approach [1] (see Enumeration Cases). In most of my projects I end up adding a simple extension to TimeInterval to get the same behavior. Which makes reasoning about time very simple eg:
Date().advanced(by: .hours(2) + .seconds(10))
I'm honestly not sure why TimeInterval doesn't include this representation by default.
Or join the ranks of your peers who have seen the light and use types.
Documentation should always be secondary to an obvious, descriptive interface. We've evolved beyond register positions and phonebook-style paper documentation. Use the tools available to you.
The article addresses this somewhat using Python's type hints. If I give you his signature, can you intuitively tell me what unit is being taken in by the function?
void addPadding(int height) {
}
Types are useful, and even as a Python programmer I gravitate towards type hints for all new code, but any application where a programmatic type maps to a real-world type with common conversions (like, say, pixels, em, en, millimetres, centimetres, or inches in the above example) tends to be a victim of the same issue, where the type system isn't expressive enough to clearly describe the real-world type being assumed by the function.
That's because your not using the type system at all in your example. Change it to "addSomething(Length height)", and have constructors for Length.ofCm(2), Length.ofMeters(5) etc.
Sure, but this isn't a solution that's unique to statically-typed languages, and the syntax can get more awkward if you use a language without good OO support.
I also haven't come across a thorough implementation of unit conversions to do stuff like this (not that it's not a pattern that works -- I personally like this); it might be common in domains where dealing with real units is central to the business, but in industries where that's done incidentally, convenience classes like this just aren't around (in my experience).
Discord API is guilty of one of these very examples, they send a retry-after header on 429 responses, but the thing is.. is it in Bananas? Apples? Elephants?
Unfortunately it's part of http. One thing you can do is to send both the standard Retry-After header for tools that rely on it, and a nonstandard but unambiguous Retry-After-Seconds. That makes responses self-documenting. (One downside is that you now have two numbers, and if you introduce a bug that makes them different, it will be more confusing.)
I recently worked on some disk file formats (.vmdk, .vhd), and I always put the units in the name, because I'm always switching byte, sectors, blocks. Same for addresses, is it a LBA on the virtual disk, or an offset in the disk image file.
Or use an IDE? Here[0] is a screenshot of the Java example in idea, not only does it show an inlayed parameter name hint, but simply mousing over the method will show you the documentation.
It also doesn't make a unit error stick out, as you have to take the time to specifically hover to check. What I mean by this is consider you've opened a mature code base and are browsing around, and scroll past:
timeout = 60000;
I'd assume this is milliseconds, and whether I check would depend on what I'm doing and probably also my mood.
Whereas if I see:
timeoutSeconds = 60000;
It'll draw my attention and no matter what I'm doing I'll either open a bug or just fix it.
in the genre of naming things, some related things to explore:
- avoiding naming things if you can help it
- using tooling to autogenerate names
- avoiding too short, likely overloaded names like `id`, `name`, and `url`
- don't choose lazy pluralization - eg instead of `names/name`, use `nameList/nameItem`
- encoding types to make Wrong Code Look Wrong, a famous Spolsky opinion (lite hungarian notation)
- coming up with grammars for naming, eg React had an exercise to name its lifecycles combinations of THING-VERB-ACTION, like `componentDidMount`, before open sourcing, which helped learnability
>- don't choose lazy pluralization - eg instead of `names/name`, use `nameList/nameItem`
Isn't this just extra noise? If the type of the variable is an Array wouldn't `nameArray` be superfluous? Worse still is if the type changes but the name stays the same.
I get the advice is probably Javascript specific, but even in a Typescript world it doesn't make much sense to me to do this kind of type-in-name encoding.
Exactly this. In many languages the compiler will help you.
But this has bitten me in Ruby, JavaScript and PHP several times. Runtime errors and downtime. Most recent: autocompled some updatedCartsItems when it had to be UpdatedCartItems. Both were used in the same class. Had they be named sensible, like CartListWithUpdatedItems and UpdatedItemList or something better, I'd have saved myself hours of WTFing through CI logs.
It communicates my intent to the reviewer and future readers of the code that: 1) I mean to set the duration to 5 minutes, which is easier parsed by humans than 300 seconds. 2) I'm passing seconds into time.sleep, which makes any mistakes I make more obvious.
I'm not saying time.sleep can't be improved but my method makes it easier to find any mistakes I've made in the future.
As a demonstration, reading your code makes it more obvious that you've passed the wrong unit into time.sleep.
Got it — so it's more about mitigating the badness when it's somebody else's API.
Seems reasonable! :)
When I encounter these sorts of methods (which is surprisingly rare these days) I tend to double-check what units the method takes and additionally add a comment above my call saying "`sleep` takes duration in seconds", just to give future readers more ways to check whether I screwed up.
I would go one step further and suggest that all physical quantities should either have the units in the identifier name or encoded in the type system. Meters, seconds, milliamps, bytes, blocks, sectors, pages, rpm, kPa, etc. Also it's often useful to explicitly distinguish between different unit qualifications or references. Seconds (duration) versus seconds-since-epoch, for example. Bytes versus page-aligned bytes, for another.
Having everything work this way makes it so much easier to review code for errors. Without this means that as a reviewer you must either trust that the units and conversions are correct or you should do some spelunking to make sure that the inputs and outputs are all in the right units.
100%. This is a baseline requirement where I work. If you don't either include the units in the identifier name, or use the type system where possible, your code is not getting merged.
The only people I've ever met that think this is unnecessary are also the same people that ship a lot of bugs for other people to fix.
Not OP, but I see that a lot in the aerospace and heavy industry sectors.
We keep laughing about "if we engineered bridges as we engineer software" ... the truth is that the areas where correct software matters tend to write very robust code, and the rest of the industry would be well advised to take notice and copy what they see.
Of course, writing robust code is a skill, and it takes extra time.
> and the rest of the industry would be well advised to take notice and copy what they see
I don't agree.
There is a good reason that aerospace industry writes robust code - in invests time (money) to avoid disasters that could cause, among other things, loss of human life.
On the other hand if for example some webform validation fails because the code was written as fast (as cheap) as possible, who cares really.
That is just a tradeoff, in aerospace industry you spend more to lower the risk, somewhere else you don't.
Yes, sure, but a "billion dollar company" in this case does not represent the whole industry.
You can probabbly find a some specific non-critical case in aerospace industry, but surely based on that example one would not suggest that the whole aerospace industry should just copy what they see in frontend dev.
Context matters, there are exceptions, but the standard practices are based on average scenario, not on extremes.
I'm not saying that all code should be developed under standards designed for embedded control system software. I'm just saying that "oh, it's just web stuff so it can't be important" is ridiculous.
>>> and the rest of the industry would be well advised to take notice and copy what they see
>> I don't agree.
>> [web form validation example]
>> That is just a tradeoff, in aerospace industry you spend more to lower the risk, somewhere else you don't.
> I'm just saying that "oh, it's just web stuff so it can't be important" is ridiculous.
This feels like a straw man.
The original argument is that the rest of the industry (that includes web, but a lot of other parts also) should copy what they see in aerospace industry.
I believe that would not be appropriate for the rest of the industry to just copy practices from any other part because each segment has its own risk factors and expected development costs and with that in mind developed their own standard practices.
Nowhere did I state that the "web stuff can't be important" nor that there is no example of web development (form validation) where the errors are insignificant.
That said,
I will go back to the "billion dollar company that can't fulfill orders" / "million people who suddenly can't use their bank online" catastrophe;
this happens all the time. Billion dollar company doesn't fulfill orders, error is fixed, orders are fulfilled again, 0.0..01% of revenue is (maybe) lost.
In aerospace industry a bug is deployed, people are dead. No bugfixing will matter after that moment.
How can this two industries have the same standards of development?
It takes time to learn, and to learn the value, and time to agree with the team that it's sensible. With this sort of thing - proper naming of variables - I disagree that it takes longer at point of use.
Not the commenter, but I work in scientific software development and it's just a minefield of different units, so being explicit is generally very useful. Even if you can assume you can stick to metric (you can't), what different users want varies across countries. For e.g. here in the UK we often want to represent data as millilitres, but in France the same measurements are often centilitres.
It varies across different users from the same city! The same family, even!
One piece of equipment I just finished working on measured and displayed vacuum at different sensors in PSIg, kPa, Pa, mmHg, and inHg. The same machine, the same measurement at different stages in the process, five different units!
Also not OP, but I work on graphics software and we frequently deal with different units and use strict naming systems and occasionally types to differentiate them.
Even more fun is that sometimes units alone aren't sufficient. We need to know which coordinate system the units are being used in: screen, world, document, object-local, etc. It's amazing how many different coordinate systems you can come up with...
Or which time stream a timestamp comes from, input times, draw times (both of which are usually uptime values from CLOCK_MONOTONIC) or wall times.
As a bonus, coordinate systems can be left-handed or right-handed, and the axes point in different directions (relevant when loading models for example).
A better example would be seconds to minutes. I think i recall a jwt related cve related to timestamps being misinterpreted between sec/ms for example.
Adding seconds to minutes can actually make sense. A minute plus 30 seconds is 90 seconds, or 1.5 minutes. Whether your type system allows this, though, is up to the project.
You can't add seconds to kilometers, or to temperature, or to how blue something is.
Ideally, hardware execution would happen on a language that can be proven correct and does not allow the programmer to make syntactic or semantic errors.
if you type check, then it ensures that only a 'second' can be passed to the function. This requires you to either create a second, or explicitly cast to one, making it clear what unit a function requires.
As per the article, if you dont have proper names and just an 'int', that int can represent any scale of time...seconds, days, whatever.
In python youd need something like mypy, but in rust you could have the compiler ensure you are passing the right types.
Having a type system to figure this out for us would be great, but there are languages where this may not be possible. As far as I know, Typescript is one such example, isn't it?
Depends. Yes, newtyping is pretty awful in TS due to its structural typing (instead of nominal like Rust for example).
You could perhaps newtype using a class (so you can instanceof) or tag via { unit: 'seconds', value: 30 } but that feels awful and seems to be against the ecosystem established practices.
This is indeed one of my gripes with TS typing. I'm spoiled by other languages, but I understand the design choice.
export interface OpaqueTag<UID> {
readonly __TAG__: UID;
}
export type WeakOpaque<T, UID> = T & OpaqueTag<UID>;
And then use it like this to create a newtype:
export type PublicKey = WeakOpaque<Uint8Array, {readonly PublicKey: unique symbol}>;
To create this newtype, you need to use unsafe casting (`as PublicKey`), but you can use a PublicKey directly in APIs where a Uint8Array is needed (thus "weak opaque").
I was recently dealing with some React components at work, where the components would accept as an input the width or the height of the element.
Originally, the type signature was
type Props = {height: number}
This naturally raises the question - number of what? Does "50" mean `50px`, `50vw`, `50em`, `50rem`, `50%`?
I've ended up changing the component to only accept pixels and changed the argument to be a string like this:
type Props = {height: `${number}px`}
Of course, if passing a "0" makes sense, you could also allow that. If you want to also accept, say, `50em`, you could use a union-type for that.
I think this could actually work for other units as well. Instead of having `delay(200)`, you could instead have `delay("200ms")`, and have the "ms" validated by type system.
Maybe the future will see this getting more popular:
type WeightUnit = 'g' | 'grams' | 'kg' | ...;
type WeightString = `${number}${WeightUnit}`;
function registerPackage(weight: WeightString): void;
You can simulate type opaqueness/nominal typing with unique tag/branded types in ts. We’re using it on high stake trading platform and it works very well.
A function might take multiple integer arguments, each in different units. Separate types for each unit guarantees you won't pass the wrong integer into the wrong argument.
Eg
func transferRegularly(dollars(10000), days(30))
Meaning clear.
func transferRegularly(10000, 30)
Meaning obscure, error prone and potentially costly
I am always amazed how new languages never pick up this most amazing feature of Python.
Though obviously, this code smells anyway because 1. repetitive transfers are usually in calendar units (eg. monthly, weekly, yearly — not all of which can be represented with an exact number of days), so in Python you'd probably pass in a timedelta and thus a distinct type anyway, and 2. amounts are usually done in decimal notation to keep adequate precision and currency rounding rules (or simply `amount_in_cents`).
Still, I am in favour of higher order types (eg. "timedelta" from Python), and use of them should be equally obligatory for unit-based stuff (eg. volume, so following the traditional rule of doing conversions only at the edges — when reading input, and ultimately printing it out).
One problem with this approach is refactoring. If you wanted to refactor your example with the parameter "amount_in_dollars" then you would either have to continue maintaining the legacy "amount" argument, or break existing code.
So you mean just like with, eg. renaming a function? I agree it's an issue compared to not doing it, but a very, very minor one IMHO, and legibility improvements far outweight it.
Renaming a function comes with the explicit implication that the API has changed. But it might not be clear to someone maintaining a Python application that changing a parameter name might change an argument - that is not the case in any other language (until PHP 8).
I see keyword arguments as slightly different though. The keyword is like the parameter name. The value is still a plain integer and (theoretically) susceptible to being given the wrong integer. In contrast, unit types allow for hard checking by the compiler.
In practice, with good naming it won't make much difference and only shows up when comparing the docs (or intellisense) for an API with how it is actually used.
Well your function could then accept multiple types (Miliseconds, Seconds, Minutes, Hours) and do the conversion between those implicitly.
The units are also extremely clear when they are carried by the type instead of the variable name, where a developer could e.g. change some functionality and end up with a variable called `timeout_in_ms` while the function that eats this variable might expect seconds for some reason.
If it is typed out you can just check if the function performs the right action when passed a value of each time unit type and then you only ever have to worry about mistakingly declaring the wrong type somewhere.
But wether you should really do all that typing depends on how central units are for what you are doing. If you have one delay somewhere, who cares if it is typed or not. If you are building a CNC system where a unit conversion error could result in death and destruction, maybe it would be worth thinking about.
Most answers here are answering your question literally, and explaining why you'd add a type for "seconds". But in reality you shouldn't create a type for seconds, the whole premise of the question is wrong.
Instead of a type for seconds, you'd want a type for all kinds of duration regardless of the time unit, and with easy conversion to integers of a specific time unit. So your foo() function would be taking a Duration as an input rather than seconds, and work correctly no matter what unit you created that duration from:
The type is "duration", not "seconds". "seconds" is the unit. You can think of the unit as an operator that converts an integer to a duration.
The advantages are:
- An integer doesn't tell you if you are talking about seconds, milliseconds or anything like that. What does sleep(500) means? Sleep 500s or 500ms? sleep(500_ms) is explicit
- It provides an abstraction. The internal representation may be a 64-bit number of nanoseconds, or a 32-bit number of milliseconds, the code will be the same.
- Conversions can be done for you, no more "*24*60*60" littered around your code if you want to convert from seconds to days, do fun(1_day) instead.
- Safety, prevents adding seconds to meters for instance. Ideally, it should also handle dividing a distance by a duration and give you a speed and things like that.
Under the hood, it is all integers of course (or floats), which is all machine code, but handling units is one of the things a high level language can do to make life easier on the human writing the code.
> The only people I've ever met that think this is unnecessary are also the same people that ship a lot of bugs for other people to fix.
I find feelings about this depend a lot on how much ceremony the type system involves; and just how many units and references to them there are in the system.
Asking bash coders to write "sleep 5s" instead of "sleep 5" - I doubt you'd get any objections at all.
But if you're putting a foo.bar.Duration on a getDefaultTimeoutFromEnvironment on a setConnectTimeout on a HttpRequest on a HttpRequestInitializer on a NetHttpTransport on a ProviderCredential to make a simple get request? People who've come from less ceremony-heavy languages might feel less productive, despite producing 10x the lines of code.
This is where I divert. You just hard coded seconds into your test. Now your tests that cover this must take seconds to finish; thankfully you were not testing hours or days!
My last shop was a Go shop and one test I think shows this off was an SMTP server and we needed to test the timeouts at different states. The test spun up half a dozen instances of the server, got each into the right smtp state and verified timeouts in under 10ms.
The environment that set the timeout would either be "timeout_ms=500" or "timeout=500ms" (or whatever). This is where you handle that :)
Many timeout functions take seconds as a floating point. So you could time out on 0.05 seconds (5 milis). But now the code is clear and less prone to bugs.
Not sure I fully understood your objection, but the reason I specified seconds is because I presumed the setConnectTimeout to be part of the default HTTP library, which likely doesn't adhere to the same conventions, and that it expected seconds (which seem to be the usual for http libraries as far as I can tell).
Of course if the setConnectTimeout method was part of the same application you could just pass the timeout directly, but at the boundary of your application you're still going to have to specify at some point which unit you want.
The test could simply mock the default value to something reasonable like '.1 seconds' and test that duration instead, so I don't think this is a real problem.
If you're testing things with timeouts it's often a good practice to mock out the system clock anyway. That allows testing your timeouts to be nearly instantaneous and also catches edge cases like the clock not moving forward, having a low resolution, moving backward, ... deterministically.
This is actually revealing a different problem: the system clock as an implicit dependency. YMMV depending on support of underlying libraries, but I will typically make the clock an explicit dependency of a struct/function. In Go, usually it’s a struct field `now func() time.Time` with a default value of `time.Now`.
This example is nice but if you put arguments metadata in the function name, you have to have one main argument, the function name can prove cumbersome if you have 3 or 4 arguments with units like
Values with an intrinsic unit scale up to many units and values. If you declare the parameters of a "calculate" function as USACurrency, Weight and Duration you can write
That's one of the benefits of having it exposed as a type-enforced parameter. setConnectTimeout() could take a Duration, which contains the amount and the unit, and therefore wouldn't care if consumer A provided a timeout in seconds, and consumer B provided a timeout in milliseconds.
with getDefaultTimeoutFromEnvironment() returning a Duration.
Ideally this is consistent throughout the codebase, so that anything that uses a primitive type for time is explicitly labelled, and anything using a Duration can just be called "Timeout" or whatever.
All fair points. In this example I was suggesting what this might look like at the border of the application where you need to talk to some (standard) library which doesn't use the same convention.
> I find feelings about this depend a lot on how much ceremony the type system involves; and just how many units and references to them there are in the system.
Ideally it'd be as simple as:
typealias Dollars = BigDecimal
typealias Cents = Long
that's valid Kotlin, but the equivalent is doable in most languages nowadays (Java being a big exception).
I recommend against that, and use proper (wrapper) types.
I don't know Kotlin, but in most languages if you alias 2 types to the same base type, for example Seconds and Minutes to Long, the compiler will happily allow you to mix all 3 of them, defeating the protection full types would bring.
If I ever have to deal with monetary values in a program where someone thought this was a good idea, ... well, it really won't be the worst thing I’ve ever dealt with, but, still.
(If you have dollars and cents as types in the same program, they darn well better work properly together, which is unlikely to work if they are both just aliases for basic numeric types.)
typealias Cents = Long
typealias Meters = Long
Cents(3) + Meters(4) = 7L
that's exactly the thing we want to prevent.
the classes shouldn't be for units at all, the type should represent the type of unit.
so instead of a class Seconds you should have a class Duration, instead of class Meters you should have a type Distance. that's because the unit of the different types can be converted between each other.
Dollars and Cents are a bit of a bad example because currencies can't be easily converted between each other, as conversion is dependent on many factors that change over time. meters, yards, feet, lightyears, miles, chain, furlongs, whatever describe a multiple of the same thing though, so a different type for each unit isn't necessary, as the input that was used to create the instance isn' usually needed. the counter example would be datetime with timezones - a datetime with a timezone convers a lot more information than the datetime converted to UTC.
>Having everything work this way makes it so much easier to review code for errors.
Had one making me pull my hair put the other day in C#. C# datetimed are measured in increments of 100 nanoseconds elapsed since January 1st 1 AD or something like that. Was trying to convert Unix time in milliseconds to a C# datetime and didn't realize they were using different units. My fault for not reading the docs but having it in the name would have saved me a lot of trouble.
I'm not sure I agree. When I convert fields to DateTime, I remove the unit suffix from the name. The DateTime is supposed to be an implementation-agnostic point in time. It shouldn't come with any units, and nor should they be exposed by the internal implementation.
The factory method used to convert e.g. Unix timestamps to DateTimes, now that should indicate whether we're talking seconds or milliseconds since epoch, for example, and when the epoch really was.
How does the C# DateTime type distinguish between dates and a point in time whose time just happens to be midnight?
Much of the C# code I've seen uses names like start_date with no indication of whether it really is a date (with no timezone), a date (in one particular timezone), or a datetime where the time is significant.
I'm certainly not a C# developer, though my quick reading of the docs suggests that the DateOnly type was only introduced recently in .NET6.
Yeah, before the new DateOnly (and TimeOnly) types, there was no built-in way in C# to specify a plain date. NodaTime[1] (a popular third-party library for datetime operations) did have such types though.
What the heck is with MS and weird datetime precision? I figured out some bug with a third party API was due to SQL Server using 1/300th seconds. Who would even think to check for that if you’re not using their products?
Established doesn't mean it is understandable without documentation. Anyone who is not familiar with it doesn't know why it starts in 1970 and counts seconds. You need to actually open the documentation to know about that, and it's name (be it unix time, epoch, epoch time or whatever) doesn't help in understanding what it is and what unit it is using.
The metric system is also not understandable without documentation, byt you don't need to explain it every time because every living person should have gotten that documentation drilled into them at age ten.
UNIX time is an easy international standard, everybody with computer experience knows what it is and how to work with it.
> anybody who will ever need to call a sleep function
Bullshit.
I never needed to know what unixtime is when I wrote anything with sleep().
All I needed to know is how long in seconds I want the execution to pause for, never ever I needed to manually calculate something from/to unixtime, even when working with datetimes types.
No, but as a person who has had a need for sleep() before, you are also the type of person who could be expected to know what unix time is.
Nobody is saying that the two things need to be connected, the point is that it can be name dropped in a type definition, and you would know what it means.
If they’re using ISO format I don’t really care what they’re counting from. But I care if some ISO dates are preserved exactly and some are rounded to another value… especially when that rounding is non-obvious. It took me months to even identify the pattern clearly enough to find an explanation. Up to that point we just had an arbitrary allowance that the value might vary by some unknown amount, and looked for the closest one.
1/300 seconds is an odd one for sure. In the case of DateTime however, I'd say it is designed to hit as many use cases as possible with a 64 bit data structure. Using a 1970 epoch as is (logically) used for Unix system times naturally misses even basic use cases like capturing a birthdate.
It is quite hard actually to disagree with the 100ns tick size that they did use. 1 microsecond may have also been reasonable as it would have provided a larger range but there are not many use cases for microsecond accurate times very far in the past or in the future. Similarly using 1 nanosecond may have increased the applicability to higher precision use cases but would have reduced the range to 100 years. Alternately, they could have used a 128 bit structure providing picosecond precision precision from big bang to solar system flame out with the resultant size/performance implications.
What precisely could have been changed to make you realize that C# DateTime is not the same as Unix time? Perhaps Ticks could be renamed to Ticks100ns but I'm not sure how to encode the epoch date such that it is not necessary to read any documentation. I suppose the class could have been named something like DateTimeStartingAtJan1_0001 but obviously would have been ridiculous.
Naming is an optimization problem: minimize identifier length while maximizing comprehension.
Having units as part of your types improves legibility for whoever's writing code too, not just reviewing. You won't make (as many) silly mistakes like adding a value in meters to another in seconds.
God I love F#'s unit types. C# is okay and all, but F# is, IMO, the best FP-language-on-a-corporate-backed-VM ever, even if the integration with the underlying VM and interop can get a bit fiddly in places (Caveat, my opinion is about 7 years old).
Sadly it hardly got better, C# gets all the new .NET toys, VB less so, C++/CLI still gets some occasional love (mostly due to Forms / WPF dependencies), and then there is F#.
In my opinion this is not a real problem, since ideally no-one should such meaningless abbreviations in code. Just write giga_years or GigaYears or whatever your style is, problem solved, doesn't get any clearer than that.
Once we get to Gigayears, what is the size of single year? Just 365 days? Or which of Julian, Gregorian, Tropical, Sidereal? At even kilo prefix the differences do add up. Or would you need to specify it?
Days, weeks and months are also fun mess to think of.
This is going to depend on the precision that you need.
(Calculations without associated uncertainty calculations are worse than worthless anyway - misleading due to the inherent trust we tend to put in numbers regardless of whether they are garbage.)
> Once we get to Gigayears, what is the size of single year?
The appropriate system of units is context-dependent. The astronomical system, for instance, has Days of 86,400 SI seconds and Julian years of exactly 365.25 Days; if you have a general and extensible units library, then this isn't really a difficulty, you just need to make a choice based on requirements.
Does the type system handle equivalent units (dimensional analysis)? eg, N.m = kg.m^2.s^-2.
Does the type system do orientational analysis? If not you to assign a value of work to a value of torque and vice versa, as they both have the above unit.
There are several other similar gotchas with the SI. I think descriptive names are better than everyone attempting to implement an incomplete/broken type system.
I see dimensional analysis, but in this table[1], torque and work have the same unit, and that unit is J.
The SI itself states[2]: "...For example, the quantity torque is the cross product of a position vector and a force vector. The SI unit is newton metre. Even though torque has the same dimension as energy (SI unit joule), the joule is never used for expressing torque."
Speaking of astropy units. I had a hilarious issue last week, which was quite hard to identify (simplified code to reproduce):
from astropy import units as u
a = 3 * u.s
b = 2 * u.s
c = 1 * u.s
d = 4 * u.s
m = min([a, b, c, d])
a -= m
b -= m
c -= m
d -= m
print(a,b,c,d)
Output: 2.0 s 1.0 s 0.0 s 4.0 s
Note the last 4.0, while min value is 1.0
The issue is that a, b, c, d are objects when astropy units are applied and min (or max) returns not the value but an object with the minimal value, thus m is c (in this particular case c has the smallest value) so c -= m makes m = 0, so d remains unchanged. It was very hard to spot especially when values change and occasionally either one of a, b, c or d has the smallest value.
In-place augmentation of a working code with units may be very tricky and can create unexpected bugs.
> This is really an issue with Python in general (specifically, mutable types).
Unit-aware values as a type where assignment as mutation is an odd choice though (normal mutable types do not exhibit this behavior, it’s a whole separate behavior which has to be deliberately implemented.) It may make sense in the expected use case (and as you note reflects the behavior of the underlying type), but more generally it's not what someone wanting unit-aware values would probably expect.
You'll want to leave the point floating to floating point numbers, but whenever you interact with legacy APIs or protocols you want a type representing the scale they use natively. You wouldn't want to deal with anything based on TCP for example with only seconds (even if client code holds them in doubles), or with only nanoseconds. But you certainly won't ever miss a type for kiloseconds.
The standard symbol for a year is "a". Using "y" or "yr" is non-standard and ambiguous, and they should be avoided in situations where precision and clarity matter.
Given a powerful enough type system, you can parameterize your types by the ratio to the unit and any exponent. Then you can allow only the conversions that make sense.
Isn't floating point specifically for dealing with large orders of magnitude ?
(Economics of floating vs fixed point chips might distort things though ?)
Also, in the case that you meant this : you might need fractions of even base units for internal calculations :
IIRC banking, which doesn't accept any level of uncertainty, and so uses exclusively fixed precision, uses tens of cents rather than cents as a base unit ?
The Python package astropy extends numpy arrays to include units.[0]
It can convert between equivalent units (e.g., centimeters and kilometers), and will complain if you try to add quantities that aren't commensurate (e.g., grams and seconds).
The nice thing about this is that you can write functions that expect unit-ful quantities, and all the conversions will be done automatically for you. And if someone passes an incorrect unit, the system will automatically spit out an error.
You don't need a type system to do this. Generic operators/functions and composite structures are sufficient and more flexible. Some languages let you encode this in type systems as well, but that's an orthogonal feature.
I'm sorry, but this whole comment section is in some collective psychosis from 2010. You don't need to mangle variable names or create custom types (and then the insane machinery to have them all interact properly)
Have none of you ever refactored code..? Or all of your writing C?
Your library should just expose an interface/protocol signature. Program to interfaces. Anything that is passed in should just implement the protocol. The sleep function should not be aware or care about the input type AT ALL. All it requires is the input to implement an "as-milliseconds()" function that returns a millisecond value. You can then change any internal representation as your requirements change
> Have none of you ever refactored code..? Or all of your writing C?
You seem to ignore the much broader context here: the article wasn't just about code. It included configuration files and HTTP requests.
It's also worth noting that depending on the language in question and the usage pattern of the function/method, using interfaces or protocols can cause considerable overhead when simply using a proper descriptive name is free.
That's also a custom type. But for libraries, custom types for everything in interface definitions are problematic. Let's say you use library A which has some functions that take a time delta, and another library B, that also has functions which take time deltas. Now both library would define their own time delta type, and you have two types for time deltas in your application and most likely need to add an additional 'meta time delta type' which can be converted to the library specific time deltas types. This will explode very quickly into lots of boilerplate code and is a good reason to use 'primitive types' in interfaces.
If you replace 'time delta' with 'strings' then the problem becomes more apparent. Each library defining its own string type would be a mess.
If you are working with a crappy language then that's probably true. But it doesn't have to be a lot of boilerplate and it can be local in scope. In Clojure it's a one-liner.
And sure it can just be doing something as simple as returning an internal value directly or calling some common stringifying method. You do have a good point that you may have redundant stringifying protocols across libraries - which sucks.
> This will explode very quickly into lots of boilerplate code and is a good reason to use 'primitive types' in interfaces.
I feel you were so close and missed :) The natural conclusion would be to have primitive interfaces - not primitive types. This way libraries only need to agree to adhere to an interface (and not an implementation)
I love when types are used to narrow down primitive values. A users id and a post id are both numbers but it never makes sense to take a user id and pass it to a function expecting a post id. The code will technically function but it’s not something that’s ever correct.
This. I really miss it when working outside of F#. I work on scientific code bases with a lot of different units and have been burned by improper conversions. Even with a high automated test coverage and good naming practices, such problems can go undetected.
If your use of a value in units lives for so long as for it to not be clear in what unit it is in or should be in (eg. spans more than 20 lines of code), I think you've got a bigger problem with code encapsulation.
I think the practical problem stems from widespread APIs which are not communicating their units, and that's what we should be fixing instead: if APIs are clearer (and also self-documenting more), the risks you talk of rarely exist other than in badly structured code.
Basically, instead of having `sleep(wait_in_seconds)` one should have `sleep_for_seconds(wait_time)` or even `sleep(duration_in_seconds=wait_time)` if your language allows that.
But certainly use of proper semantic types would be a net win, but they usually lose out in the convenience of typing them out (and sometimes constructing them if they don't already exist in your language).
When I first started to learn Ada, I found it one of the most verbose languages I’ve ever used. Now I find myself practicing those wordy conventions in other languages too.
In my software project, all measurements exist as engineering units since they all come from various systems (ADCs or DSP boxes). We pass the values around to other pieces of software but are displayed as both the original values and converted units. We have a config file that contains both units and conversion polynomials, ranging from linear to cubic polynomials. Some of the DSP-derived values are at best an approximation so these have special flags that basically mean "for reference only". Having the unit is helpful for these but are effectively meaningless since the numbers are not precise enough, it would be like trying to determine lumens of a desk lamp from a photo taken outside of a building with the shades drawn.
Have you come across a system or language that handles units and their combinations / conversions well? I have a project I want to undertake but I feel like every time I start to deal with units in the way I feel is "proper" I end up starting to write a unit of measure library and give up.
When I learned Objective-C I remember being flabbergasted at all the method and argument names that were exceedingly wordy. At some point I read a blog post[0] that said while this is out of the ordinary when it comes to most code having long, descriptive names helps when reading code.
Some people complain that it involves too much typing or takes up too much space.
In reality, we spend much more time reading code than we do writing it, so names that provide context, direction, and fore-shadowing are really useful.
I still tend to write method names and important variable names like that to this day in pretty much any language I use. IMHO, its a great hack.
An extreme example is in the NSBitmapImageRep class [1]
Then, somebody asks me to code in the temperature of a system. And I have to think: "Is now really the time that I want to teach people the difference a kelvins and celsius?"
So my rule becomes, SI "except" temperature. Sigh...
SI doesn't prescribe that you have to use a single unit for all measurements. Are distance in meters or kilometers? Weights in kilograms or grams?
I assume you always just use the base units? kg, m, s, etc.? (I always think it odd that kilogram is the base.) I feel like could get weighty for some applications of a different scales when milligrams, millimeters, kilometers, days, etc. could be clearer. And even if you use "standard" units, if you aren't clear about what standard you use and what that makes that units, people won't always guess the correct option.
In thermodynamic calculations you likely need absolute (Kelvin) values. But in many calculations where only temperature difference is used, either unit works equally well.
How often are you doing the conversion manually? It seems like the sort of thing that should happen in the presentation layer so people never see the actual Kelvin amount. If you have a system where you always use SI then it's strange the have a single exception for temperature.
This is actually an issue with thermal imaging cameras. Typically you'll get calibrated readings back in Kelvin, not in Celsius. Usually it's well documented by the camera manufacturer, but if you're providing an API to users you need to make them aware what the units are and make a decision on what you're going to return. For example this crops up if the sensor only provides counts which you need to convert into a temperature.
From a hardware perspective it makes sense to use K because you can encode the image directly using unsigned numbers plus some gain to allow for fractional measurements.
which is great when you're writing from scratch, but as soon as you have to start calling a library with functions based in non-SI units then you've got some ambiguity.
This, one million times this. Use SI units. Don't measure distance in hotdogs, time in fortnights and speed in hotdogs per fortnight! It is as stupid as it sounds.
If you do, be explicit about it either in parameter or function name. I'm not going to put you on my shitlist if you're naming your function `microsleep`, but if I have to go look into implementation to see that you count timeout on your database in microseconds (looking at you, couchbase, like you ever could return something from a larger dataset in microseconds, lol) or, even worse, cache expiry time in minutes (hello unknown developer), I am going to go on the internet and complain about you.
There should be a exception in every code standard that says SI units are OK where otherwise all lower case is enforced. Example to use mega (M) vs milli (m).
I wrote about this a long time ago too: https://explog.in/notes/units.html. Units are critical, particularly when crossing language/engineer boundaries.
> Frink is a practical calculating tool and programming language designed to make physical calculations simple, to help ensure that answers come out right, and to make a tool that's really useful in the real world. It tracks units of measure (feet, meters, kilograms, watts, etc.) through all calculations..
I use Frink very regularly as a calculator. I've got a keybinding in emacs to bring it up in comint-mode, which works very well.
It's also a general-purpose programming language, at least in theory. I actually tried using it for that purpose once, with I think a few thousand lines of Frink code in total. It was not a pleasant experience. It's fine if you want to write a short script that's dimensionally aware, but for modelling of a complex physical system there are much better tools, such as Modelica.
A really great read. I found particularly interesting the long comment about the Hertz inconsistency, I had no idea the S.I. Hertz, when applied to circular motion, was not a full circle per second.
This is not exactly the same thing, but for the love of god, if you have a monitoring or logging product, make the date and time zone visible wherever time is displayed. I cannot tell you how many times I've been sent screenshots of graphs, showing some catastrophic scenario at, say, 08:43, with no idea of what time zone the graphs are using, or what day the graph is showing.
I prefer the use of Unix timestamps. Easier to filter with standard Unix tools, and if I really need formatted date+time in my output, I can always use awk.
I don like it, say I open a database table and search for some events , then look at the created_at column and see a timestamp, so now I need to copy paste timestamps into a webpage and convert it to human readable time to then notice is 5 years old and not what i am looking for.
What are you doing in this case?(in case you worked with database logs), export to csv and then do it with unix tools?
I used to prefer unix timestamps too. But I Saw The Light.
For one: those standard Unix tools can convert from date/time values to timestamps just as easy. Arguably easier.
And a timestamp is merely an Int, so many languages, databases, APIs and so on, lack ergonomic methods to convert timestamps to datetimes. But have easy ways to do the reverse. It's almost always easier to convert dates, times or datetimes to timestamp ints (or floats) than to convert an int or float to a date, datetime or time.
A timestamp.toString() is unfamiliar to humans, a datetime.toString() is not. The list of small benefits in favor of actual date or time types just goes on.
Internally yes, this is a no brainer. However in log files that are often read directly by humans, who want to see things in local time, it can become a balance and you might need to fight some admins for it. A proper structural logging system solves this, but log files on disk and other ad-hoc diy logs is still extremely common to see.
I have sometimes put my computer in the Iceland time zone for that reason when using dual boot with Linux, since Linux prefer to run UTC on the clock, and the Iceland time zone is UTC+0 with no daylight saving time. Making windows believe it is in Iceland make sure it does not mess up the clock. Though it is possible to set windows to UTC too with the same effect.
Especially in log files I want to see UTC. When you have servers all around the world, I do not want to figure out what timezone was the specific server running in nor I want to convert between timezones when comparing logs of different servers.
On-disk logs should use ISO-8601 in UTC, ideally first thing on the line.
That way you can merge them from different sources and sort them to help figure out interactions and causality. There might be clock drift from different sources but that's a much smaller problem than trying to eyeball multiple different logs concurrently, or write ad-hoc scripts to enable merging.
For pure servers, what you say is easy and yes, almost exclusively, the preferred option. The tricky situations usually occur in CI, where you script together a lot of weird tools, most of them originally designed to be run by hands on developers workstation, where they want to see local timestamps and never had time to implement log config. Some days you can consider yourself lucky if the log files have any timestamps at all.
If you can’t go that far and still need local time zones in some specific part, just embrace your fate and keep and display timezones everywhere, even when it’s UTC.
TBH, I’ve never seen an organization that could 100% move everything to UTC. Especially with countries following DST and other shenanigans, and you want to quickly be able to compare events at the same local time.
Absolutely. I support this 100%. But even if everything is in UTC, please, please make sure that it's clear that the time is UTC. That could mean an ISO 8601 timestamp with 'Z' or '+0' at the end, or a 'UTC' in the corner of your graph, or using unix timestamps.
Unless the whole world agrees to communicate times in UTC, at some point, you will share a screenshot or a log message with someone outside of your company, and they cannot assume what time zone it's in.
Yeah, this is also happens in code. The solutions are the same, either use a type that is unambiguous (`timestamptz` in Postgres, `datetime` in Python with `.tzinfo is not None`, `DateTimeOffset` in .NET, `UTCTime` in Haskell etc.), or if you have to use naive datetimes, put the time zone in the name and call it `datetime_utc`.
I remember as a kid, my Physics teacher used to penalize us for not writing the unit in the calculations. It seemed absurdly archaic at that time, but it makes so much sense now.
611 comments
[ 2.9 ms ] story [ 304 ms ] threadtime.sleep(300)
Put your units in the method name:
time.sleep_seconds(300)
Likewise, if you're making a .length() method where the units are at all ambiguous (like the length of a string), name your units. Bad: str.len(). Good: str.len_chars() / str.len_utf8_bytes(). (I'm looking at you, Rust!)
When programmers get answers to these questions wrong, the code that they write ends up being broken for someone out there. And they do get it wrong if their native culture instills a wrong kind of "common sense" about scripts. Which is precisely why we need more stuff like str.len_utf8_bytes() - because it forces the person writing it to consider their assumptions.
I’ve spent the last decade writing javascript and I’ve never once actually cared to know what half the UTF16 byte length of a string is.
The only legitimate uses are internal in javascript (since other parts of JS make that quantity meaningful). Like using it in slice() or iterating - though for the latter we now have Unicode string iteration anyway.
I don't know these, someone who does could properly tell you.
The implementation could fallback to "glyph" or "codepoint" (don't know what those are exactly) if it is unsure. Mostly right is better than nearly always wrong (= returning number of bytes) IMHO.
> How about "ß"?
That's one character.
> When programmers get answers to these questions wrong, the code that they write ends up being broken for someone out there.
So? Returning the number of bytes would also be wrong.
Renaming len to len_glyphs will just result in most programmers typing more and some accidentally using len_utf8_bytes (returns the number of bytes?) where len_glyphs would be less wrong.
The point the article is making is not about making it easier to write a line of code, but about making it easier to read a line of code. Given that most lines of code are read many more times than they are written, this is a good thing to focus on.
"Programs must be written for people to read, and only incidentally for machines to execute."
― Abel and Sussman, Structure and Interpretation of Computer Programs, 1984
Putting the units in the method name (when you can) fixes all of this. Sleep_milliseconds(5) is impossible to misuse or leave undocumented.
FWIW, in "TimeSpan for the .NET crowd", you would write "00:00:50" for (zero hours, zero minutes and) fifty seconds. Hours, minutes and seconds cases are easy now that we know the format.
Yes, you can omit some of the zeros, but your comment above makes the case that for clarity, you should not.
This is fine but relying on an IDE for code reviews really sucks. I'd much prefer to be able to do it on github. And it sucks for any language which infers types :( Scala is in particular awful for reviewing on github
I wish code review tool could provide this hover functionality too.
But the value of time.Second is actually a Duration with value 1000000, IIRC -- it's microseconds. It's just the type that's special, and the int handling here is general over a lot of types.
It really is nice in practice.
2 * 3 * time.Second is the same whether you group 2 * (3 * time.Second) or (2 * 3) * time.Second (namely, the implicit grouping under left-associativity).
You wouldn't normally write time.Sleep(time.Second * time.Second) because your units wouldn't work out. (Apparently you can write that in Golang; it's just very sketchy and results in a 30-year sleep.)
I'm just not seeing any major downsides of this, keep in mind `time.Second` isn't the only one of its kind, you have millisecond, minute, hour, etc etc.
There is a Duration::new() constructor that's more ambiguous, but it's your choice as a dev to be ambiguous in this instance, and code review should probably catch that.
Though it does seem pretty easy for a novice to do thinking it's the same, but what does 1.month.to_i even mean!?
Duration of a month in seconds? Before you balk at the idea, there exists a definition of a constant month duration for accounting stuff. I you hate dates - and yourself - try accounting, there's mind boggling stuff that makes the engineer mind recoil in absolute terror.
The expression on the left hand side advances time (as a domain object) by exactly a month, then converts the result to integer unix time. The expression on the right adds 2629746¹ to the current unix time.
The conversion becomes dangerously magical in the presence of shared code that accepts both object and integer representations of time & duration. A consumer from one part of a system can inadvertently obtain different results to another unless they use identical calling conventions.
[1] this is 1/12 of the mean length of a gregorian year²
[2] 365.2425 days i.e. 31,556,952 seconds
int64 * Duration → Duration and Duration * int64 → Duration both make sense, but I gather this only works with constants. For other values, I believe Go only gives you Duration * Duration → Duration which is just wrong, wrong, wrong, requiring that one of the two “durations” actually be treated as though unitless, despite being declared as nanoseconds.
In the end, it’s probably still worth it, but it’s a case of Go trying to design in a certain way for ergonomics despite lacking the type system required to do it properly. I have found this to be a very common theme in Go. Also that it’s often still worth it, for they’ve generally chosen their compromises quite well. But I personally don’t like Go very much.
In my opinion, it is well designed. First of all, who is multiplying time.Duration against itself? I've been programming Go for a few years basically every day, and I've only ever seen the package constants used by themselves, or with untyped constant. I think it's a great syntax, better than any example in the article, as you don't have mystery numbers.
Go is currently allowing that, which makes `delaySecs * time.Second` a billion times larger than it appears to intend. I've personally run across code that has this kind of flaw in it... at least several dozen times. It's the kind of thing that's only noticed when it misbehaves visibly while someone is watching it.
(I read a lot of other-teams' code, which is in various states of quality and disarray)
What you're suggesting would be like a compiler error for multiplying two int64s
Working with units is a common thing in science.
I would argue it is actually three things: a scalar, a unit, and an indication of error – which is at least another scalar, but there are multiple ways of expressing error, so it might require more than just a single scalar (such as an interval and the probability the actual value lies within that interval.)
> If the type system of your programming language does not allow you to define units, this should at least be a structure with a scalar and an enum
Ideally more than just an enum – Newton = kg*m*s^-2 (equivalently kg^1*m^1*s^-2) – which suggests a set of pairs (unit and exponent).
And it's especially true for time units.
For example, "how many seconds is one month?" does not make sense, but "how many seconds is january/february/march?" does make sense. The unit "month" does not really exist, each calendar month is its own unit.
And "february" is not even a "stable" unit because sometimes it's 28 days, sometimes it's 29 days. Even a minute can some rare times be 61 seconds.
This is why in physics, we use seconds multiplied by powers of 10 and nothing else.
To my knowledge, there is not a single programming language that differentiate a "scalar" and a "quantity" (scalar, unit, error).
The variables used for accepting and parsing input are the ones that should have units in them in this example. Although if you need a delay specified, it's valuable to be explicit and robust in the input and accept a string time.ParseDuration understands. Then you don't have this units problem in your variable naming at all, allows easier input of wider ranges of values by the operator, and makes input validation (if only a subset of durations are allowed) more concise and consistent.
Time was honestly our biggest source of bugs by far. Although adding time.Time ended up being more problematic than durations which were mostly only constructed like that in tests
C++ chrono::duration allows arithmetic operations with more sensible overloading. https://en.cppreference.com/w/cpp/chrono/duration
As for languages doing it better, approximately every single language that has strong static typing and uses dedicated types for times does it better. Rust is the one I’m most familiar with and comfortable with.
But Duration(1) is way different than time.Second. honestly it just sounds like you don't know the language, and aren't willing to learn it. Go is not Rust. Things are different, that doesn't mean Go sucks.
This is also pretty typical of the trade-offs Go makes: it focuses on making things nice for the application writer, mostly pretty successfully, but at the regular cost of pain and with serious typing compromises for the library writer.
F#, Rust, C++?..
> First of all, who is multiplying time.Duration against itself
Physicists do, every time they have to deal with acceleration - m/s^2.
Every implementation of units is secretly trying to be Moment.js, basically.
https://docs.microsoft.com/en-us/dotnet/fsharp/language-refe...
This can also be pulled off with somewhat less pleasant syntax on top of a sufficiently flexible parametrized type system - e.g. C++ templates.
In reality most programming languages do not have units what so ever (built into the language, maybe tacked on as a library after the fact). They have int64s, a unitless value that just keeps track of whole numbers of whatever it semantically means to the developer. If we want to truly have units in values then we either need 1st class language support (including syntactical support) or a rich library that doesnt just "put units in [symbols]". One could probably make it happen with a type that keeps track of units
and then filling out for all the other operations you want to support.I agree, though, that this is not quite sound, because it can be misused, as shown above with `time.Sleep(delaySecs * time.Second)`.
In Kotlin you can do `1.seconds + 1.minutes` but not `1.seconds * 1.minutes` (compilation error), which I quite like. Here is a playground link: https://pl.kotl.in/YZLu97AY8
I know how to implement that in Haskell, and that it can be implemented in C++ and Rust. I know how to logically implement that in Java or Typescript, but usability will suck (no infix operators).
For a good example of what it looks like when somebody does bother to do it, see F# units of measure.
Which is wrong, 1s * 1s = 1s².
For example, the force of gravity is expressed in m/s² and describe an acceleration (m/s / s, aka a change of velocity per time units, where velocity is a change of distance per time units).
But assuming your comment is not a joke. You probably want to convert minutes to seconds in order to work with the same units, then add the scalar parts together.
That's how you deal with different quantities: convert to same unit, add values.
This is analog to fractions: 1/2 + 1/4 = 2/4 + 1/4 = (2+1)/4 = 3/4.
EDIT: Yes, you multiply the units `2m * 2s` : you first multiply the units to get: `m.s`. This is what I say: you convert everything to the same units before doing the calculations.
> Multiplying by the same unit is semantically equivalent to “x times 1 is identity(x)”
This is wrong.
1kg * 1kg = 1kg² period.
What you're saying is `2kg * 1 = 2kg`, which is right, because `1` is a scalar while `2kg` is a quantity. This is completely different than multiplying 2 quantities.
> It would not imply I’m multiplying the units, but rather the scalar value of the unit.
That's where you're wrong. When doing arithmetic on quantities, you have 2 equations:
Or There is a meaning to units and the operation you do with them. `5m / 2s` is 5 meters in 2 seconds, which is the speed `2.5 m/s`.`2m + 1s` has no meaning, therefore you can't do anything with the scalar values, and the result remains `2m + 1s`, not `3 (m+s)`.
Units can be expressed in terms of other units, and you can arbitrarily pick one unit as a base and then express the rest in it. But the key word here is "arbitrarily".
If multiplying by the same unit yield the same unit, then how did you compute area or volume in school?
[1] would that be unitful?
You cannot have a unit on its own without a scalar value. It makes no sense.
- 1 is unitless
- 1 * m casts the value to a value 1 of unit m = 1m
- 1 * m * m casts the value 1 * m = 1m to 1m then casts 1m to m which = 1m
Admittedly my educational background here might be wildly unconventional but it certainly prepared me for interoperable unit types as a concept without changing values (~precision considerations).
And the syntax is `3<unit>` not `3 * unit`
- 1 is a scalar - 1m is a quantity - 2 * 1m "casts" 2 to a meter, but really this is just multiplying a quantity by a scalar - 2 * 1m * 1m "casts" 2 to meter², multiplying 2 quantities then by a scalar
I insist, `1 * m` does not make sense. This is not a valid mathematical expression, because a unit can never be on its own without a value.
> expression of a unit without a value is (or should be to my mind, based on my education) a cast
There is no casting in math. Mainly because there is no types, only objects with operations. A vector is not a scalar and you can't cast it into a scalar.
A quantity is not a scalar either, and you can't cast one into another.
A quantity is an object, you can multiply 2 quantities together, but you can't add them if they are different. You can multiply a quantity to a scalar, but you still can't add a scalar to a quantity.
Well, yeah, F# represents this at the type level. Which I’ve said elsewhere in the discussion is preferable. Not knowing Go, but knowing it only recently gained generics, I read multiplying by `time.Seconds` (which does not have a visible 1 associated with it) as perhaps performing an operator-overloaded type cast to a value/type with the Seconds unit assigned to it. I’ve since learned that Go also does not support operator overloading, so I now know that wouldn’t be the case. But had that been the case, it isn’t inconceivable that unitlessValue * valuelessUnit * valuelessUnit = unitlessValue * valuelessUnit. Because…
> I insist, `1 * m` does not make sense. This is not a valid mathematical expression, because a unit can never be on its own without a value.
Well, if you insist! But you seem to be imposing “mathematical expression” on an expression space where that’s already not the case? Whatever you may think of operator overloading, it is a thing that exists and it is a thing that “makes sense” to people using it idiomatically.
Even in languages without overloading, expressions which look like maths don’t necessarily have a corresponding mathematical representation. An equals infix operator in maths is a statement, establishing an immutable fact. Some languages like Erlang honor this, many (most? I strongly suspect most) don’t! I couldn’t guess without researching it also treat infix = statements as an expression which evaluated to a value.
The syntax of infix operators is generally inspired by mathematical notation, but it’s hardly beholden to that. The syntax of programming languages generally is not beholden to mathematical notation. Reacting as if it’s impossibly absurd that someone might read 1 * time.Seconds * time.Seconds as anything other than 1 * 1s * 1s is just snobbery.
Not knowing Go, I focused on the syntax and the explicit values, and tried to build a syntax tree on top of it. I’m not a fan of infix operators, and I am a fan of lisps, so my mental syntax model was (* (* 1 time.Seconds) time.Seconds)), which still doesn’t “make sense” mathematically, but it can make sense if `*` is a polymorphic function which accepts unquantified units.
This sums up your incomprehension. `time.Seconds` is just a constant. An integer with the value `1_000_000` meaning 1 million of nanoseconds.
In an expression of the form `a * b` you should always read `a` and `b` as constants. This is true for EVERY programming language.
> it isn’t inconceivable that unitlessValue * valuelessUnit * valuelessUnit = unitlessValue * valuelessUnit.
It is. For example, what would be the meaning of this:
Valueless unit (or any type) is just not a thing, not in math, not in any programming language.> But you seem to be imposing “mathematical expression” on an expression space where that’s already not the case? Whatever you may think of operator overloading, it is a thing that exists and it is a thing that “makes sense” to people using it idiomatically.
Operator overloading works on typed values, not "valueless" types. In some programming languages (like Python), class are values too, but why implement `a * MyClass` when you can write `MyClass(a)` which is 100% clearer on the intent?
Using operator overloading for types to implement casting is just black magic.
> expressions which look like maths don’t necessarily have a corresponding mathematical representation
Programming languages and the whole field of Computer Science is a branch of mathematics. They are not a natural language like english or german. They are an extension of maths.
> An equals infix operator in maths is a statement, establishing an immutable fact.
An operator only has meaning within the theory you use it.
For example:
As long as the theory defines the operators and the rules on how to use them, it does not matter which symbol you use. I can write a language where you have `<-` instead of `=`, and the mathematical rules (precedence, associativity, commutativity, ...) will be the same.> Reacting as if it’s impossibly absurd that someone might read 1 * time.Seconds * time.Seconds as anything other than 1 * 1s * 1s is just snobbery.
First, that's not what I said. You should read that as `scalar * constant * constant` because reading that as `scalar * unit * unit` does not make sense nor in math, nor in any programming language.
If caring about readability and consistency is snobbery, then so be it.
> Not knowing Go, I focused on the syntax and the explicit values, and tried to build a syntax tree on top of it.
And the syntax is pretty explicit, because it's the same as math or any programming language: `scalar * constant * constant`. This is why using math as a point of reference is useful, you can easily make sense of what you're reading, no matter the syntax.
> I am a fan of lisps, so my mental syntax model was (* (* 1 time.Seconds) time.Seconds))
I still read this as `(* (* scalar constant) constant))`. And I expect your compiler/interpreter to throw an error if `time.Seconds` is anything without a clear value to evaluate the expression properly.
And I would expect to read `(* (* 1 (seconds 1) (seconds 1)))` as `scalar * quantity * quantity`, and I would expect to get square seconds as an output.
Anything else would not be correct and have little to no use.
Let's say that you want to convert `2 min` into seconds. You know that `1 min = 60 s` is true. Dividing this equation by `1 min` on both sides is allowed and brings `1 = (60 s) / (1 min)`. This shows that if we multiply any value in minutes by `(60 s) / (1 min)`, we are not actually changing the value, because this is equivalent to multiplying it by 1. Therefore, `2 min = 2 min * 1 = 2 min * (60 s) / (1 min) = 2 * 60 s * (1 min) / (1 min) = 120 s`. We didn't change the value because we multiplied it by 1, and we didn't change its dimensionality ("type") because we multiplied it by a dimensionless number. We just moved around a dimensionless factor of 60, from the unit to the numerical value.
I think that you misremember, or didn't realize that to convert minutes into seconds, you were not multiplying by `60 s` but by `(60 s) / (1 min)` which is nothing else than 1.
https://pkg.go.dev/time#hdr-Monotonic_Clocks
> RRDNS is written in Go and uses Go’s time.Now() function to get the time. Unfortunately, this function does not guarantee monotonicity. Go currently doesn’t offer a monotonic time source (see issue 12914 for discussion).
https://blog.cloudflare.com/how-and-why-the-leap-second-affe...
> time: use monotonic clock to measure elapsed time
https://github.com/golang/go/issues/12914
1. https://developer.apple.com/documentation/dispatch/dispatcht...
Depending on your language, and how much type safety you want, you could use something Haskell's units library [3].
I believe F# also has units [4], possibly built in to the language? (I've never used F#.)
[1] https://en.wikipedia.org/wiki/ISO_8601#Durations
[2] https://docs.oracle.com/en/java/javase/11/docs/api/java.base...
[3] https://hackage.haskell.org/package/units
[4] https://docs.microsoft.com/en-us/dotnet/fsharp/language-refe...
Documentation should always be secondary to an obvious, descriptive interface. We've evolved beyond register positions and phonebook-style paper documentation. Use the tools available to you.
I also haven't come across a thorough implementation of unit conversions to do stuff like this (not that it's not a pattern that works -- I personally like this); it might be common in domains where dealing with real units is central to the business, but in industries where that's done incidentally, convenience classes like this just aren't around (in my experience).
[0]: https://i.imgur.com/8UcEO5N.png
It also doesn't make a unit error stick out, as you have to take the time to specifically hover to check. What I mean by this is consider you've opened a mature code base and are browsing around, and scroll past:
I'd assume this is milliseconds, and whether I check would depend on what I'm doing and probably also my mood.Whereas if I see:
It'll draw my attention and no matter what I'm doing I'll either open a bug or just fix it.- avoiding naming things if you can help it
- using tooling to autogenerate names
- avoiding too short, likely overloaded names like `id`, `name`, and `url`
- don't choose lazy pluralization - eg instead of `names/name`, use `nameList/nameItem`
- encoding types to make Wrong Code Look Wrong, a famous Spolsky opinion (lite hungarian notation)
- coming up with grammars for naming, eg React had an exercise to name its lifecycles combinations of THING-VERB-ACTION, like `componentDidMount`, before open sourcing, which helped learnability
pulled from my collection of Naming Opinions here: https://www.swyx.io/how-to-name-things
Isn't this just extra noise? If the type of the variable is an Array wouldn't `nameArray` be superfluous? Worse still is if the type changes but the name stays the same.
I get the advice is probably Javascript specific, but even in a Typescript world it doesn't make much sense to me to do this kind of type-in-name encoding.
But this has bitten me in Ruby, JavaScript and PHP several times. Runtime errors and downtime. Most recent: autocompled some updatedCartsItems when it had to be UpdatedCartItems. Both were used in the same class. Had they be named sensible, like CartListWithUpdatedItems and UpdatedItemList or something better, I'd have saved myself hours of WTFing through CI logs.
In a small enough context, no way :)
> don't choose lazy pluralization - eg instead of `names/name`, use `nameList/nameItem`
This just seems redundant and is a personal annoyance. Is plural meaning list or sequence not widely understood enough?
```
time.sleep(timedelta(minutes=5).total_seconds)
```
Or
```
time_to_sleep = timedelta(minutes=5) time.sleep(time_to_sleep.total_seconds())
```
For example...
...looks just as plausible. So what does this solve?I'm not saying time.sleep can't be improved but my method makes it easier to find any mistakes I've made in the future.
As a demonstration, reading your code makes it more obvious that you've passed the wrong unit into time.sleep.
Seems reasonable! :)
When I encounter these sorts of methods (which is surprisingly rare these days) I tend to double-check what units the method takes and additionally add a comment above my call saying "`sleep` takes duration in seconds", just to give future readers more ways to check whether I screwed up.
Having everything work this way makes it so much easier to review code for errors. Without this means that as a reviewer you must either trust that the units and conversions are correct or you should do some spelunking to make sure that the inputs and outputs are all in the right units.
The only people I've ever met that think this is unnecessary are also the same people that ship a lot of bugs for other people to fix.
We keep laughing about "if we engineered bridges as we engineer software" ... the truth is that the areas where correct software matters tend to write very robust code, and the rest of the industry would be well advised to take notice and copy what they see.
Of course, writing robust code is a skill, and it takes extra time.
I don't agree.
There is a good reason that aerospace industry writes robust code - in invests time (money) to avoid disasters that could cause, among other things, loss of human life.
On the other hand if for example some webform validation fails because the code was written as fast (as cheap) as possible, who cares really.
That is just a tradeoff, in aerospace industry you spend more to lower the risk, somewhere else you don't.
Who knows. Maybe a billion dollar company that can't fulfill orders. Maybe a million people who suddenly can't use their bank online.
You can probabbly find a some specific non-critical case in aerospace industry, but surely based on that example one would not suggest that the whole aerospace industry should just copy what they see in frontend dev.
Context matters, there are exceptions, but the standard practices are based on average scenario, not on extremes.
>> I don't agree.
>> [web form validation example]
>> That is just a tradeoff, in aerospace industry you spend more to lower the risk, somewhere else you don't.
> I'm just saying that "oh, it's just web stuff so it can't be important" is ridiculous.
This feels like a straw man.
The original argument is that the rest of the industry (that includes web, but a lot of other parts also) should copy what they see in aerospace industry.
I believe that would not be appropriate for the rest of the industry to just copy practices from any other part because each segment has its own risk factors and expected development costs and with that in mind developed their own standard practices. Nowhere did I state that the "web stuff can't be important" nor that there is no example of web development (form validation) where the errors are insignificant.
That said, I will go back to the "billion dollar company that can't fulfill orders" / "million people who suddenly can't use their bank online" catastrophe; this happens all the time. Billion dollar company doesn't fulfill orders, error is fixed, orders are fulfilled again, 0.0..01% of revenue is (maybe) lost.
In aerospace industry a bug is deployed, people are dead. No bugfixing will matter after that moment.
How can this two industries have the same standards of development?
I don't use libraries to enforce it though, we did try this but found it quite clunky: https://pint.readthedocs.io/en/stable/
One piece of equipment I just finished working on measured and displayed vacuum at different sensors in PSIg, kPa, Pa, mmHg, and inHg. The same machine, the same measurement at different stages in the process, five different units!
Even more fun is that sometimes units alone aren't sufficient. We need to know which coordinate system the units are being used in: screen, world, document, object-local, etc. It's amazing how many different coordinate systems you can come up with...
Or which time stream a timestamp comes from, input times, draw times (both of which are usually uptime values from CLOCK_MONOTONIC) or wall times.
I may be misunderstanding this.
You can't add seconds to kilometers, or to temperature, or to how blue something is.
The world is far, far from ideal.
As per the article, if you dont have proper names and just an 'int', that int can represent any scale of time...seconds, days, whatever.
In python youd need something like mypy, but in rust you could have the compiler ensure you are passing the right types.
You could perhaps newtype using a class (so you can instanceof) or tag via { unit: 'seconds', value: 30 } but that feels awful and seems to be against the ecosystem established practices.
This is indeed one of my gripes with TS typing. I'm spoiled by other languages, but I understand the design choice.
Originally, the type signature was
This naturally raises the question - number of what? Does "50" mean `50px`, `50vw`, `50em`, `50rem`, `50%`?I've ended up changing the component to only accept pixels and changed the argument to be a string like this:
Of course, if passing a "0" makes sense, you could also allow that. If you want to also accept, say, `50em`, you could use a union-type for that.I think this could actually work for other units as well. Instead of having `delay(200)`, you could instead have `delay("200ms")`, and have the "ms" validated by type system.
Maybe the future will see this getting more popular:
Because it's React, the expectation is "px", using a string with a suffix to override it: https://reactjs.org/docs/dom-elements.html#style
Eg
Meaning clear. Meaning obscure, error prone and potentially costlyEg. you could simply do
I am always amazed how new languages never pick up this most amazing feature of Python.Though obviously, this code smells anyway because 1. repetitive transfers are usually in calendar units (eg. monthly, weekly, yearly — not all of which can be represented with an exact number of days), so in Python you'd probably pass in a timedelta and thus a distinct type anyway, and 2. amounts are usually done in decimal notation to keep adequate precision and currency rounding rules (or simply `amount_in_cents`).
Still, I am in favour of higher order types (eg. "timedelta" from Python), and use of them should be equally obligatory for unit-based stuff (eg. volume, so following the traditional rule of doing conversions only at the edges — when reading input, and ultimately printing it out).
One problem with this approach is refactoring. If you wanted to refactor your example with the parameter "amount_in_dollars" then you would either have to continue maintaining the legacy "amount" argument, or break existing code.
Guess how I discovered this issue :)
In practice, with good naming it won't make much difference and only shows up when comparing the docs (or intellisense) for an API with how it is actually used.
dollars(10000) is still better than this example, because: 10000 what? Pennies? USD? EUR?
Now you can say how there are also AUD, CAD...
The point was simply that if units are needed due to lack of specific type being used, it's nicer to have that in the API when language allows it.
The units are also extremely clear when they are carried by the type instead of the variable name, where a developer could e.g. change some functionality and end up with a variable called `timeout_in_ms` while the function that eats this variable might expect seconds for some reason.
If it is typed out you can just check if the function performs the right action when passed a value of each time unit type and then you only ever have to worry about mistakingly declaring the wrong type somewhere.
But wether you should really do all that typing depends on how central units are for what you are doing. If you have one delay somewhere, who cares if it is typed or not. If you are building a CNC system where a unit conversion error could result in death and destruction, maybe it would be worth thinking about.
Instead of a type for seconds, you'd want a type for all kinds of duration regardless of the time unit, and with easy conversion to integers of a specific time unit. So your foo() function would be taking a Duration as an input rather than seconds, and work correctly no matter what unit you created that duration from:
The advantages are:
- An integer doesn't tell you if you are talking about seconds, milliseconds or anything like that. What does sleep(500) means? Sleep 500s or 500ms? sleep(500_ms) is explicit
- It provides an abstraction. The internal representation may be a 64-bit number of nanoseconds, or a 32-bit number of milliseconds, the code will be the same.
- Conversions can be done for you, no more "*24*60*60" littered around your code if you want to convert from seconds to days, do fun(1_day) instead.
- Safety, prevents adding seconds to meters for instance. Ideally, it should also handle dividing a distance by a duration and give you a speed and things like that.
Under the hood, it is all integers of course (or floats), which is all machine code, but handling units is one of the things a high level language can do to make life easier on the human writing the code.
I find feelings about this depend a lot on how much ceremony the type system involves; and just how many units and references to them there are in the system.
Asking bash coders to write "sleep 5s" instead of "sleep 5" - I doubt you'd get any objections at all.
But if you're putting a foo.bar.Duration on a getDefaultTimeoutFromEnvironment on a setConnectTimeout on a HttpRequest on a HttpRequestInitializer on a NetHttpTransport on a ProviderCredential to make a simple get request? People who've come from less ceremony-heavy languages might feel less productive, despite producing 10x the lines of code.
And yes I'm calling a class named HttpRequestInitializer silly, I don't care if some language decided it should exist.
My last shop was a Go shop and one test I think shows this off was an SMTP server and we needed to test the timeouts at different states. The test spun up half a dozen instances of the server, got each into the right smtp state and verified timeouts in under 10ms.
The environment that set the timeout would either be "timeout_ms=500" or "timeout=500ms" (or whatever). This is where you handle that :)
Of course if the setConnectTimeout method was part of the same application you could just pass the timeout directly, but at the boundary of your application you're still going to have to specify at some point which unit you want.
(although getDefaultTimeoutFromEnvironment was artistic license on my part)
Edit: Also, overriding a class method dynamically inside a function? I usually program python these days and even I think that's wild.
I actually don't know this particular API, but I'm used to timeouts being in milliseconds, so that code looks wrong to me.
Much better API, and what the article is talking about, is to change this to:
Now the mistake is obvious, and even if the original developer doesn't notice it will stick out in a PR or even a causal glance.Ideally this is consistent throughout the codebase, so that anything that uses a primitive type for time is explicitly labelled, and anything using a Duration can just be called "Timeout" or whatever.
Ideally it'd be as simple as:
typealias Dollars = BigDecimal
typealias Cents = Long
that's valid Kotlin, but the equivalent is doable in most languages nowadays (Java being a big exception).
I don't know Kotlin, but in most languages if you alias 2 types to the same base type, for example Seconds and Minutes to Long, the compiler will happily allow you to mix all 3 of them, defeating the protection full types would bring.
> typealias Cents = Long
If I ever have to deal with monetary values in a program where someone thought this was a good idea, ... well, it really won't be the worst thing I’ve ever dealt with, but, still.
(If you have dollars and cents as types in the same program, they darn well better work properly together, which is unlikely to work if they are both just aliases for basic numeric types.)
the classes shouldn't be for units at all, the type should represent the type of unit.
so instead of a class Seconds you should have a class Duration, instead of class Meters you should have a type Distance. that's because the unit of the different types can be converted between each other.
Dollars and Cents are a bit of a bad example because currencies can't be easily converted between each other, as conversion is dependent on many factors that change over time. meters, yards, feet, lightyears, miles, chain, furlongs, whatever describe a multiple of the same thing though, so a different type for each unit isn't necessary, as the input that was used to create the instance isn' usually needed. the counter example would be datetime with timezones - a datetime with a timezone convers a lot more information than the datetime converted to UTC.
https://package.elm-lang.org/packages/ianmackenzie/elm-units...
Even if you don’t work in Elm take a moment to look at it.
Had one making me pull my hair put the other day in C#. C# datetimed are measured in increments of 100 nanoseconds elapsed since January 1st 1 AD or something like that. Was trying to convert Unix time in milliseconds to a C# datetime and didn't realize they were using different units. My fault for not reading the docs but having it in the name would have saved me a lot of trouble.
The factory method used to convert e.g. Unix timestamps to DateTimes, now that should indicate whether we're talking seconds or milliseconds since epoch, for example, and when the epoch really was.
https://docs.microsoft.com/en-us/dotnet/api/system.datetimeo...
Much of the C# code I've seen uses names like start_date with no indication of whether it really is a date (with no timezone), a date (in one particular timezone), or a datetime where the time is significant.
I'm certainly not a C# developer, though my quick reading of the docs suggests that the DateOnly type was only introduced recently in .NET6.
[1]: https://nodatime.org/
It's really not any stranger than starting dates at 1 CE, or array indexes starting at 0.
Established doesn't mean it is understandable without documentation. Anyone who is not familiar with it doesn't know why it starts in 1970 and counts seconds. You need to actually open the documentation to know about that, and it's name (be it unix time, epoch, epoch time or whatever) doesn't help in understanding what it is and what unit it is using.
UNIX time is an easy international standard, everybody with computer experience knows what it is and how to work with it.
Thanks for the laugh.
The only ones who needs to know about unixtime is:
developers when they do something which takes it/produces it
*nix sysadmins
Everyone else with "computer experience" could live all their life without the need to know what unixtime is.
Bullshit.
I never needed to know what unixtime is when I wrote anything with sleep().
All I needed to know is how long in seconds I want the execution to pause for, never ever I needed to manually calculate something from/to unixtime, even when working with datetimes types.
Nobody is saying that the two things need to be connected, the point is that it can be name dropped in a type definition, and you would know what it means.
Windows uses the Gregorian Calendar as its epoch.
It is quite hard actually to disagree with the 100ns tick size that they did use. 1 microsecond may have also been reasonable as it would have provided a larger range but there are not many use cases for microsecond accurate times very far in the past or in the future. Similarly using 1 nanosecond may have increased the applicability to higher precision use cases but would have reduced the range to 100 years. Alternately, they could have used a 128 bit structure providing picosecond precision precision from big bang to solar system flame out with the resultant size/performance implications.
Many Languages
F# More info at https://fsharpforfunandprofit.com/posts/units-of-measure/Naming is an optimization problem: minimize identifier length while maximizing comprehension.
And you need to read the docs to know why some systems use 1970 as the reference point. Should we rename it to Unix1970datetimeepoch everywhere?
Yeah, you heard me Scala.
Why would your type system have encoded unit for kilo-pascal, but not hecto-pascal, mega-pascal, micro-pascal etc?
If you only encode base units (e.g. seconds), then we should use exact-precision arithmetic instead of f32 or f64, which is sometimes an overkill.
If encoding all the modulos (kilo/milli/mega etc) I feel like there are some units may have name clashes (e.g. "Gy" -- is it giga-years, or gray)?
Should we encode only SI units, or pounds/ounces/pints as well?
In my opinion this is not a real problem, since ideally no-one should such meaningless abbreviations in code. Just write giga_years or GigaYears or whatever your style is, problem solved, doesn't get any clearer than that.
"Stars are expected to form normally for 10^12 to 10^14 (1–100 trillion) years"
So it seems Gy and even Ty units will be a reasonable scale for events during the period of star formation.
https://en.wikipedia.org/wiki/Year#SI_prefix_multipliers
Once we get to Gigayears, what is the size of single year? Just 365 days? Or which of Julian, Gregorian, Tropical, Sidereal? At even kilo prefix the differences do add up. Or would you need to specify it?
Days, weeks and months are also fun mess to think of.
(Calculations without associated uncertainty calculations are worse than worthless anyway - misleading due to the inherent trust we tend to put in numbers regardless of whether they are garbage.)
The appropriate system of units is context-dependent. The astronomical system, for instance, has Days of 86,400 SI seconds and Julian years of exactly 365.25 Days; if you have a general and extensible units library, then this isn't really a difficulty, you just need to make a choice based on requirements.
Does the type system do orientational analysis? If not you to assign a value of work to a value of torque and vice versa, as they both have the above unit.
There are several other similar gotchas with the SI. I think descriptive names are better than everyone attempting to implement an incomplete/broken type system.
0. https://docs.astropy.org/en/stable/units/index.html
The SI itself states[2]: "...For example, the quantity torque is the cross product of a position vector and a force vector. The SI unit is newton metre. Even though torque has the same dimension as energy (SI unit joule), the joule is never used for expressing torque."
[1]:https://docs.astropy.org/en/stable/units/index.html#module-a... [2]:https://www.bipm.org/documents/20126/41483022/SI-Brochure-9-...
Note the last 4.0, while min value is 1.0
The issue is that a, b, c, d are objects when astropy units are applied and min (or max) returns not the value but an object with the minimal value, thus m is c (in this particular case c has the smallest value) so c -= m makes m = 0, so d remains unchanged. It was very hard to spot especially when values change and occasionally either one of a, b, c or d has the smallest value.
In-place augmentation of a working code with units may be very tricky and can create unexpected bugs.
While it can sometimes be undefined behavior (a minimum of incompatible units), in cases like these it should DTRT.
You'd get the exact same behavior with numpy ndarrays (of which astropy Quantities are a subclass).
Unit-aware values as a type where assignment as mutation is an odd choice though (normal mutable types do not exhibit this behavior, it’s a whole separate behavior which has to be deliberately implemented.) It may make sense in the expected use case (and as you note reflects the behavior of the underlying type), but more generally it's not what someone wanting unit-aware values would probably expect.
https://www.boost.org/doc/libs/1_78_0/doc/html/boost_units/F...
tl;dr is uses some sort of pseudounits to make dimensionally similar but incompatible units, well, incompatible.
(Economics of floating vs fixed point chips might distort things though ?)
Also, in the case that you meant this : you might need fractions of even base units for internal calculations :
IIRC banking, which doesn't accept any level of uncertainty, and so uses exclusively fixed precision, uses tens of cents rather than cents as a base unit ?
https://pint.readthedocs.io/en/stable/
It can convert between equivalent units (e.g., centimeters and kilometers), and will complain if you try to add quantities that aren't commensurate (e.g., grams and seconds).
The nice thing about this is that you can write functions that expect unit-ful quantities, and all the conversions will be done automatically for you. And if someone passes an incorrect unit, the system will automatically spit out an error.
0. https://docs.astropy.org/en/stable/units/index.html
But types are not just useful to specify the content of a variable, they are also useful to specify the required precision.
So, if there is a type for seconds in the type system, should it be a 32 bits int or a 64 bits float? Only the user can say.
type DurationSeconds<Value> where Value: Numeric { ... }
DurationSeconds<UInt32>
DurationSeconds<Float64>
[0] https://en.cppreference.com/w/cpp/chrono/duration
Have none of you ever refactored code..? Or all of your writing C?
Your library should just expose an interface/protocol signature. Program to interfaces. Anything that is passed in should just implement the protocol. The sleep function should not be aware or care about the input type AT ALL. All it requires is the input to implement an "as-milliseconds()" function that returns a millisecond value. You can then change any internal representation as your requirements change
You seem to ignore the much broader context here: the article wasn't just about code. It included configuration files and HTTP requests.
It's also worth noting that depending on the language in question and the usage pattern of the function/method, using interfaces or protocols can cause considerable overhead when simply using a proper descriptive name is free.
That's an argument against languages with type-systems that make this a PITA, not against the idea itself.
A.k.a. custom type!
If you replace 'time delta' with 'strings' then the problem becomes more apparent. Each library defining its own string type would be a mess.
> This will explode very quickly into lots of boilerplate code and is a good reason to use 'primitive types' in interfaces.
I feel you were so close and missed :) The natural conclusion would be to have primitive interfaces - not primitive types. This way libraries only need to agree to adhere to an interface (and not an implementation)
I think the practical problem stems from widespread APIs which are not communicating their units, and that's what we should be fixing instead: if APIs are clearer (and also self-documenting more), the risks you talk of rarely exist other than in badly structured code.
Basically, instead of having `sleep(wait_in_seconds)` one should have `sleep_for_seconds(wait_time)` or even `sleep(duration_in_seconds=wait_time)` if your language allows that.
But certainly use of proper semantic types would be a net win, but they usually lose out in the convenience of typing them out (and sometimes constructing them if they don't already exist in your language).
(I settled on units in variable names instead, was essential when some inputs were literally in different units of the same physical dimension.)
EDIT : more on this, and on astropy (which I was not aware of and/or didn't exist back then) :
https://github.com/astropy/astropy/issues/7438
PIXELS_PER_INCH or BITS_PER_LITER rather than SCREEN_SCALE_FACTOR and VOLUME_RESOLUTION, avoids all kinds of mistakes like inverting ratios etc.
Some people complain that it involves too much typing or takes up too much space. In reality, we spend much more time reading code than we do writing it, so names that provide context, direction, and fore-shadowing are really useful.
I still tend to write method names and important variable names like that to this day in pretty much any language I use. IMHO, its a great hack.
An extreme example is in the NSBitmapImageRep class [1]
[0]: https://www.cocoawithlove.com/2009/06/method-names-in-object...
[1]: https://developer.apple.com/documentation/appkit/nsbitmapima...
Then, somebody asks me to code in the temperature of a system. And I have to think: "Is now really the time that I want to teach people the difference a kelvins and celsius?"
So my rule becomes, SI "except" temperature. Sigh...
I assume you always just use the base units? kg, m, s, etc.? (I always think it odd that kilogram is the base.) I feel like could get weighty for some applications of a different scales when milligrams, millimeters, kilometers, days, etc. could be clearer. And even if you use "standard" units, if you aren't clear about what standard you use and what that makes that units, people won't always guess the correct option.
The other issue is when you get to Candelas!
Not blaming anyone who does not know it, but I would argue for more and better science education ..
Haven't come across temperature however we would probably stick with kelvin.
We use a strict set of units in databases and while processing, conversions are localized if necessary only at the view layer.
We also only use UTC for date/times.
We only use E164 format (without spaces etc) for phone numbers: e.g. +12345678901 for an example number in OH, US. see National format https://libphonenumber.appspot.com/phonenumberparser?number=...
We only use iso3166-1 country codes and iso3166-2 region codes and translate on view.
From a hardware perspective it makes sense to use K because you can encode the image directly using unsigned numbers plus some gain to allow for fractional measurements.
If you do, be explicit about it either in parameter or function name. I'm not going to put you on my shitlist if you're naming your function `microsleep`, but if I have to go look into implementation to see that you count timeout on your database in microseconds (looking at you, couchbase, like you ever could return something from a larger dataset in microseconds, lol) or, even worse, cache expiry time in minutes (hello unknown developer), I am going to go on the internet and complain about you.
> Frink is a practical calculating tool and programming language designed to make physical calculations simple, to help ensure that answers come out right, and to make a tool that's really useful in the real world. It tracks units of measure (feet, meters, kilograms, watts, etc.) through all calculations..
https://frinklang.org/
I use Frink very regularly as a calculator. I've got a keybinding in emacs to bring it up in comint-mode, which works very well.
It's also a general-purpose programming language, at least in theory. I actually tried using it for that purpose once, with I think a few thousand lines of Frink code in total. It was not a pleasant experience. It's fine if you want to write a short script that's dimensionally aware, but for modelling of a complex physical system there are much better tools, such as Modelica.
What are you doing in this case?(in case you worked with database logs), export to csv and then do it with unix tools?
For one: those standard Unix tools can convert from date/time values to timestamps just as easy. Arguably easier.
And a timestamp is merely an Int, so many languages, databases, APIs and so on, lack ergonomic methods to convert timestamps to datetimes. But have easy ways to do the reverse. It's almost always easier to convert dates, times or datetimes to timestamp ints (or floats) than to convert an int or float to a date, datetime or time.
A timestamp.toString() is unfamiliar to humans, a datetime.toString() is not. The list of small benefits in favor of actual date or time types just goes on.
That way you can merge them from different sources and sort them to help figure out interactions and causality. There might be clock drift from different sources but that's a much smaller problem than trying to eyeball multiple different logs concurrently, or write ad-hoc scripts to enable merging.
When people try to apply this to other time related info, it's always a disaster.
If you can’t go that far and still need local time zones in some specific part, just embrace your fate and keep and display timezones everywhere, even when it’s UTC.
TBH, I’ve never seen an organization that could 100% move everything to UTC. Especially with countries following DST and other shenanigans, and you want to quickly be able to compare events at the same local time.
If you're going to do it in storage, keep it outside the ISO/8601 string. Chronology is the most important thing to get right. Locality comes after
Unless the whole world agrees to communicate times in UTC, at some point, you will share a screenshot or a log message with someone outside of your company, and they cannot assume what time zone it's in.
* https://docs.oracle.com/javase/8/docs/api/java/time/Duration... * https://docs.microsoft.com/en-us/dotnet/api/system.timespan?... * https://en.cppreference.com/w/cpp/chrono/duration
If you're putting something in a config file, as the blog says - always put the unit in the key name.