On Jan 14, 2008 8:06 PM, Christopher Smith <[EMAIL PROTECTED]> 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. > > When a language develops an entire book and vocabulary (Design Patterns) > > simply to deal with the deficiencies of the language, that's some > > pretty powerful evidence that the language is very broken. > I'm sorry, you just danced on my last nerve on this one. This is the > kind of willful ignorance that makes it hard to take people seriously. > > Let's review: > > - 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.
Did they really? I did plenty of Smalltalk for a professor in '92 during which I never heard or read the phrase "design pattern". Then in '93 all I heard about was "Design Patterns for C++". When I started digging into them I noticed immediately that many were simply not necessary in a language with dynamic binding, metaclasses, etc. You know, Smalltalk. I see from http://en.wikipedia.org/wiki/Design_pattern_(computer_science) they *did* have pre-C++ origins. But I agree with Andrew's take: the infamous design patterns and their individual vocabularies for C++ often existed to address C++ shortcomings. > - 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++. ;-) There are benefits to language level features over libraries. These include elegance, compile-time error checking, optimized code generation and using source code. One example is having OO built-in as opposed to "home brewing" your own flavor which requires more time and doesn't work with anyone else's code. Another example is the assert statement in Cobra: assert a.foo < b.foo When it fails, the AssertException will include the values of "a", "a.foo", "b" and "b.foo" which is a great aid to post-mortem troubleshooting. If "assert" were a library call, you'd end up writing: assert(a.foo < b.foo, "a=[a], a.foo=[a.foo], b=[b], b.foo=[b.foo]") for every freakin' assert(). Or you would skip it until that assertion failed. Maybe you can skip it if you're in an IDE with a debugger, but when your production code fails, it would be nice to have those values! > - 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. In many cases tackling > problems that don't exist in the C++ world. It probably wouldn't sell as > well as designed patterns, but I doubt any of the adherents would agree > that this is an indication of the failings of their language. The failing is that C++ design patterns often evoke an observation that in some other language X "that just works" or "that's two lines of code". -Chuck -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
