@Novox: Is there some other form of metaprogramming in C++? C
That's the point: No, there isn't (well, if you ignore C macros, which are metaprograms). Herb is certainly right that currently the use of metaprogramming in C++ is limited to an Elite Priesthood™, but I do not believe that the sole reason is metaprogramming per se or its limited usefulness, but the fact that C++ does not yet have proper support for metaprogramming. And that's why a language extension like "static if" might be a valuable addition to the language: It could make metaprogramming in C++ more accessible, maybe even user-friendly.
Hence, Herb's and Scott's points (as in the worries about repelled-not-attracted or run-screaming reactions ;]) are fully and well taken (it's also true TMP is indeed just one area of C++ and not in quite as widespread use as the others). At the same time, simplifying the syntax / removing the awkwardness are directly meant to address this exact point
Exactly. I'd say people run screaming not because they fear metaprogramming, but because of the unbearable awkwardness of advanced C++ template metaprogramming.
What's the purpose of the namespace System.Reactive.Linq.Observαble (note the 'alpha' instead of an 'a')? It contains internal classes that seem to correspond to the operators defined in the static class System.Reactive.Linq.Observable (with a Latin a).
If you want to make a high-performance numeric library, you'll often need to use the basic characteristics of the data type. [...] For performance, you need to use type-specific algorithms anyway.
True. For solving large problems you would always want to use low level high-performance implementations of BLAS/LAPACK like the MKL that is tuned to individual CPUs and cache sizes. But what generic programming should enable you to do is to built easy-to-use interfaces on top of these low level libraries, something you can do with template meta-programming in C++ (e.g. uBLAS, FLENS) -- though it won't be a particular pleasant experience.
A more typical use case for "generic numerics" on .NET would be something like "implement a generic class for small vector types". On .NET you can't really express the required type constraints (like "T is supposed to define a zero and to have a binary operator"), nor do .NET generics support the flexible typing behavior of C++ templates (structural typing) or the flexibility of Haskell's type classes. Yes, there are a few ways to still achieve the goal, but all of those workarounds either require interface dispatch or run-time code generation, both of which prevent inlining with the current generation CLR JITer.
I bet it’s not gonna happen. C# doesn’t have macros by design. It has several advantages that weren’t an issue 30 years ago when C++ was designed, but much clearer to see today. Ever noticed how much better VS intellisense is working with C# code compared to Visual C++? Huge part of the reason is macros.
It needn't (and shouldn't) be C macros, i.e. untyped text replacement. There are many languages out there that provide a sane way of meta-programming. Have a look at Scheme, Nemerle, Boo or D, for instance. Still, I also do not expect C# to gain such abilitiesas a built-in language feature in the foreseeable future.
Nope, C++ doesn’t have support for numeric generics neither, those are templates. Different breed.
C++ does have support for true generic programming (by accident, admittedly) and that's what bcooley is probably referring to; it's not about what "generics" mean in the context of .NET.
Generics are type-safe and support robust programming very well.
Templates are type-safe as well, they just don't use nominal typing. If concepts would have made it into C++11, this would have brought templates much closer to Haskell's type classes (see Bernardy et al., 2008).
The compiler optimizes the code a lot.
I don't know, whether you're talking about the C# compiler or the JITer. The latter one is the component that is critical for performance and lacks quite a bit behind Sun's/Oracle's HotSpot JIT compiler when it comes to inlining virtual method calls, not to mention optimizing C++ compilers (of course, C++ compilers don't need to compile on the fly, so that's not really a fair comparison).
Mono runs applications with severely lower performance than the .NET Framework on Windows. Really no need to comment more on this.
Until recently, yes. I don't have up-to-date measurements, but I suspect that their new GC and the LLVM backend might change this in the not too distant future. Well, hopefully...