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++."
No mention of IA64, or X86-64 =( I'm really curious to know if compilers will be in place to exploit these platforms, ESPECIALLY IA64.
-Berj
(hyperthreading, too?)
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.
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)
Interesting, then, that its history is so well-documented, and Stroustrup himself has written a whole book on how the language was designed, the rationale behind each feature that was, or was not, provided, and other historical reasoning behind decisions that were made. Where's the Java or C# equivalent?
Well, except for the currently-under-test Comeau compiler, which provides just about everything there is, and the internal code at MS, which is rumoured to support pretty much everything except export, anyway.
Y'know what? I really hope you're wrong. But unlike you, I'm going to justify my position.
Firstly, I work at a software development house, and on a MLOC C++ project. Our clients just hired a new whizzkid just like you. They provided all the latest tools, and he's come up with this really cool interface using C# and .NET. The only slight problem is that, unlike many other languages, he can't figure out how to use the 500,000 lines of rigorously tested mathematics we've accumulated over the past decade, so his code is utterly useless. Had he written in any number of other languages that were designed to communicate freely rather than locking you into a pet framework with much hype but little real support, he wouldn't just have cost them thousands of pounds for a cute but useless prototype. So, that's one thing where C# has a long way to go to catch C++.
There are many more. The obvious and boring example is templates and the standard library. Then there are all the portability issues, but I suppose they don't count because .NET and the CLR are portable and support many platforms, languages, days of the week, etc. There's the teensy-weensy little issue of performance, which is pretty much untested in C# and .NET as yet. Don't you think the Java developers might have learned a trick or two in the past few years? There's the insistence on everything being an object, single inheritance and a common root, all of which are as flawed as they have ever been. And in return we have what? A garbage collector? They could at least have learned from Java's mistakes and provided a decent mechanism for managing other resources -- which C++ has had for years -- but they seem to have forgotten that people also need to close files, release locks, share databases and such. I could go on, but what's the point? You're obviously massively prejudiced and unwilling to make the effort to get anything worthwhile out of C++, so why bother?
Oh, and bad programmers can blow their feet off in every language I've ever written. Still, at least in C++, good programmers can be great.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.