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:C++0x? (Score:5, Informative)
Re:C++0x? (Score:5, Informative)
It's named in parallel with language-revision names like Fortran77 and C99, that use the base language plus the last two digits of their revision year. When the process started years ago, though, they didn't know what year it would finish, but expected it to be in the 200x decade, hence "0x". So, C++0x. Now that the finalization has slipped past 2009, it's C++1x. When it actually comes out, it will have a year with no 'x', like C++10 or C++11.
Re:Why not just do duck typing? (Score:5, Informative)
I don't think that they are. There is quite a good comparison on the wiki [wikipedia.org] 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.
Uncluttered article (print = easy to read) (Score:5, Informative)
Re:Maybe the vendors don't want C++... (Score:4, Informative)
Do you realise that most of the guts of Windows is actually written in C++? And that the secretary of the C++ Standards Committe, Herb Sutter, works for Microsoft?
Are you even a C++ developer at all?
Re:Really Unfortunate Initials (Score:5, Informative)
Care to actually provide the names of those other language maintainers, with appropriate citations, that make such claims?
Few people remember this days, but Java was positioned that way back in late 1990s. I cannot find any reference because I don't remember the exact words, but I recall Scott McNealy saying something along the lines of "Now that you have Java, why would you write in anything else"?
Bertrand Meyer and his Eiffel programming language is another example. He isn't really stating directly that it's the best thing since sliced bread, but virtually all his papers on the matter read like aggressive advertisements, praising the virtues of Eiffel, and sniding other languages because they don't "see the light" in form of design-by-contract and command-query separation (conveniently ignoring the major flaws of Eiffel such as universal generic type covariance). He also edited Wikipedia article on Eiffel to match that, got extremely offended when other people have tweaked the article to remove self-promotion, and tried to "revoke" his GFDL'd contributions (read from here [wikipedia.org] on, and check the article history, for the full story of that drama).
Re:Maybe the vendors don't want C++... (Score:2, Informative)
Re:The feature C++ REALLY needs. (Score:2, Informative)
Qt 4.5 has been released LGPL. As long as you link to the Qt's dynamic libraries, you can completely close the rest of your app. Qt has become the standard cross-platform GUI framework for C++.
Re:Concepts aren't enough! (Score:3, Informative)
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"?
Unless my memory fails me, SNOBOL4 could do this 30 years ago.
Runtime vs. compile-time checking (Score:5, Informative)
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).
Compile-time checking has two purposes: enforce contracts between methods [wikipedia.org] and allow for optimization. I'll cover each of these in turn:
Dynamic languages have more overhead to dispatch a method call. But then static languages have to duplicate the template code for each type that it handles. It is disputed whether the more direct dispatch outweighs the overhead of loading the duplicated instructions into the CPU's instruction cache.
Types of arguments to methods make up part of a contract between a method and methods that call it. It's good to have a compiler that can verify some of a contract at compile time, but the halting problem implies that not all parts of all contracts can be expressed in a way that can a machine can verify. Fans of dynamic languages claim that purpose-written unit tests can verify contracts more thoroughly than a compiler's built-in checking, but fans of static languages claim that properly done static typing writes half the unit test for you.
Re:Why not just do duck typing? (Score:2, Informative)
Other people have said that that breaks C++'s static typing, but what they didn't say is that static typing is one of the explicit design goals of C++.
Some quotes from The Design and Evolution of C++:
"The importance of static type checking was also strongly emphasized. In other words, C++ follows the Simula rather than the Smalltalk model of inheritance and type checking."
"This delayed type-error detection [as present in Smalltalk or Python] was considered unacceptable for C++."
"However, the most fundamental reason for relying on statically checked interfaces was that I was -- as I still am [at least 1994] -- firmly convinced that a program composed out of statically type-checked parts is more likely to faithfully express a well-thought-out design than a program relying on weakly-typed interfaces or dynamically-checked interfaces."
Re:Runtime vs. compile-time checking (Score:4, Informative)
It is disputed whether the more direct dispatch outweighs the overhead of loading the duplicated instructions into the CPU's instruction cache.
Keep in mind that if you can statically determine what function is going to be called, you can potentially inline it. This is important for the stereotypical object-oriented designs where you have a lot of small functions (like getters and setters). This eliminates not just the function call overhead entirely, but will often enable other optimizations. (Of course, virtual functions make determining the function to be called hard or impossible in many cases.)
So it's not just the increased call overhead that dynamic languages have to deal with, it's the lack of ability to perform a bunch of other optimizations as well. Given C++ templates vs. a true interpreted language, I would wager C++ templates would win virtually every time, I-cache pressure and all.
However, not all is lost; JIT compilers start introducing a lot of the benefits from static typing back into the dynamic context once it decides to for-real compile part of the code. Once it does that, dynamic languages can pick up most of the benefits of the static language. (And my understanding is sometimes more, because the JIT compiler has some dynamic information while the static compiler has to make safe assumptions.) Of course, not all languages have true JIT compilers (e.g. Python (specifically CPython, the typical implementation) is bytecode-interpreted with no JIT compiler).
Re:Why not just do duck typing? (Score:1, Informative)
First, what you young bucks like to call 'duck typing', as cutesy as that sounds, the computing science world calls 'dynamic dispatch'.
That's not true.
First, 'duck typing' is actually a reasonably-standard term. I would define it as "the operations your object supports are not defined a priori". A language like Smalltalk or Python or Ruby doesn't have class definitions in the same way as Java and C++ do; instead, an object just has some methods, and if it supports the method you're trying to call it works, otherwise it fails. C++ templates are duck typing -- they're just compile-time duck typing. For instance:
This function imposes an interface on T: it needs to support a zero-argument bar function and operator+ with an int argument (or something int can be converted to), be it a member or free function. But there is nowhere that interface is actually specified; it's implicit in the function. For any type T that supports those two operations, you can instantiate foo with that type. This is what is meant by "if it looks like a duck and quacks like a duck, it's a duck."
By contrast, you can have dynamic dispatch in a statically-typed language. C++ does: virtual methods. Virtual method dispatch is dynamic dispatch, even if it's through a statically-defined interface that produces a vtable.
Re:Really Unfortunate Initials (Score:1, Informative)
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.
Try not to confuse programming language with programming model. The vast majority of programming nowadays follows the imperative model [wikipedia.org], but such programming is done in a variety of programming languages (C, C++, Java, Perl, Python). Furthermore, many programming languages borrow ideas from multiple programming models (e.g., C++).
Re:Papering over the mold (Score:4, Informative)
C++ is dangerous because it needs to be. There needs to be one high level language in the world that's like juggling operating chainsaws to code in it, because of the options that gives you.
Wrong. It's not essential that a language be unsafe to have low level constructs. Ada, Modula I/II/III, Clascal, Object Pascal, Eiffel, and other hard-compiled languages have been much safer than C++, with comparable power. You don't have to go to an interpretive environment to get safety. That's an illusion from Java, which was made interpretive because Sun wanted portability between their SPARC architecture and the competing Wintel systems.
Kudos: Indignation +1 (Score:3, Informative)
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."
Nice job quoting him out of sequence, and implying that his response regarding his guiding philosophy is even relevant to the question that's posed to him about switching. And also, nice job omitting the phrase "I tried to..." from his guiding philosophy. Since such a qualifier implies personal doubt that he even achieved such a goal, that doubt was endangered your thesis, so kudos removing it -- that makes his response (that you've already completely distorted by quoting out of sequence, and quoted from a totally different question then the one you've put before it) sound even more absolute.
Stewart: Did you have a guiding philosophy when designing Ruby?
Matz: Yes, it's called the "principle of least surprise." 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. I tried to make people enjoy programming and concentrate on the fun and creative part of programming when they use Ruby.
[...]
Stewart: Why should someone already familiar with Perl or Python switch to Ruby?
Matz: 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. Learning a new language is harmless. It gives you new ideas and insights. You don't have to switch, just learn and try it. You may find yourself comfortable enough with Ruby to decide to switch to it.
Re:The feature C++ REALLY needs. (Score:2, Informative)
Re:Why not just do duck typing? (Score:3, Informative)
I'm not the original poster, but many PL people would consider memory safety violations as breaking type safety. This includes buffer overruns, multiple frees, etc.
Er, you said it yourself - there's "type safety" and there's "memory safety". Those are two entirely orthogonal concepts, and I'm not aware of anyone who's into PL design (professionally or otherwise) who would mix those.
There's also an argument that the fact that you can even do unsafe casts means that C++ isn't fully type-safe.
Well, Java lets you do unsafe casts as well. Especially with generics (where such casts need not fail immediately), this can be an endless source of fun. Granted, Java at least doesn't say it's just U.B. to do so, but still.
In any case, the original post was (seemingly, at least) made more from a pragmatic perspective than from an academic one. With that in mind, consider that C#, for example, also has raw pointers with arithmetic and unsafe casts. I don't see how it makes it any more type-unsafe than Java for the end-user (i.e. your average developer).
Subscript checking is cheap if done right. (Score:3, Informative)
Now, we damn well know that, barring memory corruption or a serious bug in the STL, that this won't overrun the boundaries of the container. So why should i be range-checked ten million times?
It shouldn't. If the compiler, rather than the template library, knew about subscript checking, it could optimize much of it out. Most subscript checks in FOR loops can be hoisted [compilerop...ations.com] out of the loop. Only a single check at loop entry is required, and that may resolve to a constant expression which is always true, eliminating the test entirely. Most C compilers today know how to hoist expressions and do basic strength reduction [wikipedia.org]; that's why, for loops, pointer arithmetic and subscripts generate almost the same code in modern compilers.
But because the language doesn't know how big arrays are, the compiler can't help out here.
This is another price paid for papering over the problem with templates.
Re:Subscript checking is cheap if done right. (Score:3, Informative)
See Optimizing Array Bounds Checks Using Flow Analysis [kfupm.edu.sa]. The Java JVM does some array bounds checking optimization. C and C++ don't, because the language doesn't know how big arrays are. And millions suffer because of that.