I can understand why religion can so easily fill a scientifically minded person with disgust, because it is so often the worst and most obnoxiously stupid representatives for religion that are the loudest and make the most absurd demands on our time and efforts. However, there is a large majority that are really quite sensible and open-minded.
If that were true, then scientifically minded people wouldn't dislike homeopaths so much. But we do, despite almost all homeopaths being generally nice people. Nice people can still do stupid things, and dangerously stupid things.
Your reasons about why they are complementary rather than antithetical is precisely the reason they are antithetical. The problem is you can't stop people from noticing "that's funny", which is the kind of thing Asimov says makes science work. When people can't stop noticing things, they can't stop studying things. They can't stop studying things that people don't want them to study. Religion, not just the extreme, but mainstream religion, has a list of things they preferred remain unstudied. That's why moderates always clamour for "non-overlapping magisteria" when they're under threat, but have no problem overlapping if they feel confident.
This would be mitigated by making it an optional feature.
It wouldn't, because if you use a library that inadvisedly uses the "optional" feature, you have no way to turn it off.
but more than once I've found myself cursing this omission.
You know what, so have I. But then I thought about the design for a bit and realized I could do it a much more better way. I like reflection when I'm doing rapid prototyping. Personally I find lambdas more useful than reflection, and luckily it's a major part of C++11 already implemented in most compilers.
But then you're optimising. Not the compiler.
There has to be some kind of manual optimizing. No compiler can fix people using the wrong data types or algorithms. Incidentally, C++11 templates can help the compiler optimize more efficiently. For example, std sort is faster than qsort, because qsort can only take in a function pointer, whereas std sort can embed the sorting function as part of the type once the template has been fully realized. But back to strings. What if an array of chars is the only efficient way to implement something, but the language has hijacked all string literals as built-in strings which are necessarily less efficient than a plain old array?
If it prevents useful features from existing, this is a poor design decision. Plus, you'd only need to include it if it was actually used. It could even be added as an optional feature to classes.
No, it's a good design decision. Why would anyone want their program to pay for something they don't use? Others have argued too many unneeded powerful features already exist in C++, thus contradicting your own definition of a poor design decision. I personally would side more with you than those who argue C++ has too much stuff, but there has to be a limit, and the limit of not bogging down a whole language just to include certain features is a sensible limit, because it is something that can be measured. Much more sensible than ideologically impose limitations like the OO or pure functional paradigm fanaticism.
This is a problem with the library. Not C++.
You simply cannot make a blanket statement like that. A library, especially highly generic concepts like containers, iterators, and algorithms, needs to cater to as many types as they can with minimal configuration. You can't fault a library or a language so absolutely.
The above code can optimise to {return 11;} if strings are built in. If it's a type then it involved allocating at least 3 chunks of memory and 2 memory copies.
If that kind of optimization is needed, people can use a string literal. If the string in your example needs to be modified later on, then that optimization cannot be done in any implementation. As for excessive allocations, this is now solved with rvalue references and move semantics.
Can be implemented as static members. Performance cost is a little bit of static data per class type.
Yes, but the point is that it breaks the "you don't pay for what you don't use" design principle of C++.
Not at all. If you don't use it then the string conversion function won't be linked.
You can't guarantee it. For example, if some library happens to use some kind of generic conversion function for its templated type, and you include the enum, then you've automatically dragged in a whole bunch of stuff.
A built in type means that the compiler is allowed to know what a string is and is and can handle strings differently for optimisation.
Any implementation of a string in any language boils down to a char array, whether it's built in, or a library data type.
It also means that we can have third party libraries that don't rely on an assumption that we're using the right std::string implementation.
Those would be bugs in the string implementation, which do not disappear by becoming in-built. If the standard defines strings as a built-in type, you've just shifted the problem from the library to the compiler which doesn't fix anything.
If I want that I'll add a lisp macro as a precompile step. Templates add a lot of complexity for limited benefit.
If you want that, you can just use templates. If you don't use the full power of templates, then you don't need to expose yourself to that complexity. The complexity is pushed to compile time, and the "limited benefit" often means greater performance because virtual functions and class hierarchies aren't needed to achieve polymorphism.
Real Programmers don't eat quiche. They eat Twinkies and Szechwan food.
