On 11/3/2012 3:15 PM, Eric Niebler wrote:
On 11/3/2012 2:24 PM, Paul Mensonides wrote:
He's been told repeatedly.
To be fair to Herb, it's not his call to make.
I don't dislike Herb, and my rant isn't really about Herb. I just believe that everything that he says WRT VC++ is carefully filtered through MS's marketing engine--which is what I have a problem with. Because of that, I do not trust anything that MS says, via Herb or others, with respect to VC++ or MS's so-called "commitment" to C++. I believe that MS has made valuable contributions to C++, but also that they have hobbled it and tried to control it. In the cases where they have made contributions, such as putting money into this new foundation, I do not believe it has been for altruistic reasons but is instead yet another marketing attempt. Don't get me wrong, I have nothing against companies trying to make money. I do have a problem with companies attempting to disguise their agendas. All of the above is opinion, but trust is earned not assumed, and I have not seen anything out of MS WRT to C++ that gives me cause to issue trust. In fact, I've seen the opposite time and again over a very long period of time.
Not that I'm against a "foundation" or against adding more libraries to the standard library, but the only things that C++ programmers need to produce portable code are C++ compilers that implement the standard (and only the standard--not a bunch of vendor-specific extensions). As an example, paraphrasing, "We're proposing 'await' but if the committee doesn't want it we can always add it as an extension." It is particular compiler vendors and their compilers that are getting in the way of progress.
I disagree with the view that it's categorically wrong for compiler vendors to implement extensions, as long as there is a way to turn them off, and as long as the standard library works in a std-compliant way when they're off.
To be clear, I understand the need for compiler-specific things like pragmas (and maybe even things like __stdcall and __cdecl). I do have a problem with feature extensions of any kind, however. The reason is not because I believe the language to be sacrosanct so much as that it breeds lack of portability. If a vendor wants a particular feature extension, the route is through the language standard, which, to some degree, allows such features to be discussed and designed in a much larger context and also inhibits the abuse of popular-compiler-vendor power. If that route fails, the feature is either not ready or not general purpose enough to belong in the language. I hardly believe the standard to be perfect. For example, I believe initializer lists to be an abomination. Such a facility should have been implemented atop a less-castrated variadic template mechanism. However, initializer lists are part of C++ because the majority thought they were a good idea. Therefore, if I was to implement a compiler and call it C++, I had better implement that feature even if I don't like it. The same is true for two-phase lookup, etc., etc.. The point being, *I*, as the compiler vendor, don't get to decide what is and is not C++ and what should or should not be implemented. What C++ needs is portable libraries. In theory, if a library is not making platform-specific API calls and not using vendor extensions, portability should be achieved *accidentally*--not by drastic effort by a library implementer for each compiler/platform. The bottom line here is not more libraries added to the standard library per se nor a foundation. Those are solutions to different problems. The bottom line is lack of real prioritization to implement the language by certain compiler vendors. *They* are the problem. VC++ is at the top of that list, though it is by no means the only one on the list. Each compiler/platform implements a union of a subset of C++ and a set of extensions. Writing portable C++ code requires using only the intersection of those sets from all compilers/platforms together with workarounds for all bugs in all scenarios. Almost nobody does that, and therefore we end up with lots of non-portable or conditionally-portable libraries. If compilers implemented 100% of the language (allowance being made of course for features recently added to the language) and did not provide extensions (which by their very existence encourage their use), then libraries can be developed to generalize platform-specific details (not compiler-specific details) (e.g. Boost.Filesystem, Asio, etc.) and a hierarchy of portable libraries *can* be developed.
Further, we don't need C++/CX (or whatever it is called this iteration). The .Net Framework is a huge pile of typical MS bloatware, and, contrary to popular opinion, C# is actually *not* a good language.
C++/CX has nothing whatsoever to do with .NET. You're thinking of C++/CLI.
I'm thinking both actually. I.e. extensions to the language designed to interoperate with other things. Those should be 100% library. Same thing with AMP.
It actively interferes with abstraction and encourages bloatware production. I am so tired of hearing the "right tool for the job" fallacy WRT programming languages especially WRT to C# and Java.
One language to rule them all, then?
In theory, yes. Or, at least, almost yes. There is a legitimate difference between scripting vs compiled software (e.g. Python vs. C++) but that difference has to do with codebase longevity, not application domain. Otherwise, programming is about abstraction and composition of those abstractions. A theoretical language which allows full abstraction and full composition of abstractions is the "one language to rule them all." I'm not saying that is C++, and C++ is unlikely to reach that even in the limit, though it is the closest of current major languages. What abstraction and composition give you is the ability to decompose software at the library component level--whose domain reach extends far beyond the language itself and the standard libraries of the language. Given that such a language doesn't yet exist, there is room for a competition of ideas in how to reach or most closely approximate that goal. In that competition there are means of comparing languages objectively. The only significant productivity boost that C# yields is the presence of the large monolithic .Net Framework. It isn't the language itself that is more productive. The language is, in fact, crippled WRT abstraction and composition. Just like Java, it is full of decisions intentionally designed to enforce a particular way of coding--which is the opposite of abstraction, the opposite of DSEL design, and so on. Furthermore, its generics mechanism is a joke, it lacks a typedef concept and therefore an associated types concept, the universal gc model is fraught with issues related to release of non-memory resources (leading to the Dispose so-called "pattern" and tons of the equivalent of try/catch/rethrow cleverly hidden as using() which is the absolute opposite of abstraction). It is simply not a good language from first principles because its first principles are objectively wrong. Related to that, the supposed easy-to-use languages such as C# actually amount to unqualified people implementing (and re-implementing) duct tape solutions to problems. That is not a good thing, it's detrimental in the long run. Duct tape solutions, in turn, drastically deprioritize the development of good, reusable, long-term solutions. WRT to C#, I'm not speaking without experience, unfortunately. I implemented and maintain a C# code-base of approximately 60,000 lines (not particularly small for one person, though not large) for my employer (which is not a software foundary). I originally made the decision to use C# because I believed at the time that C++ would be beyond the capability of our IT department to understand and maintain. In retrospect, that was a mistake on my part where I fell into the right-tool-for-the-job trap. However, as time went on, the domain logic far exceeded the language complexity, and the codebase is now well beyond the capability of our IT department regardless (lots of math). In that development, I routinely ran into C#'s lack of abstraction capability. Now, I want to port it to C++, but to do that I have to replace usages of the .Net Framework with libraries. Boost provides some of those that I need, Qt (which is its own style of abomination) provides others, but others are more difficult. Not because such libraries don't exist, but because they are often full of unjustified platform/compiler-specific extensions, rely on other libraries with such reliance, or run afoul of broken or missing language features on said compilers. Regards, Paul Mensonides