4 ms·

C++ has std::sort() and std::stable_sort(). You should write what you mean, and you should know and understand your tools. Blaming the tool for your ignorance m

by bregma 4mo ago

C++ has std::sort() and std::stable_sort(). You should write what you mean, and you should know and understand your tools. Blaming the tool for your ignorance marks you as significantly less than an artisan.

tialaramex 4mo ago
Sure, both languages offer both generic comparison sorts†. But the defaults matter and as always in C++ the defaults are wrong, here it's reflected in naming. That's not actionable information, except in the sense that the correct action is "don't use C++". Because sure, I know about sort stability, and I know about pointer provenance, and about memory ordering, but there might be any number of things I do not know and unfortunately in C++ "you should know and understand" absolutely everything at all times, which is not viable. † The C++ standard library sorts are both much slower than in Rust, but hey, they're also both less safe so you're really getting the worst of both worlds
- patrick451 4mo ago
  > Sure, both languages offer both generic comparison sorts†. But the defaults matter and as always in C++ the defaults are wrong, here it's reflected in naming. Why, exactly, is the c++ std::sort "wrong"? There are tradeoffs both ways. You happen to prefer stable sorting to speed, but that is a preference not an objective fact.
  - tialaramex 4mo ago
    > Why, exactly, is the c++ std::sort "wrong"? It's silently an unstable sort, which is surprising, and then to add insult to injury it's also slower. Yeah, I know, the C++ unstable sort is so slow it's slower than Rust's stable sort. YMMV for input types, sizes etc but generally that's what the numbers look like and though it's not universal it's actually quite common. "I bet the C++ is faster" is the wrong instinct, sometimes by a large margin.
    - bregma 4mo ago
      So C++ is "wrong" because it doesn't work like something that came along 40 years later and you used first? The problem does not appear to be in C++.
      - tialaramex 4mo ago
        No? One of the giveaways of how unserious such responses are is that I spent many years getting paid to write C. The home where I'm writing this was bought† with money made writing C years ago. Rust wasn't even a twinkle in Graydon's eye when I started that job, let alone when I first wrote C last century. The choice to provide the unstable sort and then add a stable sort as an afterthought smells of the New Jersey approach to me. It was easier to do this, and too bad for the users, they weren't the priority. It's the wrong choice because if you don't know about sort stability this outcome is surprising, so this means that although a beginner probably thinks they know what "sorting" means they actually mustn't use the sorting APIs in such a language until they've learned extra material. † For cash, I don't like to owe people money, including having a mortgage
    - jltsiren 4mo ago
      And stable sorting typically allocates large amounts of memory, which is also an unpleasant surprise. I prefer the C++ naming convention, because it matches my expectations. When I studied CS, quicksort was considered the default sorting algorithm, and stable sorting was therefore a special case. My pet peeve is that standard library sorting algorithms are still mostly single-threaded. Multicore CPUs have been the norm for ~20 years, but standard libraries still don't offer reasonable algorithms for sorting large arrays.
    - patrick451 4mo ago
      You are failing to make an argument for why stable sorting is objectively the correct choice. Just because something doesn't match your expectations doesn't make it wrong.
      - tialaramex 4mo ago
Mond_ 4mo ago
Sort specifically is kind of a weird example, but C++ is full of awful naming. std::map (which is not a hash map, which is what most people would expect), std::move (which doesn't move), std::vector (which is not a vector), and std::vector<bool> (which is not even a std::vector).

by bregma 4mo ago

tialaramex 4mo ago

Sure, both languages offer both generic comparison sorts†. But the defaults matter and as always in C++ the defaults are wrong, here it's reflected in naming. That's not actionable information, except in the sense that the correct action is "don't use C++". Because sure, I know about sort stability, and I know about pointer provenance, and about memory ordering, but there might be any number of things I do not know and unfortunately in C++ "you should know and understand" absolutely everything at all times, which is not viable. † The C++ standard library sorts are both much slower than in Rust, but hey, they're also both less safe so you're really getting the worst of both worlds

patrick451 4mo ago
> Sure, both languages offer both generic comparison sorts†. But the defaults matter and as always in C++ the defaults are wrong, here it's reflected in naming. Why, exactly, is the c++ std::sort "wrong"? There are tradeoffs both ways. You happen to prefer stable sorting to speed, but that is a preference not an objective fact.
- tialaramex 4mo ago
  > Why, exactly, is the c++ std::sort "wrong"? It's silently an unstable sort, which is surprising, and then to add insult to injury it's also slower. Yeah, I know, the C++ unstable sort is so slow it's slower than Rust's stable sort. YMMV for input types, sizes etc but generally that's what the numbers look like and though it's not universal it's actually quite common. "I bet the C++ is faster" is the wrong instinct, sometimes by a large margin.
  - bregma 4mo ago
    So C++ is "wrong" because it doesn't work like something that came along 40 years later and you used first? The problem does not appear to be in C++.
    - tialaramex 4mo ago
      No? One of the giveaways of how unserious such responses are is that I spent many years getting paid to write C. The home where I'm writing this was bought† with money made writing C years ago. Rust wasn't even a twinkle in Graydon's eye when I started that job, let alone when I first wrote C last century. The choice to provide the unstable sort and then add a stable sort as an afterthought smells of the New Jersey approach to me. It was easier to do this, and too bad for the users, they weren't the priority. It's the wrong choice because if you don't know about sort stability this outcome is surprising, so this means that although a beginner probably thinks they know what "sorting" means they actually mustn't use the sorting APIs in such a language until they've learned extra material. † For cash, I don't like to owe people money, including having a mortgage
  - jltsiren 4mo ago
    And stable sorting typically allocates large amounts of memory, which is also an unpleasant surprise. I prefer the C++ naming convention, because it matches my expectations. When I studied CS, quicksort was considered the default sorting algorithm, and stable sorting was therefore a special case. My pet peeve is that standard library sorting algorithms are still mostly single-threaded. Multicore CPUs have been the norm for ~20 years, but standard libraries still don't offer reasonable algorithms for sorting large arrays.
  - patrick451 4mo ago
    You are failing to make an argument for why stable sorting is objectively the correct choice. Just because something doesn't match your expectations doesn't make it wrong.
    - tialaramex 4mo ago

Mond_ 4mo ago

Sort specifically is kind of a weird example, but C++ is full of awful naming. std::map (which is not a hash map, which is what most people would expect), std::move (which doesn't move), std::vector (which is not a vector), and std::vector<bool> (which is not even a std::vector).