>>35
True enough; on second thought, I actually meant syntax overloading, of which operator overloading is a large, but far from sufficient, part.
>Therefore
>>29 has obviously not read his SICP today and should crawl back to C++, along with his job.
I have actually (well, not today), and I do love LISP for its ability to do all that, much like I love haskell for project euler exercises. I still prefer C++ for getting real work done though, even though it's far from perfect.
>>36
>What would you consider 'noticeable'?
Visible in source code.
BigInteger x = y.copy(); x.add(z); is noticeably different from
int x = y; x += z;, whereas
BigInteger x = y; x += z; isn't. If your language supports the latter style, I couldn't care less whether BigInteger is part of the language of part of the library - the only difference being that I may need to
#include <bigint.h>.
>Almost no languages actually fit your criteria, since I can roll my own data structures in C and add an interface to it in the language.
And how does this not fit my criteria, except for the difference in syntax?
>Sepples only fits your criteria because it has no built-in data structures. This is not a good thing; the resulting library specifications took decades to become complete, portable, bug-free, and reasonably fast.
And do you think they would be complete, portable, bug-free, and reasonably fast any sooner if std::map was part of the language instead of the standard library?
My point is pretty much that in a proper language - which C++ manages
reasonably well (that is, better than most imperative alternatives)
in this regard - I, as a programmer, should hardly be able to see what exactly is in the language and what is in the standard library, except maybe having to include some header file or the like.