Slashdot Mirror
Interview With Herb Sutter
Anonymous Coward writes "Herb Sutter, a C++ luminary, recently joined Microsoft's Developer Platform and Evangelism Division, where he acts as a liaison between Microsoft and the C++ developer community. In this interview he speaks about his new job, the role of C++ in the .NET framework, and the current state of C++."
Nope, it definitely doesn't work.
c:\linux\src\kernel>nmake
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.00.9466 for 80x86
Copyright (C) Microsoft Corporation 1984-2001. All rights reserved.
kernel.c
kernel.c(3) : error : Invalid token : expecting "(C)", found "GPL".
compile aborted.
c:\linux\src\kernel>
bugger.
PGP KeyId: 0x08D63965
Fair enough, but given that Herb Sutter is an authority and "evangelist" on C++ in general - how can he reconcile his new position with the new licenses MS are attaching to their development tools which seem to prohibit any GPL'd application (e.g. GCC) linking against their .NET library?
You shouldn't find it so strange that a "guy which is secretary in the standards committee" works for a company which has recently declared its intention to change its ways and produce a fully conforming C++ compiler. Their internal build supports partial specialization now, and in fact most stuff other than export. It's finally getting to be about as compliant as compilers from other companies.
Did you know that Microsoft has relatively recently rejoined the C++ standards process, and even hosted the last ISO/ANSI C++ meeting? That's quite a turnaround.
After a little initial concern, I'm pleased to have someone with Herb's integrity working inside Microsoft. Over recent months (indeed, even before Herb joined MS) we've finally seen a willingness from Microsoft to discuss the flaws of VC++, and what they plan to do about it.
We can't assume that MS will play fair forever in this area, but we shouldn't assume that they'll double-cross the community. Much though the quality (or lack thereof) in VC++ annoyed me, I'm willing to give them the benefit of what little doubt is left. VC++7.0 is a step forward, and the next release is make-or-break in terms of the credibility of MS's C++ development team. If it's up with the leading group they'll have won the (possibly grudging) respect of large parts of the C++ community. If not, they might not get another chance so easily again.
The C++ language is _for_ people who write C++ code. Are you seriously suggesting that the majority of the users of a language should be banned from participating in the standards process, because they get money for doing their job?
I am hoping you really meant that the people who write the compilers should not be allowed input: but even this is impractical, since nobody wants a standard full of features which turn out in practice to be unimplementable.
I was at the ACCU Conference that Herb mentions in his speech, and at the end of the first day there was a special last-minute session scheduled with Herb and Stan, called "Revelation on the road to redmond". It was quite interesting, and when Herb introduced the man who had implemented partial specialisation in Visual C++, there was a tremendous round of applause! And this was not a conference full of Microsoft flunkies, far from it.
The upshot is, MS have an internal build of MSVC that will compile Loki. It should be available around the end of this year.
From the article:
/do/ want portabilty, you're on your own: you'll have to invent your own abstraction layer in order to achieve it. Obviously, some succeed better than others in that respect, and as he says, it doesn't keep people from trying.
:P), is much better for offering cross-platform services and libraries, simply because the burden does not lie upon each and every individual library developer anymore to create a platform abstraction layer. That only has to be done once, by the runtime.
.NET. But I think the reason why these are so big and ugly is because they want to make it possible to put the interface at every conceivable place. Of course the interfaces will be complex if you do that.
"Q: Standard C++ doesn't support modern programming concepts such as multithreading, distributed computing, components, and persistence. The result is a plethora of proprietary libraries and platform-dependent frameworks that make cross-platform development in C++ nearly impossible. Is Standard C++ still relevant? Which features would you like to see added to the language in the future?
A: Again, these questions arise from an overstated premise. Thousands of companies are routinely writing and shipping cross-platform software written in C++. Claiming that it's "nearly impossible" doesn't change the fact that we've been doing it for years. The one big area I can think of where portability is genuinely difficult is one the question didn't mention -- GUIs. GUI portability is a problem in all languages, unless you give up writing rich GUIs and write only simple and limited ones. Interestingly, despite some languages' attempts to "standardize" cross-platform GUI libraries, the best and most successful solution for cross-platform GUIs is not a code library at all, but HTML."
Well, that proves the point, doesn't it -- HTML + JavaScript is apparently a "language" that people find better suited to define standard, cross-platform GUIs in than C++!
The reason may very well be that C++ GUIs tend to they tie in to too many features of the underlying platform to be portable. If you
It seems that any language that uses a runtime (for HTML+JavaScript, that's the browser; for Java, that's the JVM; for Scheme, that's Emacs
Really, this is not exactly a mind-shattering concept (USCD-Pascal on p-Code anyone?)
Not that the current state of affairs with HTML+Javascript or Java gives much reason to feel content, but I *definitely* still see the point of having a runtime that offers a standard, special-purpose language to define GUIs.
However, I think the API for such a runtime should be viewed more as a data protocol than as a set of language-specific functions to call.
And *that* really applies to more than just GUIs: there really is a need for portable APIs that are not tied to any language these days, if you look at those complex, horrible 800lb monstrosities like Corba, COM or
Why not focus on *data-centric* APIs instead, that are intended to be put where the interface is as thin as possible, and build them as efficient and robust as an internet protocol should be?
If you're thinking of XML now, that may be close, but I really can't see how XML is the most efficient and easy-to-implement way of transmitting trees of attribute/value pairs. It's too difficult and slow to parse, to start using it as a transport for local subsystem calls as well, and contains too much redundancy, such as named close tags.
What the Internet and your local system needs is a good OSI layer 5. Is HTTP + XML really the best thing we can come up with?
All generalizations are false, including this one. (Mark Twain)