3 ms·

Your experience with Python and Haskell has most likely made you a far better C++ programmer than you were before.

yummyfajitas 17y ago
This is absolutely the case. I'm now used to first class functions, currying, etc. C++ actually has them, hidden in the stl and boost::function. Whatever I can't do using those, I can usually do by creating a family of classes which only implement operator() (I've only needed to do this once or twice, and it might have been avoidable). Due to using a language with native dicts (and syntactic sugar), they are now part of my vocabulary. This means I immediately reach for std::map or boost::unordered_map when it makes sense. Similarly, python generators and haskell lazy lists have made view sequences as reasonable objects to generate and iterate over. Custom iterators are just the same thing with added verbosity. If I never used higher level languages, I'd still be treating C++ as C with objects.
- scott_s 17y ago
  In C++, I'm more likely to write a struct/class which implements operator() than an actual function. It lets me write code like this, which does mutate state, but I put it off as long as possible: xformerlist& lbrace = node.children.front().xformations; xformerlist& rbrace = node.children.back().xformations; fn_and<shared_variable> row_and_flat(&shared_variable::is_row, &shared_variable::is_flat); const sharedset& flat_ins = filter(row_and_flat, set_union_all(in, inout)); const sharedset& flat_outs = filter(row_and_flat, set_union_all(out, inout)); const sharedset& flat_all = set_union_all(flat_ins, flat_outs); make_conditions<gen_in<row_access> > make_gen_in_row(parcond, conds, local_depths); make_conditions<gen_out<row_access> > make_gen_out_row(parcond, conds, local_depths); append(lbrace, fmap(make_gen_in_row, flat_ins)); append(rbrace, fmap(make_gen_out_row, flat_outs)); I imagine that code would give a lot of people fits. In my current project, I ran with a more functional approach to C++. I don't know if I'll keep everything I've used in this programming style, but I certainly will keep some of it.

This is absolutely the case. I'm now used to first class functions, currying, etc. C++ actually has them, hidden in the stl and boost::function. Whatever I can't do using those, I can usually do by creating a family of classes which only implement operator() (I've only needed to do this once or twice, and it might have been avoidable). Due to using a language with native dicts (and syntactic sugar), they are now part of my vocabulary. This means I immediately reach for std::map or boost::unordered_map when it makes sense. Similarly, python generators and haskell lazy lists have made view sequences as reasonable objects to generate and iterate over. Custom iterators are just the same thing with added verbosity. If I never used higher level languages, I'd still be treating C++ as C with objects.

scott_s 17y ago
In C++, I'm more likely to write a struct/class which implements operator() than an actual function. It lets me write code like this, which does mutate state, but I put it off as long as possible: xformerlist& lbrace = node.children.front().xformations; xformerlist& rbrace = node.children.back().xformations; fn_and<shared_variable> row_and_flat(&shared_variable::is_row, &shared_variable::is_flat); const sharedset& flat_ins = filter(row_and_flat, set_union_all(in, inout)); const sharedset& flat_outs = filter(row_and_flat, set_union_all(out, inout)); const sharedset& flat_all = set_union_all(flat_ins, flat_outs); make_conditions<gen_in<row_access> > make_gen_in_row(parcond, conds, local_depths); make_conditions<gen_out<row_access> > make_gen_out_row(parcond, conds, local_depths); append(lbrace, fmap(make_gen_in_row, flat_ins)); append(rbrace, fmap(make_gen_out_row, flat_outs)); I imagine that code would give a lot of people fits. In my current project, I ran with a more functional approach to C++. I don't know if I'll keep everything I've used in this programming style, but I certainly will keep some of it.