We can blame the bad code out there on the developers, no matter what paradigm it was developed under. For a lot of legacy ABL, the paradigm is probably best described as unimaginative cowboy, i.e., imitate what is there unless you feel like doing something else. For OOP languages, one can naively expect that the code would at least be a reflection of OOP principles, but that is rarely true. But, to blame the idea of OO on the travesties committed in its name is missing the point.
Stefan, I am glad you have found inspiration in Stepanov. I didn't. To me, it was details. E.g., the specifics of how and why around generics and templates to me are religious wars which get wrapped up in implementation while people forget what was underlying.
Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice http://www.cintegrity.com
> For a lot of legacy ABL, the paradigm is probably best described as unimaginative cowboy, i.e., imitate what is there unless you feel like doing something else.
> blame the idea of OO on the travesties committed in its name is missing the point.
That is not what Stepanov, Edsger Dijkstra etc. did, nor what I do.
> the specifics of how and why around generics and templates to me are religious wars
Demasking the oo abl hype, that's what I'm interested in, you could have concluded that by now from what I mailed. That's totally different from a religious war.
"OOABL" hype? Seems to me that OOABL has been crawling its way out of the muck rather than being hyped. It seems to me that, it is only in the last year or two that I see it being used with any kind of frequency and even a great deal of that is a limited use in the context of a procedural envelope. People advocating the use of OO form (note, for some of the concrete OO pluses like compile time type checking) are often mapping that form on to familiar procedural constructs, which might ease the transition for the new to OO programmer, but hardly results in good OO practice. Serious, rigorous OO is a rarity ... and often mocked.
We have different ideas of what OO means.
> We have different ideas of what OO means.
Who are "we"? You cannot have an idea of what I think oo means in any case.
Could be an interesting book of this Stepanov: "Elements of programming"
Think I'm going to buy this one (well, take a look at some more excerpts first).
Commercial: “The book contains some of the most beautiful code I have ever seen.
—Bjarne Stroustrup, Designer of C++"
Got to have a book of EDW also.
All a matter of taste, I suppose ... I certainly have never seen any C++ that I thought was beautiful. Now, TOOL, that was beautiful.
Then put aside your prejudices (pardon me, but you show tons of them in your reactions) and study that book. ;-) Doubtless there are more. You can improve your programming capabilities by studying books with examples in other languages. C++ has possibilities that progress does not have of course, in any case it's good to have knowlegde of those possibilities then. I learned some refactoring from Martin Fowler's Refactoring: Improving the Design of Existing Code. Examples in java. You won't find books on the art of programming with beautiful abl code.
Some discussion about how C++ moved on:
I stopped counting languages I have developed in when I got to 50 ... that was in the early 90s ... so I am well aware of the potential for cross fertilization. It is hard enough to find beautiful ABL code, much less books on it.
You won't find books on the art of programming with beautiful abl code.
So sue me. I've gotten lazy in my old age.
Friendships are discovered rather than made.~Harriet Beecher Stowe
pompiedom where is the deletebuttom
Ah, watch this one: Civilizing the Barbarians Lecture 1: Introduction www.youtube.com/watch
By that same C++ Stepanov.
Must watch for some here.