4 ms·

I really support this kind of writing, I don't think this kind of stuff is written about enough, and it's exactly what everyone learns the hard way working on s

I really support this kind of writing, I don't think this kind of stuff is written about enough, and it's exactly what everyone learns the hard way working on software projects. Skill wise, knowing the kinds of reasoning/techniques that articles like these discuss is the difference between "junior" and "senior" developers (though I very much dislike those terms). One thing I want to point out -- if at all possible do not use decimals for money: > We could use decimal (and we will, but no directly), but decimal is less descriptive. Besides, it can be used for representation of other things than money, and we don't want it to be mixed up. So we use custom type type [<Struct>] Money = Money of decimal . The custom type is a great idea (try to write code in languages that make this concept easy, I suggest Haskell & type/newtype). The problem here is that decimal is the wrong type for storing money[0]. Your first IEEE754 floating point bug teaches you this, but in general trying to write code around manipulating decimals can get very messy really quickly when precision is involved in any case. Another example is JSON, JSON numerics are actually all floats under the covers, so this means if you store more precision or a bigger number than it can handle, things can get wacky if you're not careful -- this is one of the places where being "stringly typed" (and defining your own unpacking to go with your domain types) can be very helpful. Libraries like dinero.js[1] exist because of how surprisingly hard this problem is, kind of like how moment[2] exists due to how hard dealing with time can be. [0]: https://stackoverflow.com/questions/3730019/why-not-use-double-or-float-to-represent-currency https://stackoverflow.com/questions/3730019/why-not-use-doub... [1]: https://github.com/sarahdayan/dinero.js https://github.com/sarahdayan/dinero.js [2]: https://momentjs.com https://momentjs.com

jorams 7y ago
> The problem here is that decimal is the wrong type for storing money Note that the code here is .NET, where decimal is a type explicitly for use in financial calculations[0]. It is still floating point, which means you still need to really watch what you are doing, but it's very high precision. In general though, if your application allows for it, you should store money using integers representing cents (or the relevant smallest unit for the currency). [0]: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/decimal https://docs.microsoft.com/en-us/dotnet/csharp/language-refe... (this is a page for C#, but it is more useful than the general page for Decimal)
- couchand 7y ago
  > It is still floating point, which means you still need to really watch what you are doing, but it's very high precision. The key difference between a decimal type (in any language) (regardless whether it's fixed-point or floating-point) is that it's not BINARY floating point. Yes, you need to watch what you are doing (shouldn't you always?)... but you can limit analysis to the appropriate precision, without worrying about binary conversion artifacts like 0.3 isn't 0.3. > In general though, if your application allows for it, you should store money using integers representing cents. What you're describing is a poor man's fixed point. Much better to just use a fixed point decimal type so you don't need to remember to apply the scale factor everywhere. In any case, you can't get around the need to determine a ceiling in your necessary precision.
marcc 7y ago
Agreed. I dislike the terms "sr" and "jr" developer, but I think we too often call someone a senior because they know a lot of technology or they've been around for a while. I've been thinking a lot about these terms and have been defining these roles internally as: junior: can build relatively simple solutions, still gaining experience. mid-level: can build complex systems, but the solution is going to be complicated. senior: builds simple solutions to solve complicated problems. I mentor internal devs to help shift their focus from learning more complicated technologies toward learning how to produce much cleaner and simpler solutions. This is the career path that I think helps them the most and also helps our company scale.

jorams 7y ago

> The problem here is that decimal is the wrong type for storing money Note that the code here is .NET, where decimal is a type explicitly for use in financial calculations[0]. It is still floating point, which means you still need to really watch what you are doing, but it's very high precision. In general though, if your application allows for it, you should store money using integers representing cents (or the relevant smallest unit for the currency). [0]: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/decimal https://docs.microsoft.com/en-us/dotnet/csharp/language-refe... (this is a page for C#, but it is more useful than the general page for Decimal)

couchand 7y ago
> It is still floating point, which means you still need to really watch what you are doing, but it's very high precision. The key difference between a decimal type (in any language) (regardless whether it's fixed-point or floating-point) is that it's not BINARY floating point. Yes, you need to watch what you are doing (shouldn't you always?)... but you can limit analysis to the appropriate precision, without worrying about binary conversion artifacts like 0.3 isn't 0.3. > In general though, if your application allows for it, you should store money using integers representing cents. What you're describing is a poor man's fixed point. Much better to just use a fixed point decimal type so you don't need to remember to apply the scale factor everywhere. In any case, you can't get around the need to determine a ceiling in your necessary precision.

marcc 7y ago

Agreed. I dislike the terms "sr" and "jr" developer, but I think we too often call someone a senior because they know a lot of technology or they've been around for a while. I've been thinking a lot about these terms and have been defining these roles internally as: junior: can build relatively simple solutions, still gaining experience. mid-level: can build complex systems, but the solution is going to be complicated. senior: builds simple solutions to solve complicated problems. I mentor internal devs to help shift their focus from learning more complicated technologies toward learning how to produce much cleaner and simpler solutions. This is the career path that I think helps them the most and also helps our company scale.