Christopher Smith wrote:
Andrew Lentvorski wrote:
Christopher Smith wrote:
There are quite a few languages that do everything C++ can do, and
they do it much better.
All evidence to the contrary aside....
What evidence to the contrary? Popularity? That's about all I can
think of.
Popularity and success. Those are difficult things for languages to
achieve, and one is foolish to dismiss them out of hand or fail to
appreciate the reasons as to why.
I don't dismiss them out of hand. C++ had a very large backward
compatibility advantage. The question is whether C++ owes its position
to being good or being first.
The trend suggests that it is because it was first:
http://www.tiobe.com/tpci.htm
While I have a few quibbles with the overall methodology of those
rankings, it's probably as good as any other.
The fact that Java and C are holding their places while C++ is losing
its place speaks volumes.
- Design patterns originated in the Smalltalk/OOPSLA community (indeed,
the very same folks as were involved in Agile methods and such), not the
C++ community. Perhaps this is evidence of deficiencies in Smalltalk and
object-oriented proramming in general, but nonetheless, this is where it
was developed and where it caught on.
Among the minority. And it escaped into the programming community at
large with C++ and the STL. And, in fact, several of the patterns
simply *do not apply* to Smalltalk--they *only* apply to C++ or similar
statically compiled, non-introspective, manual memory managed languages.
- The notion that one language is superior to another simply because one
can implement a design using native language keywords and operators
while the other must use a library is..... the kind of thinking that
leads to hideously complex syntaxes like... C++.
At no point did I talk about syntax or keywords.
I still maintain my point about design patterns being deficiencies of
the languages--that *includes* Smalltalk.
Many of the "object oriented" related patterns are about how to deal
with the deficiency of "single-dispatch" ie. all object functions have
an implicit first parameter of self/this/etc. This *does not exist* in
a language with proper multiple dispatch. (Note: Java also has this
deficiency)
Many of the "behavioral" patterns deal with the fact that the languages
do not have a clean delineation between counting, doing something to
each element of a collection, or unfolding tail recursion. This is a
deficiency of the language.
- One could write an entire book of design patterns for purely
functional languages (indeed, there are more than enough essays/white
papers on Haskell to assemble one right now), declarative languages,
scripting languages (Rails anyone? ;-), or whatever else is your
favourite pet programming language/style.
Yet nobody has. Or, if they do, they call it a "Cookbook" rather than
trying to foist it off as a great contribution to CS. Why?
Because these other languages are not as deeply deficient. For example,
I don't have to *think* about an Iterator to walk over every element in
a container in Python/Ruby/etc. If I have multiple dispatch, which I
can do if I can introspect, I don't have to build deep hierarchies of
responsibility. etc.
Looking back at the table of contents in my copy of Design Patterns I am
*amazed* at how little it applies to just about any language that anyone
considers a useful successor to C++ or Java.
Perhaps I should consider this a job well done by Design Patterns. The
patterns were so important that the newer languages integrated the
lessons so we can now operate at a higher level of abstraction. Of
course, if that is the case, that's even *more* of an argument that the
old languages need to be abandoned.
Unfortunately, constructors and destructors are excruciatingly
difficult to get right in the presence of exceptions. The fact that
that you have to pull out about 3 different books to get this right
says that something is broken.
Or perhaps that there is something that can be learned.... ;-)
Yes. Exceptions and manual memory management don't mix.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
