I get the distinct feeling that no matter how I respond to what you say, you'll find some way to extend the argument. I'm not here to debate you about general

I get the distinct feeling that no matter how I respond to what you say, you'll find some way to extend the argument. I'm not here to debate you about general issues with C++; I'm here to argue against very specific, incorrect claims you made about C++ in your initial posts. I'm not interested in arguing with you ad infinitum. > Now, actually using STL's <algorithm> and still end up with readable code isn't easy to me. For instance, each time `for_each` or `accumulate` would be appropriate, I end up writing a `for` loop instead, because the end result is more concise and more local. This seems to be a new complaint, again unrelated to your previous complaint. No one, least of all me, is claiming that C++ is concise. If that's a debate you want to have, you'll need to find some other patsy to have it with. > So in the end, container independent algorithms rarely matter to me. They matter a lot to any implementer of new containers and algorithms, because they mean that any container implementer can provide iterators and automatically support a huge library of algorithms, and any algorithm implementer can automatically support a wide array of containers without needing any specific knowledge of how those containers are implemented. > I think we don't use "simple" in the same way. Here, such an implementation of lists takes only 12 tokens and 2 lines in ML. How many do you need to do the same in C++? When did this debate become about conciseness? Your claim was not that parametric polymorphism was wordy in C++, it was that the implementation was "abysmal". In reality, the implementation is as optimal as it really can be in an imperative, C-derived language: a non-polymorphic data structure on some type "X" can be made polymorphic by prepending "template <typename T>" before the data structure and replacing all references to "X" with "T". That's pretty simple. The difference you note in line counts for implementing a singly linked list is not because of any real difference in capability of the language to support parametric polymorphism, but in ML's support for algebraic data types as opposed to C++'s support for machine-based data types: now you're introducing yet another complaint which is not your original complaint. > The real problem shows when you combine them with inheritance: you have to jump through some hoops (like having to re-declare virtual methods in the derived classes). Perhaps, but since virtual methods and inheritance-based subtyping is something ML doesn't support at all you cannot fault C++ for its less-than-optimal support for those features in comparison to ML. > But even then, we're not done. Before you do the actual lambda lifting, you have to parse the source code. Trivial in Lisp, but quite a feat in C++. Introducing yet another complaint unrelated to anyone's original claims. Ignoring it, since it's not relevant to the reason why this thread originally began. > To me, such a restriction is sufficient to make function second-class citizen. "First class" is a well defined term in programming language design and implementation, and it's not the same definition you're trying to use here. I see no point in arguing with you about your non-standard use of the term.