Slashdot Mirror
Bjarne Stroustrup On Concepts, C++0x
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.'"
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?
No you need to calm down and thing about the previous designations of C and C++ standards: C++98, C99, etc. C++0x was intended to be a C++ standard released between 2000 and 2009; at this point, it looks like it is actually going to be released in 2010, and we'll all be calling it C++10.
Palm trees and 8
I don't think that they are. There is quite a good comparison on the wiki page. The main difference that springs to mind is that duck typing in Python is dynamic (resolved at runtime), where-as the type system in C++ is static (resolved at compile-time). That makes them very different beasts.
Slashdot: where don knuth is an idiot because he cant grasp the awesome power of php
Can't we just skip "concepts", and move straightaway to "meta-concepts"? After all, a "concept" is just a concept itself, so with meta-concepts we'll be able to define "concepts" recursively. Which doesn't sound like a win, until you realize then you can redefine concepts to fit your own idiosyncratic needs. Like how in my code, the first thing I always do is overload "+" to mean "*", and vice versa. I've always liked them the other way around, not sure why. Anyway, back on point: Concepts by itself is like the 4-blade razor, a lame, stupid half-measure. The real prize, the 360-dunk-off-the-free-throw-line, is 5 blades on a razor. I move we skip "concepts" and go for the big win. Those effeminate Python dorks will have no answer to this, they'll be stunned to see just how inferior they really are. Who's with me on this?
Broader point: I'm sick and tired of these language designers not giving us enough features. For the last 20 years I've been waiting for a language that will allow me to redefine keywords. If that too much to ask? What if I don't happen to like "for", or "while", or "return"? Do you people lack vision, or competence, or both? Second thing on my must-have list is a pre-pre-processor. I'm tired of writing all these header files all the time. I want a way to generate them programmatically, at compile time. A small embedded scripting language would do fine, just make sure it has templates and operator overloading and multiple inheritance, so I can stretch my legs and get comfy with it. Come on people, start earning your paychecks and get some of this stuff done!
What are those people supposed to say about their language? That it sucks? That user's shouldn't use it? None of those quotes imply anything that you are claiming. Those are just snippets telling people what the positives of using their languages is. In the case of Ruby the maintainer even says that if you are happy with Perl or Python that you shouldn't switch to Ruby. That's hardly a claim of "my language is the solution to all your problems and it's going to take over the world".
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.
- Michael T. Babcock (Yes, I blog)
It is a big deal. The two most important things concepts were going to do was make generic programming in C++ (1) explicit and (2) accessible.
Currently, generic programming in C++ is supported through a number of template meta-programming patterns and practices, most of which exist as Boost tribal knowledge - hail King Dave!* It is implicit in many library designs, but there is nothing enforcing it at the language level. If you're not familiar with the concepts of generic programming (pun intended), it's easy to mistake what's going on in the standard libraries as something else. This is especially true if your primary use of the STL is to have polymorphic container classes - you might just design a generic extension to another language that completely misses the point of generic programming (see Java Generics).
At a more fundamental level, a lot of the power in generic programming comes from the specializations that are possible when you meet type requirements. Right now, there is no way, outside the documentation, to state requirements and possible specializations. Making this explicit in the language makes it clear to the library user what the requirements are and what specializations are available.
This leads into the accessibility problem. Generic Programming using template meta-programming is difficult. To use it, you have to understand both the template system and generic programming. The former is defined in the standard, but the latter, as mentioned above, is tribal knowledge. By making generic programming explicit in the language, it immediately becomes accessible to a large number of developers who didn't have the time, patience, or fortitude (dealing with the Boost mailing list requires a large supply of this) to become proficient with template-based generic programming.
As an analogy: consider object-oriented programming in C. Prior to (and even after) C++, lots of OO code was been developed in C. But, each object system was different and based on local best-practices. C++ (and Objective-C) took those practices and codified them into a language extension. As soon as that occurred, one method for OO was standardized. Developers no longer had to implement their own object systems and adhere to documented (but not language enforced) policies. And, with a standard set of rules around this flavor of OO, many other developers felt comfortable jumping in the the fray.
Concepts in C++ should have had the same effect for Generic Programming in C++ that C++ had for Object Oriented Programming in C. The should have democratized generic programming and brought forth a renaissance in C++ library design. Instead, petty politics killed the most exciting change to C-like languages in years.
-Chris
*(Dave - I mean that in the nicest sense... you've done a great job with Boost (oh, we need to jam again, too)).
The C+-* Language
* pronounced "C, more or less."
Unlike C++, C+- is a subject oriented language. Each C+- class instance known as a subject, holds hidden members, known as prejudices or undeclared preferences, which are impervious preferences, which are impervious to outside messages, as well as public members known as boasts or claims. The following C operators are overridden as shown:
C+- is a strongly typed language based on stereotyping and self-righteous logic. The Boolean variables TRUE and FALSE (known as constants in less realistic languages) are supplemented with CREDIBLE and DUBIOUS, which are fuzzier than Zadeh's traditional fuzzy categories. All Booleans can be declared with the modifiers strong and weak. Weak implication is said to "preserve deniability" and was added at the request of the D.O.D. to ensure compatability with future versions of Ada. Well-formed falsehoods (WFFs) are assignment-compatible with all Booleans. What-if and why-not interactions are aided by the special conditional evenifnot X then Y.
C+- supports information hiding and, among friend classes only, rumor sharing. Borrowing from the Eiffel lexicon, non-friend classes can be killed by arranging contracts. Note that friendships are intransitive, volatile, and non-Abelian.
Single and multiple inheritance mechanisms are implemented with random mutations. Disinheritance rules are covered by a complex probate protocol. In addition to base, derrived, virtual, and abstract classes, C+- supports gut classes. In certian locales, polygamous derivations and bastard classes are permitted. Elsewhere, loose coupling between classes is illegal, so the marriage and divorce operators may be needed:
Operator precedence rules can be suspended with the directive #pragma dwim, known as the "Do what I mean" pragma. ANSIfication will be firmly resisted. C+-'s slogan is "Be Your Own Standard."
http://baetzler.de/humor/c_more_or_less.html