4 ms·

The nice thing about C++11 is that the designers seem to have actually tried to increase usability, rather than just maximizing expressivity, which is usually t

by dfan 12y ago

The nice thing about C++11 is that the designers seem to have actually tried to increase usability, rather than just maximizing expressivity, which is usually the case. Features like range-based for and auto make programming much more pleasant. I program in a functional style in many other languages, but could never bear to in C++ before because it was so awkward.

Silhouette 12y ago
I still wouldn't try to use too many functional idioms in C++ even now. It's just not a good language for that kind of programming style. For example, from the "New language features" section of the C++14 Wikipedia page[1], the first example is generic lambdas, which means we can now write: auto lambda = [](auto x, auto y) {return x + y;}; That's progress of a sort, but in Haskell, a language designed to support this style of programming, it looks like this: lambda = (+) Obviously C++ is slowly being left behind by modern programming language design and the collective experience of the programming industry over several decades since C++ was invented. Eventually it will be superseded by other languages that do support more expressive language features and better designed standard libraries (which is easy to do with the wisdom of hindsight, of course -- this is not a criticism of the people who built C++ without the benefit of that hindsight). But since we don't yet have any such alternatives that don't also have significant drawbacks and/or unacceptable run-time performance characteristics, for the near future C++ is still going to be the first choice for a lot of projects in the real world. In that respect, closing the loopholes and fixing the pain points is useful for a lot of people, and very wisely that seems to be what the standards committee are concentrating on doing. [1] http://en.wikipedia.org/wiki/C%2B%2B14#New_language_features http://en.wikipedia.org/wiki/C%2B%2B14#New_language_features
- dfan 12y ago
  I agree with your example. But, for example, before C++11, if I wanted to do an even slightly non-trivial map or filter I'd probably do it by hand rather than write a (C++) "functor" or assemble some function in place with std::bind1st et al., whereas now I will happily write a simple lambda.
  - Silhouette 12y ago
    I agree, but in C++, I probably wouldn't try to wrap that kind of logic up in a functional programming style with the standard algorithms anyway. I've read the advocacy and I've considered the arguments many times, and in a language designed to support those styles I would absolutely agree that using them is a huge improvement over a raw loop. But in those languages, the functional style has clear benefits for both readability and maintainability. Unfortunately, C++ is not such a language and the benefits of trying to shoehorn that programming style into C++ projects are far from clear, even with the new lambdas. Therefore, for logic that isn't completely trivial, I usually still choose to write the loop. I suspect we actually have quite similar preferences about programming style, and I don't like that favouring raw loops is the conclusion I've reached. However, as with some of the libraries using terribly clever template wizardry, I find sometimes in C++ the medicine is worse than the disease.

by dfan 12y ago

Silhouette 12y ago

I still wouldn't try to use too many functional idioms in C++ even now. It's just not a good language for that kind of programming style. For example, from the "New language features" section of the C++14 Wikipedia page[1], the first example is generic lambdas, which means we can now write: auto lambda = [](auto x, auto y) {return x + y;}; That's progress of a sort, but in Haskell, a language designed to support this style of programming, it looks like this: lambda = (+) Obviously C++ is slowly being left behind by modern programming language design and the collective experience of the programming industry over several decades since C++ was invented. Eventually it will be superseded by other languages that do support more expressive language features and better designed standard libraries (which is easy to do with the wisdom of hindsight, of course -- this is not a criticism of the people who built C++ without the benefit of that hindsight). But since we don't yet have any such alternatives that don't also have significant drawbacks and/or unacceptable run-time performance characteristics, for the near future C++ is still going to be the first choice for a lot of projects in the real world. In that respect, closing the loopholes and fixing the pain points is useful for a lot of people, and very wisely that seems to be what the standards committee are concentrating on doing. [1] http://en.wikipedia.org/wiki/C%2B%2B14#New_language_features http://en.wikipedia.org/wiki/C%2B%2B14#New_language_features

dfan 12y ago
I agree with your example. But, for example, before C++11, if I wanted to do an even slightly non-trivial map or filter I'd probably do it by hand rather than write a (C++) "functor" or assemble some function in place with std::bind1st et al., whereas now I will happily write a simple lambda.
- Silhouette 12y ago
  I agree, but in C++, I probably wouldn't try to wrap that kind of logic up in a functional programming style with the standard algorithms anyway. I've read the advocacy and I've considered the arguments many times, and in a language designed to support those styles I would absolutely agree that using them is a huge improvement over a raw loop. But in those languages, the functional style has clear benefits for both readability and maintainability. Unfortunately, C++ is not such a language and the benefits of trying to shoehorn that programming style into C++ projects are far from clear, even with the new lambdas. Therefore, for logic that isn't completely trivial, I usually still choose to write the loop. I suspect we actually have quite similar preferences about programming style, and I don't like that favouring raw loops is the conclusion I've reached. However, as with some of the libraries using terribly clever template wizardry, I find sometimes in C++ the medicine is worse than the disease.