Re:Ask HN: How to avoid over-engineering software design for...
by smabie on Wednesday June 24, 2020 @02:40AM
(#23624797)
Conventional type systems don't really help you when your code is pretty much just taking in vectors/matrices of floats and returning vectors/matrices of floats.
[ Parent
| on HN ]
Re:Ask HN: How to avoid over-engineering software design for...
by MaxBarraclough on Wednesday June 24, 2020 @04:56AM
(#23625729)
You still have the option of introducing new types, even there.
In Ada, the programmer is discouraged from using the Ada equivalent of int directly, and is encouraged to instead introduce a subtype that reflects the specific use of int (including automatic range checking).
This isn't as natural in C++ but is still possible. Boost offers a BOOST_STRONG_TYPEDEF [0] to deliberately introduce an incompatible type. (I do recall having trouble getting it to behave, but it's been a while.)
Whether this makes sense in most mathematical code, I'm not sure, but it seems like it's an option.
[0] https://www.boost.org/doc/libs/1_73_0/boost/serialization/st...
Re:Ask HN: How to avoid over-engineering software design for...
by jeffreygoesto on Wednesday June 24, 2020 @07:25AM
(#23626628)
If you are working with physicial quantities in C++ there are also
Re:Ask HN: How to avoid over-engineering software design for...
by antris on Wednesday June 24, 2020 @02:42AM
(#23624808)
You are correct, however that's a niche use case that would warrant using a non-conventional type system. Conventional type systems are mostly for just dumping a bunch of strings and integers to and from a database and formatting them neatly.