3 ms·

Back when I competed regularly in TopCoder for food money in college, std::next_permutation saved my bacon. I got so good at whipping out <algorithm> in C++ th

Back when I competed regularly in TopCoder for food money in college, std::next_permutation saved my bacon. I got so good at whipping out <algorithm> in C++ that every other language's standard library felt deficient. Python's basically caught up with itertools and the built-in set type. Often you can replace dozens of lines of for loops and if statements with set subtraction and some generator comprehensions. Sometimes the code ends up faster, to boot!

loup-vaillant 17y ago
Then you will absolutely love Haskell's and Ocaml's standard libraries (if you can spare some CPU cycles). Paranoid static typing with easy genericness (more flexible than C++ templates), and they don't have the one show stopping flaw C++'s <algorithm> still have sometimes: lack of locality. Until C++ has closures, a loop will often look like this: body(…){ code_of_body; } fun(…) { // (Big) blob of code std::loop(begin, end, body) … } I have done it. Lack of locality kills readability, so I still use loops even when std::accumulate or std::foreach would do.
- eru 17y ago
  Since the root comment talked about Python's set, you might want to have a look at Haskell's Data.Set. Haskell's Data.Map is more or less equivalent to Python's dict. You can also map and fold over Sets and Maps. There is no built-in function for applying a function to a set to get a map, but you can easily add one.
- jemfinch 17y ago
  Since C++ templates are Turing-complete, and at least OCaml's type system is not, I'm fairly confident that the claim that OCaml's "easy genericness" is "more flexible than C++ templates" is demonstrably false.
  - loup-vaillant 17y ago
    In theory. In practice, I found that translating from OCaml to C++ is often painful, while the reverse is quite easy. When I deal with generic code, this difficulty is largely attributable to the differences between Hindley-Milner and templates. My conclusion is that where it really matters, C++'s templates are less flexible than OCaml's genericness. I dare you to try and prove me wrong with production code without being fired… upon.
    - jemfinch 17y ago
      First, I think it's important to note that as the original claimant here, the onus is on you to prove your claim, not on me to disprove it. If you think OCaml's "easy genericness" is "more flexible than C++ templates" then provide an example of the exercise of such flexibility. Second, ease of translation between languages is not particularly relevant to flexibility. Insofar as it is relevant, things that are more flexible are typically more difficult, not easier, on account of that flexibility, at least in my experience. Remember, your original claim was not about ease, but about flexibility. I doubt you attempted the subtle transition maliciously, and perhaps your original claim was where you misspoke, but I would never argue that C++ templates are easier than other forms of genericity, simply that they're more flexible.

loup-vaillant 17y ago

Then you will absolutely love Haskell's and Ocaml's standard libraries (if you can spare some CPU cycles). Paranoid static typing with easy genericness (more flexible than C++ templates), and they don't have the one show stopping flaw C++'s <algorithm> still have sometimes: lack of locality. Until C++ has closures, a loop will often look like this: body(…){ code_of_body; } fun(…) { // (Big) blob of code std::loop(begin, end, body) … } I have done it. Lack of locality kills readability, so I still use loops even when std::accumulate or std::foreach would do.

eru 17y ago
Since the root comment talked about Python's set, you might want to have a look at Haskell's Data.Set. Haskell's Data.Map is more or less equivalent to Python's dict. You can also map and fold over Sets and Maps. There is no built-in function for applying a function to a set to get a map, but you can easily add one.
jemfinch 17y ago
Since C++ templates are Turing-complete, and at least OCaml's type system is not, I'm fairly confident that the claim that OCaml's "easy genericness" is "more flexible than C++ templates" is demonstrably false.
- loup-vaillant 17y ago
  In theory. In practice, I found that translating from OCaml to C++ is often painful, while the reverse is quite easy. When I deal with generic code, this difficulty is largely attributable to the differences between Hindley-Milner and templates. My conclusion is that where it really matters, C++'s templates are less flexible than OCaml's genericness. I dare you to try and prove me wrong with production code without being fired… upon.
  - jemfinch 17y ago
    First, I think it's important to note that as the original claimant here, the onus is on you to prove your claim, not on me to disprove it. If you think OCaml's "easy genericness" is "more flexible than C++ templates" then provide an example of the exercise of such flexibility. Second, ease of translation between languages is not particularly relevant to flexibility. Insofar as it is relevant, things that are more flexible are typically more difficult, not easier, on account of that flexibility, at least in my experience. Remember, your original claim was not about ease, but about flexibility. I doubt you attempted the subtle transition maliciously, and perhaps your original claim was where you misspoke, but I would never argue that C++ templates are easier than other forms of genericity, simply that they're more flexible.