Re: [boost] C++ announcements coming tomorrow

Subject: Re: [boost] C++ announcements coming tomorrow
From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2012-11-03 21:43:33

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