Bjarne Stroustrup On Concepts, C++0x 346
An anonymous reader writes "Danny Kalev has an interview with Bjarne Stroustrup about the failure of concepts, the technical issues of concepts, whether the ISO committee's days are over, and whether C++ is at a dead-end. 'I don't think that concepts were doomed to fail. Also, I don't think concepts were trying to fix many things or to transform C++ into an almost new language. They were introduced to do one thing: provide direct language support to the by-far dominant use of templates: generic programming. They were intended to allow direct expression of what people already state in comments, in design documents, and in documentation. Every well-designed template is written with a notion of what is required from its arguments. For good code, those requirements are documented (think of the standard's requirements tables). That is, today most templates are designed using an informal notion of concepts.'"
Re:Really Unfortunate Initials (Score:5, Insightful)
What's really unfortunate is that he's one of the very few language maintainers out there that isn't of the mentality "Rah rah! My language/tool/design-philosophy/whatever is the solution to all your problems and will take over the world tomorrow."
Care to actually provide the names of those other language maintainers, with appropriate citations, that make such claims?
Re:Really Unfortunate Initials (Score:1, Insightful)
WAIT A MINUTE THERE BUDDY!! Python is the best language ever! It will solve all your problems and take over the world tommorrow!!!
How dare you say ... oh ... wait, you were saying Python is that language.
Yeah, python is cool, isn't it?
Re:The feature C++ REALLY needs. (Score:3, Insightful)
There are plenty of features that I would say are a lot more important than a GUI framework. A standard way to convert C style FILE pointers into an iostream would be a great feature, one that several vendors already implement as extensions. Even a standard way to open a network connection and represent it as an iostream would be a good thing to have, with the heavy focus on network applications these days. Also, move allocators out of the template argument list for containers, and representing them as class members instead -- if ever there was a perfect case for preferring composition, it is this. Also, improved i18n/l10n support (C++ is better than C in this regard, but there is a lot that remains to be done).
Re:Really Unfortunate Initials (Score:3, Insightful)
You've never seen a Python coder, have you?
He said language maintainer, not language user. Care to quote the Python language maintainer(s) making such a claim?
Re:Really Unfortunate Initials (Score:1, Insightful)
What's really unfortunate is that he's one of the very few language maintainers out there that isn't of the mentality "Rah rah! My language/tool/design-philosophy/whatever is the solution to all your problems and will take over the world tomorrow."
Care to actually provide the names of those other language maintainers, with appropriate citations, that make such claims?
Very well. They don't out and out say that exact phrase but I'm sick of languages being marketed to me like an automobile. Here are a few after a bit of Googling. I don't really have time to dig more up:
Larry Wall of Perl: "Perl is designed to give you several ways to do anything, so consider picking the most readable one. " - From the Perl Man Pages
Yukihiro Matsumoto of Ruby: "Why should you switch to Ruby? If you are happy with Perl or Python, you don't have to. But if you do feel there must be a better language, Ruby may be your language of choice." and then "I believe people want to express themselves when they program. They don't want to fight with the language. Programming languages must feel natural to programmers." From an interview [linuxdevcenter.com]. It's hard not to roll my eyes when I hear about the latest flavor of the month. Ruby's marketed as 'the most natural.'
From Sun's about Java page [java.com] they claim, "Write powerful and efficient applications for mobile phones, remote processors, low-cost consumer products, and practically any other device with a digital heartbeat." As one of their reasons developers choose Java.
I'm surprised you aren't sick of languages being marketed to you as silver bullets that can solve all your problems. That's really all I see these days. No more are people considering a multitude of languages to be a toolbox you use to solve all kinds of problems but instead you see languages like Java being marketed for inappropriate things. It's like the inventor of C#, Anders Hejlsberg said, "The dream is to have a single programming model." I just don't believe that's a realistic dream.
If I were in their shoes, I would explicitly say what the language is but also explicitly say what it is not. As someone who's tried to do video analysis in Java, I've been down the "should not" path and wasted my time.
Re:Maybe the vendors don't want C++... (Score:3, Insightful)
as it is, I think C++ is pretty much dead as it is, and its' probably going to have to be up to gcc to just grab the bull by the horns and implement new features by fiat and create a defacto standard.
Well, that's how it used to be - the standards committee generally checks what all the major implementations implement that isn't specified by the standard, and then try to get the common non-standard parts into the next standard. Basically - see what the industry is doing, and if they all seem to agree then standardise it.
Re:Really Unfortunate Initials (Score:5, Insightful)
Re:Maybe the vendors don't want C++... (Score:5, Insightful)
C++ is far from dead in all piece of code that need performances. Intel released a C++ library called TBB to use multi-core architecture a few years ago. They do not believe it is dead. Parallel programming framework such as cilk stoped using C to use C++ to gain templates.
Don't get me wrong, for most task people don't care about the performance provided by a low level language and thus don't need it. It is even harmful to use C++ if you are not going to do it properly.
Re:The feature C++ REALLY needs. (Score:5, Insightful)
What on earth does a GUI have to do with a language? A GUI belongs in the C++ specification about as much as Java belongs in the kernel.
Each has its place and is used when necessary and shouldn't be forced into a place it doesn't belong for convenience.
Re:Why not just do duck typing? (Score:1, Insightful)
Sigh, someday I will get a language which satisfies my quite reasonable list of requirements for a decent language.
Like this [lolcode.com]?
Re:Concepts aren't enough! (Score:5, Insightful)
All that you want exists already, no need to wait 20 years - in fact, it was there already when you've started waiting! It's called Common Lisp.
It's the only language I know of where you can use its macro facility (reader macros, to be specific) to fully implement another language with arbitrary complex syntax. In other words, a program written in any textual language can be a Common Lisp program if you insert a corresponding CL reader macro definition at the beginning of the code.
Come to think of it, maybe the fact that it hasn't taken over the world yet has something to do with that...
Interviewer acted like an ass (Score:5, Insightful)
What are they supposed to say (Score:5, Insightful)
They are supposed to make the claim against the area for which their language is most appropriate. Although to be fair, it is often the people who are marketing the self-help books that tend to be the most vocal advocates of a particular language. I remember picking up an early O'Reilly book on Perl in a bookstore and reading the introduction and putting it back on the shelf in disgust because of the zealousness of the advocacy in the introduction.
I have also been down the "should not" path on several languages much to my chagrin. Fortunately, I've paid the price allowing me to spare my students the pain.
Re:Really Unfortunate Initials (Score:2, Insightful)
Wow. Calling out Matz of all language maintainers as one with a "rah rah" mentality really shows that you have no clue at all what you are talking about. I've read most of his posts on the Ruby mailing list throughout the past 9 years and I don't think you could find a worse example. At least pick someone like David Heinemeier Hansson -- the creator of Ruby on Rails and one of the most annoying self-marketers I've encountered in software development.
Re:Why not just do duck typing? (Score:5, Insightful)
Well, many type errors are discovered at compile time. Unfortunately, static typing tends to have the side effect of requiring more complex code, and often has to be worked around.
Personally, I write mostly in Java and Ruby. Java is pedantically static to a level that would make C++ blush, while Ruby is completely duck typed. I've had situations where Java's pedantic nature has caught bugs before test runs, but I've also had situations where the code was 10x as long and harder to debug because of the inflexibility. I think it's highly debatable which approach is better, and the answer probably depends on the kind of problem you're solving.
Re:Really Unfortunate Initials (Score:3, Insightful)
Larry Wall of Perl: "Perl is designed to give you several ways to do anything, so consider picking the most readable one. " - From the Perl Man Pages
Wait, wait, wait. You're seriously citing THAT as an example of (quoting from the GGP)
"Rah rah! My language/tool/design-philosophy/whatever is the solution to all your problems and will take over the world tomorrow."
?
The other examples are actually quite similar; Ruby says, in essence, "we think Ruby is good", and Java says, in essence, "Java is good". Nothing wrong with that - certainly it's not saying anything about other languages. In fact, in Ruby's case, it's explicitely said that if other languages work for you, then by all means continue using them.
But Perl? You're even crazier there. Larry isn't even saying "Perl is good"; in fact, his quote could just as well have come from someone who does NOT like Perl but still wants to give some useful advice (advice that, one might add, is applicable to just about EVERY programming language).
If that's your idea of "rah rah take over the world!", then you must be from Bizarro World - you're not even wrong.
C++: even iostream is doing it wrong (Score:4, Insightful)
It is even harmful to use C++ if you are not going to do it properly.
For example:
Re:C++0x? (Score:4, Insightful)
Hehe, it does seem a pretty good symbol of C++'s syntax: bits of syntax that make sense individually turning into a monstrosity when combined.
Re:Why not just do duck typing? (Score:3, Insightful)
Only since Python and particularly Ruby fans started using it as a way to market a feature in their pet language (dynamic typing coupled with dynamic dispatch) that's been available in existing languages for *many* years. It's a marketing term, nothing more. It adds nothing to the actual discussion, other than to sound all neat and cutsey.
Standardized terminology adds quite a lot to any discussion.
And I would define it as dynamic typing and binding. Nothing more. The language determines, at run time, how to bind a method call to an object. It's just that simple.
What do you call what Ocaml does?
Templates, on the other hand, are realized at compile time.
C++ templates are a turing-complete functional programming language, and are executed by the compiler. What you think of as "compile time" is the same as "runtime" for the templates.
What I should've said is that duck typing == dynamic dispatch + dynamic typing. Either way, it's hardly a new idea. And it's an idea that does *not* fit in a language that's meant to be strongly, statically typed (eg, C++).
The principle of duck typing says that you shouldn't care what type of object you have - just whether or not you can do the required action with your object. [voidspace.org.uk]
CeePlusPlus: Templates can create compile-time polymorphism via DuckTyping (as used in AndreiAlexandrescu's ModernCeePlusPlusDesign as well as Microsoft's ActiveTemplateLibrary). [c2.com]
In computer programming, duck typing is a style of dynamic typing in which an object's current set of methods and properties determines the valid semantics, rather than its inheritance from a particular class or implementation of a specific interface. [...]"when I see a bird that walks like a duck and swims like a duck and quacks like a duck, I call that bird a duck." [wikipedia.org]
Duck typing does not require dynamic dispatch, and does not (strictly) require dynamic typing. All it requires is that what matters is "I have a multiply() method" rather than "I am a number".
Re:Papering over the mold (Score:2, Insightful)
I guess buffer overflows are a feature too then.
Re:Papering over the mold (Score:1, Insightful)
DO WANT array bound limiting built into the language.
DO NOT WANT static-size arrays.
DO NOT WANT bound checking overhead at runtime.
That's the problem. It's a tradeoff between speed, space, and bullet-proof code.
operator= versus operator== (Score:3, Insightful)
Uncluttered article [devx.com], without any extra crap and multiple pages. Printable == readable.
There fixed that for you.
You know, this tends to bug me a bit...
I mean, yeah, here we are talking about C++ in which "=" means assignment and "==" means an equality test... But the world at large is not governed by these definitions. An equation like "y = 3*x + 4" establishes a relationship in which the two sides of the equation are equal.
If you want to apply the meanings of C operators to English text, then really neither meaning is correct:
"Printable = Readable" - means "Henceforth, until further notice, 'Printable' will have the value that 'Readable' has now" (Assignment)
"Printable == Readable" - means "I want to know if 'Printable' and 'Readable' have the same value". (It's an equality test, not an equality assertion)
Re:Really Unfortunate Initials (Score:5, Insightful)
It's well designed
I would disagree. Anonymous inner classes are clearly a hack necessitated by a lack of first-class function types. Lack of a more concise capturing mechanism (i.e. true lambdas) is crippling. There's nothing in the language to help solve, or even warn about, the brittle base class problem (@Override is one piece of the puzzle, but more are needed to solve it - see C# for a proper take on this problem, and API versioning in general). Type-erasing generics are one huge hack (I don't care about perf, but they are simply not first-class, and not fully typesafe - consider `instanceof` for a generic interface). Etc.
and efficient - so much so that you can implement other languages in it, to speed them up significantly.
Can you give any example of something being sped up significantly by reimplementing it in Java?
C/C++, ASM, and Java are basically the big three that everything is built on top of. Many people would be shocked that an interpreted language could make the cut.
I wouldn't be shocked, as Java isn't an interpreted language. JIT compiler still produces native code. And back when there was no JIT, Java was slow.
Re:BIG need to dramatize (Score:3, Insightful)
I think you're overstating things a bit. It's certainly true that Concepts would have been an improvement, and would have made life a whole lot easier for a whole lot of people -- but let's face it, "renaissance" implies that we're currently in a dark age, and that's overstating things quite a bit. Point one, there's pretty substantial work being done right now. Point two, concepts are not going to allow an average programmer to just decide that they're going to recreate something like Spirit or Proto or Xpressive this afternoon, or anything like that.
:-)
I also the think "petty politics" is going overboard, at best. Howard Hinnant seems to have been the one who started the discussion at the last meeting that ultimately led to the removal of concepts from the draft standard -- and I find an accusation of his being involved with petty politics completely unbelievable. Quite the contrary, the (admittedly few) times I've talked with him, he struck me as a very level-headed person who was careful to evaluate ideas on their merits. Likewise, Beman Dawes, Bjarne himself, and (since you brought him up) Dave Abrahams don't seem to me exactly "petty politics" kinds of people either.
I'd also note that when it came to a vote, the overwhelming majority of committee members voted to remove them -- including (for one example) Douglas Gregor, the primary author of ConceptGCC, and one of the coauthors of both N1758 [open-std.org] and N1849 [open-std.org] (the two versions of the Indiana Proposal).
I think the vast majority of the committee simply believed that including concepts would delay the standard by a minimum of a couple years, and probably longer than that. A fair number of features originally intended to be included in C++0x have been removed for exactly the same reason, though quite a few others have localized enough effects that they're currently scheduled for a TR (Technical Report) rather than waiting for the next major update to the standard itself. Unfortunately, since they make fundamental changes to the type system, I don't think concepts can be added in the same way.
*(Dave - I mean that in the nicest sense... you've done a great job with Boost (oh, we need to jam again, too)).
I object your honor. Everybody knows a proper blues guitarist is short and fat, with black hair and a scraggly beard -- and this "Dave" is about as different from that as humanly possible!