4 ms·

That’s not automatically bad. There are two kinds of Hungarian notation: systems Hungarian, which duplicates information that the type system should be tracking

That’s not automatically bad. There are two kinds of Hungarian notation: systems Hungarian, which duplicates information that the type system should be tracking; and apps Hungarian, which encodes information you’d express in types if your language’s type system were expressive enough. [1] goes into the difference. [1] https://www.joelonsoftware.com/2005/05/11/making-wrong-code-look-wrong/ https://www.joelonsoftware.com/2005/05/11/making-wrong-code-...

yencabulator 2y ago
And this is exactly the kind the language should have a type for, Duration.
- crazygringo 2y ago
  Not really. I don't want to have a type for an integer in seconds, a type for an integer in minutes, a type for an integer in days, and so forth. Just like I don't want to have a type for a float that means width, and another type for a float that means height. Putting the unit (as oppose to the data type) in the variable name is helpful, and is not the same as types. For really complicated stuff like dates, sure make a type or a class. But for basic dimensional values, that's going way overboard.
  - yencabulator 2y ago
    > I don't want to have a type for an integer in seconds, a type for an integer in minutes, a type for an integer in days, and so forth. This is not how a typical Duration type works. https://pkg.go.dev/time#Duration https://pkg.go.dev/time#Duration https://doc.rust-lang.org/nightly/core/time/struct.Duration.html https://doc.rust-lang.org/nightly/core/time/struct.Duration.... https://docs.rs/jiff/latest/jiff/struct.SignedDuration.html https://docs.rs/jiff/latest/jiff/struct.SignedDuration.html
    - crazygringo 2y ago
      I'm just saying, this form of "Hungarian" variable names is useful, to always include the unit. Not everything should be a type. If all you're doing is calculating the difference between two calls to time(), it can be much more straightforward to call something "elapsed_s" or "elapsed_ms" instead of going to all the trouble of a Duration type.
  - thaumasiotes 2y ago
    > I don't want to have a type for an integer in seconds, a type for an integer in minutes, a type for an integer in days, and so forth. > For really complicated stuff like dates, sure make a type or a class. Pick one. How are you separating days from dates? Not all days have the same number of seconds.
  - ghusbands 2y ago
    You're missing the value of these things in identifying bugs. When you subtract a number of seconds from a temperature, you'll be glad for the compile-time error. There also doesn't have to be a runtime cost, as in C++ (and languages supporting value type instances) they can either be type-erased or cost no more than an integer.

yencabulator 2y ago

And this is exactly the kind the language should have a type for, Duration.

crazygringo 2y ago
Not really. I don't want to have a type for an integer in seconds, a type for an integer in minutes, a type for an integer in days, and so forth. Just like I don't want to have a type for a float that means width, and another type for a float that means height. Putting the unit (as oppose to the data type) in the variable name is helpful, and is not the same as types. For really complicated stuff like dates, sure make a type or a class. But for basic dimensional values, that's going way overboard.
- yencabulator 2y ago
  > I don't want to have a type for an integer in seconds, a type for an integer in minutes, a type for an integer in days, and so forth. This is not how a typical Duration type works. https://pkg.go.dev/time#Duration https://pkg.go.dev/time#Duration https://doc.rust-lang.org/nightly/core/time/struct.Duration.html https://doc.rust-lang.org/nightly/core/time/struct.Duration.... https://docs.rs/jiff/latest/jiff/struct.SignedDuration.html https://docs.rs/jiff/latest/jiff/struct.SignedDuration.html
  - crazygringo 2y ago
    I'm just saying, this form of "Hungarian" variable names is useful, to always include the unit. Not everything should be a type. If all you're doing is calculating the difference between two calls to time(), it can be much more straightforward to call something "elapsed_s" or "elapsed_ms" instead of going to all the trouble of a Duration type.
- thaumasiotes 2y ago
  > I don't want to have a type for an integer in seconds, a type for an integer in minutes, a type for an integer in days, and so forth. > For really complicated stuff like dates, sure make a type or a class. Pick one. How are you separating days from dates? Not all days have the same number of seconds.
- ghusbands 2y ago
  You're missing the value of these things in identifying bugs. When you subtract a number of seconds from a temperature, you'll be glad for the compile-time error. There also doesn't have to be a runtime cost, as in C++ (and languages supporting value type instances) they can either be type-erased or cost no more than an integer.