31–40 of 57 posts
Do people really still make the `=` vs `==` mistake? GCC -Wall has had "warning: suggest parentheses around assignment used as truth value" since as long as I can remember.
It's the one mistake that everyone seems to cite when complaining about C, and I've literally never seen it happen in all my years of programming. Right up there with fall-through cases.
If your only example to show C++ verbosity fails to compile and is also patently wrong, you are not making a good point. (The constructor is private, the variable naming prevents short accessors such as Rectangle::width()). Better: struct Rectangle { double x,y, width, length; }; int main() { Rectangle r = {0., 0., 10., 10. }; return 0; } This even compiles in C++03. If you really insist on private members, you will…
bookmarked: http://bartoszmilewski.com/2011/07/11/monads-in-c/ http://bartoszmilewski.com/2010/11/29/understanding-c-concep...
http://blog.garillot.net/post/15147165154/every-single-fresh...
My somewhat biased stance: functional programming languages make you progress as a programmer quickly. Becoming great requires deliberate practice and intrinsically hard problems. So you learn programming and CS about 5-10 times as fast in a functional language. This is part of why enterprise Java/C++ devs plateau at a skill level of 1.2 (even into their gray-haired years) while ML and Haskell programmers can reach 1…
There are very few people who have just learnt functional programming. I have met a few in academia, and they tend to be as "bad" as the pure Java/C++ programmers, but in a different way. They have trouble understanding how their code will boil down to CPU instructions, and so have trouble with performance, particularly (unsuprisingly) mutating algorithms, which are vital for performance in some situations.
After I have defined a high-performance algorithm, they often want to modify it to make it "more beautiful" (which means functional) and in the process destroy the performance.
Also, I had quite a lot of exposure to Haskell, and I haven't found C++ hate. I got some Haskell hate, because doing some things (mutating algorithms and bit fiddling) were really, really hard, while I found most of the things I loved from Haskell I could do in C++, with care.
I work on low-level algorithm design in A.I., where performance is everything and there are many interlocking, low-level and complex algorithms and data structures. I know that other problems might well have very different characteristics. For example, I have no real ideal how Haskell vs C++ would compare for the average web app for example (or of course, something like Ruby/Python which seem to be much more popular).
Earlier quoted context omitted.
Yes, I know, but there is no way to enforce it. This a classic "noob" mistake with macros - using a macro argument more than once.
That's why in C++ people seem to generally recommend inline functions instead. Not only do the arguments only get evaluated once, but the whole thing is type safe too. Of course, people still misuse macros.
One of the more clever not so well known C++ type system hacks I have seen is the way Ogre3D (a graphics engine for games) handle Degrees versus radians. Basically they have a class for each and have overloaded the operators so that you can mix and match operations freely (e.g you get a radian result from some computation which you can then add twenty degrees to simply by saying + Degree(20) and have the C++ type sys…
One of the more clever not so well known C++ type system hacks I have seen is the way Ogre3D (a graphics engine for games) handle Degrees versus radians. Basically they have a class for each and have overloaded the operators so that you can mix and match operations freely (e.g you get a radian result from some computation which you can then add twenty degrees to simply by saying + Degree(20) and have the C++ type sys…
map and fold are available in C++, though they're called std::transform (in ) and std::accumulate (in ). Totally agree with the author's point, the C++ I write nowadays is heavily influenced by my Scala/Haskell/Lisp exposure and is much better for it.
Part of the beauty of Haskell is the aggressive effort to define each function on the most general type it applies to (and then specialize to concrete types during compilation, a la C++, when performance is requested via a pragma), leading to a rich hierarchy of tiny type classes (type classes are similar to C++ abstract classes)
That first example is terrible. C doesn't guarantee that the arguments to a macro are evaluated only once. At best, you might be doing the computation twice. At worst (if the function has internal state), you could get different answers for the comparison and the assignment. The non Haskell-style is better!
Earlier quoted context omitted.
Technically, the code is wrong only if f() is not pure.
Yes, I know, but there is no way to enforce it. This a classic "noob" mistake with macros - using a macro argument more than once.
map and fold are available in C++, though they're called std::transform (in ) and std::accumulate (in ). Totally agree with the author's point, the C++ I write nowadays is heavily influenced by my Scala/Haskell/Lisp exposure and is much better for it.
Does 'accumulate' work on non-'numeric' types? Part of the beauty of Haskell is the aggressive effort to define each function on the most general type it applies to (and then specialize to concrete types during compilation, a la C++, when performance is requested via a pragma), leading to a rich hierarchy of tiny type classes (type classes are similar to C++ abstract classes)
int main() {
string s[] = { "a", "b", "c" };
// will print "abc"
cout template string accumulate(InputIterator first,
InputIterator last, string init);