4 ms·

I am curious about people's experience with this kind of system, I have been thinking about it for years, but never actually tried it. I sometimes feel like fi

I am curious about people's experience with this kind of system, I have been thinking about it for years, but never actually tried it. I sometimes feel like finding the explicit unit of some sub-expressions in geometry might be complicated. I know "auto" avoids that particular problem, but I don't have a good policy for when to put "auto" to avoid expressing a complex type and when to explicit the type to block the propagation of errors. Also during debugging we might need to display some customary unit for sub expressions/watchpoints because the SI unit means nothing to humans in some fields (pressure comes to mind, some people use mm of water, mm of mercury, bars, etc.)

nicklecompte 3y ago
It is built in to F# and I think it's a very underrated feature of the language for certain applications, although it comes with some overhead and tedium. There is a cost. I used F# for financial analysis in the power industry, where there is just an atrocious lack of unit standardization leading to tons of subtle bugs. It's not just stuff about volts and kilowatt hours: I have nightmares about a function that wanted on-peak hourly averages but the caller gave it overall hourly averages - or did it??? By itself, the debugger does not really help you figure out what's going on here unless you are eagle-eyed about time zones. But the compiler can complain if you gave it an `float<price/hour> array` instead of `float<peakPrice/hour> array`, which makes the source of the bug much more transparent, or prevents the bug from occurring at all. Implementing certain computations in F# instead of C# saved me a lot of time and headaches, while also making the code more descriptive to humans. And of course the compiler also verifies things like kilowatts versus megawatts, etc. It's a specific use case: many intricate floating-point computations with highly sophisticated business logic, where common bugs can be avoided by simple labelling of the units. It is all static, so there isn't boxing or performance penalty, but it does have syntactical overhead. And of course the compiler doesn't know physics - you can invalidly coerce things by arbitrarily multiplying with `1<newUnit/oldUnit>.` What you're saying about some subexpressions is true, but the units will only ever be in simple algebraic combinations so you won't get any truly confounding `decltype` head-scratchers. It might be tedious but it'll never be particularly deep. In practice, yes, it gets annoying. But in many cases I found the annoyance was a helpful check on my thinking - "somehow I got dollars^2/week, that doesn't make sense, what did I do?" Instead of `auto`, if the units are getting too tedious I think it's better to cast down to floats/etc and do things the old fashioned way, with helpful documentation, then cast to a unit further up the call stack, where things may be more transparent. You can see how it works in F# here: https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/units-of-measure https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref... They are smaller examples, so it is hard to judge the safety-overhead from this alone. But I think they have a nice syntax, and clever ways to use generics. > Also during debugging we might need to display some customary unit for sub expressions/watchpoints because the SI unit means nothing to humans in some fields (pressure comes to mind, some people use mm of water, mm of mercury, bars, etc.) It seems like this would be in principle easy to add to a debugger, as long as all those units are in scope of the function. But it would be a very specific feature. And I am not sure if it's a good idea for software engineers to be debugging things in different units than the computer is currently working with - what if the bug is in the unit conversion itself? This just seems like a confusing practice.
- nraynaud 3y ago
  Thank you, having a look at F#, I didn't know about its unit system. As for the last point, it comes to mind because of electronics/mechanics engineering where the teachers always tell you to look if the numbers make sense in the context or that you should know the rough answer to a computation before hand, that is folklore that can only happen in customary units.

nicklecompte 3y ago

It is built in to F# and I think it's a very underrated feature of the language for certain applications, although it comes with some overhead and tedium. There is a cost. I used F# for financial analysis in the power industry, where there is just an atrocious lack of unit standardization leading to tons of subtle bugs. It's not just stuff about volts and kilowatt hours: I have nightmares about a function that wanted on-peak hourly averages but the caller gave it overall hourly averages - or did it??? By itself, the debugger does not really help you figure out what's going on here unless you are eagle-eyed about time zones. But the compiler can complain if you gave it an `float<price/hour> array` instead of `float<peakPrice/hour> array`, which makes the source of the bug much more transparent, or prevents the bug from occurring at all. Implementing certain computations in F# instead of C# saved me a lot of time and headaches, while also making the code more descriptive to humans. And of course the compiler also verifies things like kilowatts versus megawatts, etc. It's a specific use case: many intricate floating-point computations with highly sophisticated business logic, where common bugs can be avoided by simple labelling of the units. It is all static, so there isn't boxing or performance penalty, but it does have syntactical overhead. And of course the compiler doesn't know physics - you can invalidly coerce things by arbitrarily multiplying with `1<newUnit/oldUnit>.` What you're saying about some subexpressions is true, but the units will only ever be in simple algebraic combinations so you won't get any truly confounding `decltype` head-scratchers. It might be tedious but it'll never be particularly deep. In practice, yes, it gets annoying. But in many cases I found the annoyance was a helpful check on my thinking - "somehow I got dollars^2/week, that doesn't make sense, what did I do?" Instead of `auto`, if the units are getting too tedious I think it's better to cast down to floats/etc and do things the old fashioned way, with helpful documentation, then cast to a unit further up the call stack, where things may be more transparent. You can see how it works in F# here: https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/units-of-measure https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref... They are smaller examples, so it is hard to judge the safety-overhead from this alone. But I think they have a nice syntax, and clever ways to use generics. > Also during debugging we might need to display some customary unit for sub expressions/watchpoints because the SI unit means nothing to humans in some fields (pressure comes to mind, some people use mm of water, mm of mercury, bars, etc.) It seems like this would be in principle easy to add to a debugger, as long as all those units are in scope of the function. But it would be a very specific feature. And I am not sure if it's a good idea for software engineers to be debugging things in different units than the computer is currently working with - what if the bug is in the unit conversion itself? This just seems like a confusing practice.

nraynaud 3y ago
Thank you, having a look at F#, I didn't know about its unit system. As for the last point, it comes to mind because of electronics/mechanics engineering where the teachers always tell you to look if the numbers make sense in the context or that you should know the rough answer to a computation before hand, that is folklore that can only happen in customary units.