4 ms·

I think a standard library is not negative, but rather acts as a multiplier for decisions. The C++ std::unordered_map designers made a bad decision (requiring b

by durumu 3y ago

I think a standard library is not negative, but rather acts as a multiplier for decisions. The C++ std::unordered_map designers made a bad decision (requiring buckets to be iterable) and now, like you say, it's hard to get people to use the superior absl::flat_hash_map. But if the standard library designers make a good decision -- for instance, Python's extremely well-designed dict that is fast, insertion-ordered, and forms the basis of nearly every object -- then everyone gets to reap the benefits without the cognitive overhead of figuring out what the best hash map is.

tialaramex 3y ago
Python's current dict is reasonable by Python's standards (it's slow but not ludicrously slow, it's big but not ludicrously big and insertion ordering, though non-free, is not a great extravagance and is convenient for newbie programmers) but it wasn't so very long ago that their dict was bigger, slower and didn't preserve order. Even early Python 3's dict was like that. There's a benefit for vocabulary types, which Python's dict clearly is. I think you could make the argument for C++ std::unordered_map if it wasn't awful and I would make that argument for std::vector even though it's not the best possible design it's fine and it's vocabulary. And don't get me wrong, the opposite is a problem too. Python's dict isn't from their standard library it's a core language feature. Python doesn't formally have a freestanding mode so that doesn't make much a huge difference but e.g. the syntax for dict is not something a third party library could do. C++ here chooses to go out of its way not to put important stuff in the core language, so e.g. the built-in array type in C++ is garbage, it's the array from C. You can have a vaguely reasonable array type, std::array but it's from their stdlib and so can't change language syntax. Likewise tuples, the C++ rather unconvincing attempt at sum types (std::variant) and so on. The result is that C++ falls into the Turing Tarpit where everything is possible but nothing interesting is easy, which is maybe one harder way to play Advent of Code without needing an esolang that's designed to be awful but doesn't make a lot of sense for engineering. It's too late for WG21, but don't do this at home.

by durumu 3y ago

tialaramex 3y ago

Python's current dict is reasonable by Python's standards (it's slow but not ludicrously slow, it's big but not ludicrously big and insertion ordering, though non-free, is not a great extravagance and is convenient for newbie programmers) but it wasn't so very long ago that their dict was bigger, slower and didn't preserve order. Even early Python 3's dict was like that. There's a benefit for vocabulary types, which Python's dict clearly is. I think you could make the argument for C++ std::unordered_map if it wasn't awful and I would make that argument for std::vector even though it's not the best possible design it's fine and it's vocabulary. And don't get me wrong, the opposite is a problem too. Python's dict isn't from their standard library it's a core language feature. Python doesn't formally have a freestanding mode so that doesn't make much a huge difference but e.g. the syntax for dict is not something a third party library could do. C++ here chooses to go out of its way not to put important stuff in the core language, so e.g. the built-in array type in C++ is garbage, it's the array from C. You can have a vaguely reasonable array type, std::array but it's from their stdlib and so can't change language syntax. Likewise tuples, the C++ rather unconvincing attempt at sum types (std::variant) and so on. The result is that C++ falls into the Turing Tarpit where everything is possible but nothing interesting is easy, which is maybe one harder way to play Advent of Code without needing an esolang that's designed to be awful but doesn't make a lot of sense for engineering. It's too late for WG21, but don't do this at home.