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.'"
Why not just do duck typing? (Score:3, Interesting)
Templates are what Python calls 'duck typing'. ("If it looks like a duck and quacks like a duck...") Why not just do that? You could add methods for introspection and so forth...
No need to dramatize (Score:5, Interesting)
I've seen a lot of people dramatize about concepts being removed from C++0x.
Really, it's no big deal. There are alternative solutions, like some based on SFINAE -- that has now been extended to arbitrary expressions --, that provide almost the same feature set, the same quality in error messages, and are not much harder or more verbose to write or use.
Actually, getting rid of concepts was probably the best solution for C++0x, since they were a lot of work to implement on top of not being that well polished, not integrating that well with the rest (concepts are not types, nor are they templates, they're a whole new category of things) which would probably have led to different categories of compliance to the new standard.
This even gives a new chance to more vital features, such as polymorphic lambdas (understand lambdas were the types of the arguments is not given and which thus exhibit parametric polymorphism), to now being reconsidered.
The feature C++ REALLY needs. (Score:1, Interesting)
If any one feature could ensure the continuation of C++ as a language it would be a standardized GUI library.
( i know I know, platform problems, implementation , the venders oppose it).
but when it comes right down to it. If C++ had a set of GUI libraries that were part of the standard and could be counted on to be in every compiler ( even if they didn't always look the quite the same). It would go a long way to providing something most developers need and want that can't be found in a lot of languages.
Re:Maybe the vendors don't want C++... (Score:2, Interesting)
I would be willing to bet that some vendors that make more than one language are probably not too crazy about doing more with an open language like C++. Not that I would make any association with a large software vendor founded in the 1970s that leveraged a pretty good BASIC interpreter into operating system and tools dominance... but
Yeah, Microsoft is so uninterested in C++ that for the Visual C++ 2010 release that they've added in a whole bunch of new features including partial support for this new standard.
Re:BIG need to dramatize (Score:5, Interesting)
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)).
Papering over the mold (Score:5, Interesting)
It's kind of sad. The C++ committee has taken the general position that the underlying defects of C++ should be papered over by making it possible to write templates that hide the problem. But the hiding never quite works; the mold always seeps through the wallpaper.
The root of the problem is that C and C++ backed into a type system. Originally, C barely had types at all; there were ints and there were floats. Pointers and ints were almost interchangeable. Fields in structures were just offsets, and field names had to be unique across all structures. Gradually, C evolved into a strongly typed language. Sort of. "void *" was introduced as a sort of escape hatch for the type system.
More importantly, there was never a clear distinction made between arrays and pointers. That single design decision is responsible for most of the buffer overflows in the world. We should have had syntax like
int read(int fd, char buf[n]&, size_t n);
to replace the old
int read(int fd, char *buf, size_t n);
which says nothing about the size of the array. Right there is the cause of most buffer overflows - the language doesn't properly support talking about the size of arrays.
Part of the problem there was a major error in the original design of C++ - it didn't have "&" references. So you couldn't talk about a reference to an array; you had to use a pointer to the first element. That pointer has the type of the element, not of an array. Every time you write "char *buf" instead of "char buf[n]&", you're lying to the compiler. The cost of that lie is millions of crashes a day.
Instead of fixing the mess underneath, C++ papered it over. Arrays were wrapped with classes in the Standard Template Library. The STL is a good thing, but it's not good enough to totally replace built-in arrays. So real-world programs remain a mixture of ambiguous built-in arrays, pointers to arrays, and STL arrays.
Then the STL approached iteration as an extension of pointer arithmetic. For "compatibility" with C pointer arithmetic, iterators are not only unchecked, but are not explicitly bound to the collection over which they iterate. So the safety problems of C were carried over into STL arrays. This was another bad decision. Most modern languages approach iteration by providing a "do this to all that stuff" construct used for most common iteration cases. C++ does not.
This is why I'm so critical of the C++ committee. If they'd focused on safety, instead of cool but obscure template features, software would be much better today.
Re:Really Unfortunate Initials (Score:1, Interesting)
Having had some exposure to Eiffel, I can safely say that Eiffel's generic implementation is intuitive and consistent. Constrained genericity was something that I was first introduced in Eiffel and it seemed to be quite natural for OO design. The simplicity of multiple inheritance and repeated inheritance makes efficient code reuse possible in Eiffel. With these contributions, I can tolerate some marketing messages from the creator. The downside being, it converts almost every eiffel programmer to an evangelist :-(, including yours truly.
Re:Really Unfortunate Initials (Score:2, Interesting)
What about this quote [slashdot.org] from Guido van Rossum?
Re:Really Unfortunate Initials (Score:3, Interesting)
Check out the history of the actual article. The comments should be read in context of that.
By the way, the "blue font" issue might need clarification as well - it's not that he tried to use blue just for the keywords, it's that he used blue as the base text color for all code snippets, including inline ones (as it's mandated by the "Eiffel methodology"). This just looked ugly [wikipedia.org], and caused confusion with hyperlinks, which is why most other editors of the article have supported not using blue text for code snippets. Meyer ignored that as well, insisted that Eiffel is an "all or nothing" thing, and therefore any Eiffel code should follow his conventions; and kept reverting any attempts to remove the blue highlighting.
Re:Why not just do duck typing? (Score:2, Interesting)
Well, either you believe in static typing, or you don't. If you do, Java is a good choice. If you don't, Ruby is a good choice. C++, on the other hand, is static enough to be annoying, but not static enough to be safe.
I actually much prefer Objective-C to C++. Once again, the worse solution won.
C++ jumped the shark a long time ago (Score:2, Interesting)
I've struggled with large C++ codebases on a number of different projects, and while I admit that it is a powerful language, the problem is that there are a half a dozen different ways to do things. The fact that they are trying to give the language even more expressive power is just adding to the amount of rope that we as developers can hang ourselves with.
I yearn for a language which is functionally complete, compiled, small, fast, cross-platform, and oh, NO TEMPLATES PLEASE! Templates/Generics are a blight (a blight I say!) on modern programming -- to say I was pissed when they added them to C# and Java was an understatement. I like my languages without too much syntactic sugar, thanks.
In general, OO programming was never fully grokked by the masses. People spent far too much time trying to make their objects re-usable, and not enough time solving the problem at hand. At least with a language like C you are not fooling yourself, you can write in a procedural style and be happy.
Don't get me wrong, C has a lot of short-comings as well. D is almost perfect, but again, the template blight has reared its ugly head.
I know, a lot of people love templates, and they will argue that they are faster, or they are safer because of type-safety. Faster? Maybe
Plus, you make the compiler work really hard, and your project now takes 40 minutes to compile instead of 5. Thanks for the productivity gains, but no thanks!
Re:Papering over the mold (Score:3, Interesting)
Fortran is a much older language than C++, and it supports variable sized arrays with known sizes in calling functions. It is also one of the few languages that are faster than C on supercomputer number crunching applications.
C++ should be several different languages, that can be compiled and linked together. The source files should have DEFCON levels to show how dangerous / fast they are.
DEFCON 5 - Peace. The most passive Java/Python/Scriptish code imaginable; run-time types; and built-in automatic memory management.
DEFCON 4 - Forces compile-time type checking.
DEFCON 3 - Adds Multi-processing / Cluster computing.
DEFCON 2 - Fast code; direct access to all member variables; none of the get/put call slowness; memory management is banned (no new or delete); and no aliased variables. Numerical code as fast as Fortran. Code automatically configured to work well with MPI / Cluster configurations.
DEFCON 1 - Pointers. Manual memory management.
With DEFCON levels on the source files, bugs can be contained to areas of code, and the class/optimization level of the code can become clearly visible.