OOP considered harmful (was: C. Date on UML book)

[Frank Carver]

Ilja: I don't get your point here - isn't code generation orthogonal to OOP?
Map: It is. Means that there are code generators that do not employ OOP concepts, as well as those that do. I happened to use one that didn't have any notion of OOP. My point was that in some cases other techniques can do the job without overhead of OOP.
This is a complete "straw man" argument. All the examples we are talking about here are eventually run on some sort of machine-code processor programmed in terms of registers, flags and jumps. I leave as an excercise a compiler for an abstract Turing machine
The issue here is not whether one paradigm can be implemented in terms of another, but whether one can provide any significant benefits to people programming in it natively.

[Mapraputa Is]

Frank wrote:
This is a complete "straw man" argument.
Now I did not get it. Which argument?
The issue here is not whether one paradigm can be implemented in terms of another, but whether one can provide any significant benefits to people programming in it natively.
Not sure with whom you argue, but in case it's me , I do not see how this contradict to what I said. Let's rephrase:
"The issue here is not whether one paradigm can be implemented in terms of another (was: "code generation techniques and OOP are orthogonal paradigms, so one can be implemented in terms of another or not) My point was that in some cases other techniques can do the job without overhead of OOP (i.e. provide significant benefits in cost-effective aspect)."
I did not stress "the issue here is not..." because it sounds rather extreme to me. Perhaps it's not exactly what you meant, but "whether one paradigm can be implemented in terms of another" can be read as "whether there are benefits in implementing one in terms of another" or, in other words, "whether they can complement each other". I was thinking about developing this line in some subsequent posts, but if we started to talk about it, I'll outline my vision here as underdeveloped as it is.
I think this is exactly the case with code generators and OOP. One thing I disliked about my template-generated code was that it dumbly copied and repeated 80-90% of "standard" code in each and every new module. If the code generator used OOP internally, it could output far less bloated modules. On the other hand, maybe it's simply a mark of bad design, I am not sure, but it looks to me that with OOP one has to write a good amount of redundant code (like get() and set() methods for each and every private fields, even if it doesn't do anything non-trivial). So here code generation techniques could benefit OOP (I suppose IDEs already use them).
Stuart Halloway's "Component Development for the Java Platform" has a very nice chapter on "Java and code generation" and the whole book can be downloaded from DevelopMentor site:
http://www.develop.com/devresources/DMSeries.aspx

[Mapraputa Is]

Ilja wrote:
As Larman puts it in Protected Variation: The Importance of Being Closed:
What a great article, thanks for the link!
This is what they should teach in Computer Science-1, instead of Java API!
"each generation of software developers needs help seeing mountains as mountains again —especially after four years of computer science and 500 patterns!"

"Novice developers tend toward brittle designs, and intermediates tend toward overly fancy and flexible generalized ones (in ways that never get used). Experts choose with insight — perhaps choosing a simple and brittle design whose cost of change is balanced against its likelihood."
Two " ", one for novice and one for intermediate. I would give three, but I am too far from an expert yet
"A good designer can identify the likely points of instability or variation and apply PV to those points but not others. Otherwise, effort is wasted and complexity may arise (and with it, the chance for defects)."
But this begs another question of paramount importance: who is this "good designer"? A programmer? To identify "the likely points of instability" he must possess a good understanding of domain, and this is not his area of competence!
"Components such as brokers and virtual machines are complex examples of indirection."
- forgot who said it, "any problem in computing can be solved by adding another level of indirection"
[ September 03, 2002: Message edited by: Mapraputa Is ]

[Mapraputa Is]

Well, for me "Constructs and arrangements that make your own mind happy may not do the same for other brains" implies "those that do not make your own mind happy may do so for others". And that doesn't seem to connect to "Its few, rare benefits there do not justify the added complexity" until you add an " - for me, at least".
Mm... If to meditate on these two sentences long enough, it *is* possible to combine them without contradiction, but I agree that it would sound better in your variant.
Well, my experience seems to be radically different from yours
Not really. I was talking about my experience in American college. My education in Russia was very different, and one thing I like about it (there is exactly one thing I like about it, no more ) is that they started from Assembler - at least some base to build knowledge on. Perhaps not the best, but at least something. Here in USA they learn products! They do not learn set theory - Ok, but they do not even properly learn SQL - they learn Oracle! They do not learn REST - Ok, they learn some HTML and then they move to FrontPage! This is very practical approach, I agree, and perhaps it helps students to find a job, or I would rather say, it used to help students to find a job, and that they do not see the forest for the trees - who cares...
BTW, I doubt that many of the current experienced OO advocates are influenced by the educational system in the way you describe - many of them are in software development for decades and I would be surprised if OOP was a main focus of their early education...
Experienced - no, but I got an impression that an average software developer isn't too experienced. I can be very wrong here, because I do not have any valid statistics.
How did we move from "your own mind" to "majority of developers out there"?
By the small word "might". It is a possibility, isn't it?
Well... Everything is possible if we add "the small word "might", but it would be nice to see some reasons behind such addition... This is an interesting question: how well programming language abstractions fit a human mind? I read a lot about "expressive power" and other math-related stuff, but nothing about whether it is "natural" for programmers to think in these abstractions or not. And the next point would be to find out whether some abstractions fit certain thinking styles and whether it is feasible to have several programming paradigms for no other reason but that they serve certain groups of programmers better.
Possibly.
What should we do about it?
Certainly - if distribution were connected to quality at all, Smalltalk would already have taken over the world...
This is another important question! Frankly, I do not know what we should do, I am trying to spread links about alternative POVs all around the Ranch, start discussions, review weird books etc. The marketing machine is doing its job anyway, but there is always some hope...

[Mapraputa Is]

Ilja wrote:
Ouch...
Well, it was some time ago...
So, does that mean that OO APIs are more complex than non-OO APIs providing the same functionality???
I suspect he is talking about "classes" and "constructors" as concepts, not their realizations.
Sorry, I don't get the meaning of this sentence..
Could be my bad translation. Um, how can I make it clear You can build almost anything out of cubes, because they are not specialized for anything particular. Now imagine that you do not have cubes, but instead rather sophisticated constructions made out of them. What can you build out of those "higher-order cubes"? Something ugly. Something wont fit.
"It is said that "Objects hide implementation complexity, yet they expose modeling complexity".
Who is saying that?
Let's see if I can find it... I was following links to links to links... Here it is: http://www.jot.fm/issues/issue_2002_07/column1
You seem to think that patterns are more about models than about practical code???
No, no, I was talking about building a domain model. Patterns I see as intermediate layer between a domain model and code, but I can be wrong, of course.
BTW, this is called the Dependency Inversion Principle.
Ah, I remember reading about it in
http://www.objectmentor.com/resources/articles/Principles_and_Patterns.PDF
Maybe we should make a page with links to particularly useful OOP resources? What do you think?

[Ilja Preuss]

Originally posted by Mapraputa Is:
[...] but I agree that it would sound better in your variant.

Well, thanks!

Well, my experience seems to be radically different from yours
Not really. I was talking about my experience in American college. My education in Russia was very different, and one thing I like about it (there is exactly one thing I like about it, no more ) is that they started from Assembler - at least some base to build knowledge on. Perhaps not the best, but at least something. Here in USA they learn products! They do not learn set theory - Ok, but they do not even properly learn SQL - they learn Oracle! They do not learn REST - Ok, they learn some HTML and then they move to FrontPage! This is very practical approach, I agree, and perhaps it helps students to find a job, or I would rather say, it used to help students to find a job, and that they do not see the forest for the trees - who cares...

Uh, and I thought our german colleges were bad... :roll:

BTW, I doubt that many of the current experienced OO advocates are influenced by the educational system in the way you describe - many of them are in software development for decades and I would be surprised if OOP was a main focus of their early education...
Experienced - no, but I got an impression that an average software developer isn't too experienced. I can be very wrong here, because I do not have any valid statistics.

I think I agree with you that many of the not-so-experienced developers are into OOP because of marketing hype. Nevertheless I think once you look through the hype, you will start to see the *real* values of OOP. So, rather than trying to keep someone from learning OOP, I'd try to educate him so that he is able to look through the hype, too...

Well... Everything is possible if we add "the small word "might", but it would be nice to see some reasons behind such addition...

I just wanted to question wether "Topmind" is in the position to determine wether OOP or the Relational Model is the better fit for most developers brains.

This is an interesting question: how well programming language abstractions fit a human mind? I read a lot about "expressive power" and other math-related stuff, but nothing about whether it is "natural" for programmers to think in these abstractions or not.

And the preceding question probably would be "what does 'natural' mean at all?". It seems to me as if much of what we refer to as 'natural' simply is what we are used to, or what we learned in our childhood.
"I don't travel by air. I travel as god has designated people to travel - by car."

Possibly.
What should we do about it?
Certainly - if distribution were connected to quality at all, Smalltalk would already have taken over the world...
This is another important question! Frankly, I do not know what we should do, I am trying to spread links about alternative POVs all around the Ranch, start discussions, review weird books etc. The marketing machine is doing its job anyway, but there is always some hope...

Sounds like a reasonable approach...
[ September 04, 2002: Message edited by: Ilja Preuss ]

[Mapraputa Is]

Some meta-observations before I go to bed
One unsolved problem of mine: I do not believe in being "reasonable=unemotional" even when we are talking about such abstract things as code Emotions have their value, and it wont do us any good to get rid of them. But on the other side, they have potential to distort/tunnel vision and to hamper discussion. For example, I passionately believe in a value of "objective" metrics, so when Ilja said "When emotional votes don't motivate you to try something which might make your life easier, it's your problem, not mine" I was almost mad. I do not know what kind of miracle it was, when later I was suddenly able to see things from his POV.

[Ilja Preuss]

Originally posted by Mapraputa Is:
[...] I passionately believe in a value of "objective" metrics, so when Ilja said "When emotional votes don't motivate you to try something which might make your life easier, it's your problem, not mine" I was almost mad.

Mhh, OTOH I would bet that you are making decisions without having "objective" metrics all the day. For example, how do decide wether to try a new parfait?
I think you simply have to accept that there are things you don't have metrics for (yet), so you have to make your decision based on the experiences of others and on good guesses. Of you might decide to not try new things if you don't have "objective" metrics suggesting that it would be rewarding, but I would question wether doing that regularly would be very usefull...
BTW, what metrics do you have about the applicability of the Relational Model?

I do not know what kind of miracle it was, when later I was suddenly able to see things from his POV.

Well, perhaps you are *still* mad...

[Frank Carver]

Here in USA they learn products! They do not learn set theory - Ok, but they do not even properly learn SQL - they learn Oracle! They do not learn REST - Ok, they learn some HTML and then they move to FrontPage!
Wow. That explains a lot.
My degree-level computer studies (way back in the '80s) were the opposite of this, and much closer to Map's "start from basic principles and build up" approach. We covered set theory, turing machines and computability, then worked up through assembler, Pascal, C and C++ via interpreter/compiler theory, general algorithms, relational database theory, functional programming etc. (with forays into Forth, Lisp, Awk and so on for practical experience)
I regret that we never covered a pure OO language like Smalltalk, but the whole thing was too new at the time.
By the time I discovered OO, I was ready for it, and found that it helped me think about problems and solutions in a new and useful way.

[Mapraputa Is]

To be honest, these were my observations in classes that are for 2-years degree. But then many students transfer to university and continue to work on 4 years degree, so I would not expect university programs to be radically different? At the best case, they start from products (more or less) and then move to theory? I know that "turing machines and computability" *are* studied in Universities, not sure if it's a requirement for all students or not.
Regarding "fundamental vs. practical education", there is a great article by F. Pascal "The myth of market-based education" Really explains a lot. :roll:
"So it is with education: it ends when it falls into the hands of moneyed incorporations. It becomes training at best or, to put a stop to independent, critical thinking, indoctrination at worst."

[Thomas Paul]

I'm looking at my Alma Mater to see all those practical computer classes. Here is the sequence for a CS major:
Introduction to Computer Science
Computer Programming I
Computer Programming II
Computer Organization
Computer Architecture
Discrete Structures
Data Structures
Database Management
Operating Systems
Compiler Design
Intro. to Computer Networks
Database Interfaces and Programming
Distributed Database Systems
Internet Programming Languages
There are electives for those interested in C or COBOL.

[Mapraputa Is]

Ilja wrote:
I think you simply have to accept that there are things you don't have metrics for (yet), so you have to make your decision based on the experiences of others and on good guesses. Of you might decide to not try new things if you don't have "objective" metrics suggesting that it would be rewarding, but I would question wether doing that regularly would be very usefull...
I can agree that "there are things you don't have metrics for (yet)" - from general considerations, but I very doubt software engineering is the field where those things grow in abundance. The explanation that we are simply unaware of such metrics looks more feasible.
BTW, what metrics do you have about the applicability of the Relational Model?
Applicability - it is an application of set theory and predicate logic to data management, so any fact that can be put in logically consistent form (atomic facts, most important) can be expressed. "What can be said at all can be said clearly" (Ludwig Wittgenstein).
But you probably mean other things, like easy of maintenance, extensibility etc. Do you really believe they cannot be measured? I would agree that such measurement isn't a programmer responsibility, don't we have researchers for this case? :roll: If I ever will have time, I'll read this book.
What is your educational background, by the way? Computer science? Something else? I am trying to figure out why this idea about "absence of metrics", "code smells" (brrrr...) etc. looks so appealing to you
Well, perhaps you are *still* mad...
Well. Not at you. But what *really* makes me mad is that currently there are three degrees of power in Computer Science: a feature can be
1) powerful
2) very powerful
3) incredible powerful
I am positively sure with some mental efforts we could produce a little more precise definitions

[Frank Carver]

Map wrote (to Ilja, really) : What is your educational background, by the way? Computer science? Something else? I am trying to figure out why this idea about "absence of metrics", "code smells" (brrrr...) etc. looks so appealing to you
I'll nip in, again.
I have always considered myself primarily a scientist (although maybe tending to more of an engineer, these days). For me, though, the reason things like "code smells" are attractive is that I have been burned too many times by inappropriate metrics.
With something wishy-washy, you have to talk about it and reach some sort of shared understanding. And I'd much rather be there than back with productivity measured in lines of code per day And, interestingly enough, the very vagueness of the "code smells" concept has led to an upsurge in academic study and practical tool building to try and bring the idea from alchemy to chemistry.

[Mapraputa Is]

Frank, you are always welcome!
Need to think on what you said...

[Mapraputa Is]

I became a little tired of this discussion and melancholically read through "Topmind's" anti-OOP papers when one of his sentences woke me up. That's just amazing! I did not want to tell it for not to worse already pretty inflammatory thread ( ), but this was the last straw! How can it be that OOP evokes precisely the same associations in me? He is talking about Church of Objects, and this exactly an impression I got from people's talking about their eyes opened or that one needs to experience OOP to be able to comprehend its virtues - all this reminds me James' "The Varieties of Religious Experience" book I read some time ago. (I do not want to offend anybody, and religious experience isn't necessarily bad thing...) He compares OOP to communism - again, exactly my thoughts! In fUSSR pure facts were never allowed to travel unconvoyed, they were always shipped with proper official interpretation - call it "methods"... Incapsulation, you know :roll: Sort of. He is talking about xenophobia - I called it "greediness"... Finally, today:
"OOP versions of multiple dispatching, such as the Visitor Pattern are usually a shameful mess. It is a Rube Goldberg contraption for what it allegedly does. I get a headache trying to figure out C++ or Java versions of Visitor."
He is doing it again! This is exactly what "patterns" remind me - Rube Goldberg pictures! I posted a link in MD forum some time ago, and it's still there, if you need proofs.
I am becoming more and more convinced that OOP and what he calls "table-oriented programming" are based on some very basic and incompatible traits of human mind. Otherwise how two persons of diametrically opposite backgrounds (he is supposedly from capitalistic, democratic, and rather religion-oriented country and me is communistic, totalitarian and gloomly atheistic) get 100% the same associations? Unless he also emigrated from some communistic country, but I doubt it.
I swear I did not have any prejudices against OOP, I love to learn new viewpoints, it's the first time when something inside me is deeply opposed to such new viewpoint and I cannot overcome it.

[Mapraputa Is]

Metrics: I am not advocating of total elimination of any subjectivity. Every programmer probably has inner feelings of how good/bad his program is written and this feeling is as important as any metrics. Then there is a notion of "beauty" which I am not eager to replace by some number.
But only subjective feelings are not enough. "subjective" and "objective" should work together and enhance each other! I stressed "objectivity" part because it seemed to me that Ilja's vision list to "subjectivity" too much, but this, in turn, can be nothing more than reaction to my posts, of course...
I read assorted articles on how statistical techniques were applied to literature work analysis, for example, and it was quite insightful Such an analysis can find regularity in what looked like plain chaos.
Then, if to think deeper, I do not believe in "objectivity" of "objective metrics" too much - they measure one aspect and miss or mismeasure (is there "mismeasure" word?) other, so the final picture is distorted anyway. "Subjective metrics" are probably more holistic and can even be more accurate when applied to the whole. Danger of "subjective metrics" is that they can catch us in trap of "self-evidence" - it's well known how people can see what they want to see and to be blind to what they do not want to see. And I am afraid that our tribe is a "risk group" in this respect - percent of introverts in programming is so high that introversion became a hallmark of programming. And introverts tend to have particularly decoupled relationships with reality

[Mapraputa Is]

There is a picture that can wonderfully illustrate what I was trying to say.
"Objective metrics" are projections, and "subjective metrics" are your point of view. Both can produce distorted image of reality.
Frank, have you seen "Weka"? "a collection of machine learning algorithms for solving real-world data mining problems" - I thought you may be interested.
[ September 08, 2002: Message edited by: Mapraputa Is ]

[Mapraputa Is]

Ilja wrote:
Of course we have still code left that is coupled to the data - but by encapsulating it in the same class, we made that coupling explicit. In a well designed OO system, changes to data structure should only affect the code of the class the data resides in.
Perhaps the main thing I cannot get is how the persistence mechanism (aka database) fits in this lovely OOP picture. If data were only kept in memory - then all the above would probably make sense. But they reside (typically, and for good reasons!) in a database. Domain (am I using the term right? By "domain" I mean what our application is going to model) was already modeled: entities (nouns) and relations between them were already captured in a data model. Why to model all this again, now with classes? It looks to me that a data model encompasses most fundamental = less likely to change aspects of domain. After you are done with modeling, data become "atomic facts". You can run queries against those "atomic facts" and 1) combine them in any unforeseen way to build more complex abstractions 2) infer logical implications that aren't explicitly coded.
Now how to reuse already built abstractions? I doubt that there is a radical difference between SQL and OOP languages. Essentially, the process is the same: modularization - increase granularity level 2) including a module 3) possibly overriding it with one you need - this mechanism works even for DTD. If the current version of SQL doesn't provide such a mechanism, it' very sad, but this is because the current version of SQL doesn't provide them, not because it is impossible.
And it look to me that SQL statements are easier to override, because they do not have "private variables", they do not have inner state, they are stateless. It's a "little language". "One spinoff of the UnixDesignPhilosophy was the realization that it is easier to implement a task-specific language optimized for that task than it is to implement a general-purpose language optimized for all possible uses."
http://c2.com/cgi/wiki?LittleLanguage

[Mapraputa Is]

This "topmind's" idea looks like a good explanation of my incompatibility with OOP:
"LISP came closer to the right idea by treating code like data instead of data like code, which is what OO does wrong."
This is my deep believe that data is more fundamental and far more important element of reality than code. When OOP marries these two it undeservedly equalizes them in rights.
With a data model we have a clear and relatively straightforward model of reality. "Entities", relations between them, "no entity without identity"... OOP's class structure is a mixture of entities from domain and OPP's own artifacts (aka patterns), which are nothing but implementation details. Why to mix these two
completely different fields?
Is anybody still interested in this discussion, or you all are already sick of it?

[Ilja Preuss]

Originally posted by Mapraputa Is:
This "topmind's" idea looks like a good explanation of my incompatibility with OOP:
"LISP came closer to the right idea by treating code like data instead of data like code, which is what OO does wrong."

How does OOP treat data like code???

This is my deep believe that data is more fundamental and far more important element of reality than code. When OOP marries these two it undeservedly equalizes them in rights.

1. I think you are reading way to much into OOP - it is simply a tool for decoupling.
2. According to your own interpretation, wouldn't LISP "undeservedly equalize them in rights", too?
3. It is my deep believe that programming has less to do with "correctly" modeling the reality, but rather with building usefull systems in an effective way...

With a data model we have a clear and relatively straightforward model of reality. "Entities", relations between them, "no entity without identity"...

Seems to me as if you had the same in OOP - with behaviour added to the entities.

OOP's class structure is a mixture of entities from domain and OPP's own artifacts (aka patterns), which are nothing but implementation details. Why to mix these two
completely different fields?

Doesn't normalizing a relational model introduce implementation details into the model, too?

[Ilja Preuss]

Originally posted by Mapraputa Is:
Now how to reuse already built abstractions? I doubt that there is a radical difference between SQL and OOP languages. Essentially, the process is the same: modularization - increase granularity level 2) including a module 3) possibly overriding it with one you need - this mechanism works even for DTD. If the current version of SQL doesn't provide such a mechanism, it' very sad, but this is because the current version of SQL doesn't provide them, not because it is impossible.

One very powerfull mechanism for decoupling - and therefore reusing - code seems to be polymorphism. Possibly you could introduce polymorphism into SQl - making it an OO language.

And it look to me that SQL statements are easier to override, because they do not have "private variables", they do not have inner state, they are stateless.

But they are depending on state of the data - they don't have "private variables" but instead are accessing "global variables". Most programmers experiences seem to imply that that makes a system *less* flexible.
[ September 09, 2002: Message edited by: Ilja Preuss ]

[Frank Carver]

Is anybody still interested in this discussion, or you all are already sick of it?
I'm still interested, but it's getting so deep that I have to think between posts (damn, that's bringing my posting rate right down )
Perhaps the main thing I cannot get is how the persistence mechanism (aka database) fits in this lovely OOP picture. If data were only kept in memory - then all the above would probably make sense. But they reside (typically, and for good reasons!) in a database.
Here we begin to see a difference in design approach. In many ways it's like the old argument between "top down" and "bottom up" which (as far as I can tell) has kind of faded away as people realized that you can start from wherever is appropriate.
Your paragraph, above, seems to imply that you assume from the start that your application will need persistent storage, and for "good reasons" this will be a database. I don't like to attribute things to other people, but this may be because of the types of system you have worked on in the past.
I've worked on a lot of systems where the most important thing is not the static data, but the transient behaviour and user experience (word processors, generic reporting tools, on-line calculators, web-site formatters/portals and so on.) All of these were useful applications, none used a database or a persistent data model.
For all of these applications, the most important data structures are in memory, and all that is needed by way of persistent storage is a few simple files.
I also have a strong background in simulation, where the most important thing is to have software which can reliably and understandably handle large numbers of instances of entities with complex behavior and interactions but little by way of persistent data.
For me, at least, OO techniques have provided a powerful tool to cut through these problems. I started with OO because of the simulation domain, where it is a natural fit. I then found that thinking in terms of objects and behavior helped simplify the complex internal data structures in something like a word-processor.
Eventually I reached the point I am at now, where (much as you "assume" a database will be useful), I "assume" that OO will be useful. Because it has been so useful in the past, and because it is a tool I have become comfortable with using.
Somtimes I find that I need persistence, but it's no big deal. Often just serializing something to a file now and then will do the job. Other times I might prefer something more fancy like a JavaSpace or a object database or (gasp!) even a relational database.
Why to model all this again, now with classes? It looks to me that a data model encompasses most fundamental = less likely to change aspects of domain. After you are done with modeling, data become "atomic facts". You can run queries against those "atomic facts" and 1) combine them in any unforeseen way to build more complex abstractions 2) infer logical implications that aren't explicitly coded.
Consider my word-processor example again. To me, spending a lot of time to come up with a relational model to persist the complex interrelated structure of text, graphics, images, markup and layout seems like a complete waste of time. The in-memory representation is the important one. The "persistence" requirement is more of an "export" to one or more serializations. The huge majority of persistance operations will be simple save/load, and in the occasional event of someone wanting to run soms sort of search or query against the text, it's easy enough to provide a searchable text-only "export" option.
I'm pretty sure that the two most used application types in the world are a word processor and a web browser (you can add the operating system, and web server too, if you like). I posit that none of these particularly benefit from a relational modelling exercise.
[ September 09, 2002: Message edited by: Frank Carver ]

[Ilja Preuss]

Originally posted by Mapraputa Is:
But you probably mean other things, like easy of maintenance, extensibility etc. Do you really believe they cannot be measured?

Let me rephrase my question: Based on which metrics did/would you decide to learn "Relational Programming"?

What is your educational background, by the way? Computer science? Something else?

Apprenticeship as precision mechanic (hands-on training was required by the planned study anyway, and I felt like doing the whole thing); two semesters of "technical environment protection" (the chemical practicum was like hell for me); almost pre-degree in "technical mathematics"; pre-degree in computer science. Than I realized that I was learning more at the job and by private investigation than at the university.

I am trying to figure out why this idea about "absence of metrics", "code smells" (brrrr...) etc. looks so appealing to you

Because it works perfectly for me.

Well, perhaps you are *still* mad...
Well. Not at you.

I know. But perhaps *like* me...

[Frank Carver]

He is talking about Church of Objects, and this exactly an impression I got from people's talking about their eyes opened or that one needs to experience OOP to be able to comprehend its virtues - all this reminds me James' "The Varieties of Religious Experience" book I read some time ago.
I don't wish to squash your personal epiphany, but I can't help feeling that this sort of analogy is common, whatever the opposing views. For me, trying to explain OO to people with a relational/procedural viewpoint feels like fighting the closed minds of an orthodox church.
Your own style of argument: (I exaggerate and distort, of course ) "The Pope (Date) has said that everything is a database, so why do we need these blasphemous objects as well" fits this model.
Debating whether or not an arbitrary OO program can be transformed into a procedural one (for example) is almost as pointless as debating how many angels can fit on the head of a pin. Yet discussions of this nature seem prone to such tangential offshoots as the participants struggle to find common ground.
He compares OOP to communism - again, exactly my thoughts!
For me, the paradigm of a large central database which carefully guards all the "facts", with real users' applications reduced to small peripheral programs (queries) which must conform to its structure and petition for resources from a sort of relational modellers "five-year plan" sounds more like Communism (or at least Stalinism)
May I gently suggest that religious/political analogies may be spurious (or at least inappropriate) in this context. I recently read a thoughtful article suggesting the limiting nature of all analogy when applied to computer issues. I'll try and remember where I saw it.
[ September 09, 2002: Message edited by: Frank Carver ]

[Mapraputa Is]

How does OOP treat data like code???
This is a very vague notion in me. I'll try to condense it into something more substantial and see whether it will evaporate in process
I think you are reading way to much into OOP - it is simply a tool for decoupling.
It's too broad a definition. As the paper you quoted brilliantly explains, "decoupling" (under various names) is the main idea behind all history of computing. The Relational Model can be described as "simply a tool for decoupling" too. If we are trying to compare different tools for decoupling, we need to lay out more distinctions here.
According to your own interpretation, wouldn't LISP "undeservedly equalize them in rights", too?
Good question! I do feel the difference, but once again, it's vague and I need to think more!
It is my deep believe that programming has less to do with "correctly" modeling the reality, but rather with building useful systems in an effective way...
I was thinking about database applications. Data are "model of reality" and incorrect model isn't very useful.
Doesn't normalizing a relational model introduce implementation details into the model, too?
No! This is a fundamental trait of relational model: it separates "logical model" (abstract view of data) from "physical" (implementation). This is an interesting point and I am going to develop it better, just wanted to let you know I do not ignore it

[Mapraputa Is]

One very powerful mechanism for decoupling - and therefore reusing - code seems to be polymorphism. Possibly you could introduce polymorphism into SQL - making it an OO language.
Well, you see the problem with vague terminology - perhaps it works for talking between your OOP types , but it is not good for foreign relations. You yourself already admitted that polymorphism isn't OOP monopoly! If we are going to use "OOP" to denote "everything that is good" then of course, any progress from now on will make everything OOP :roll: I am trying to figure what is OOP and what it is not, and even this simple task is so complicated!
Luca Cardelli. Bad Engineering Properties of Object-Oriented Languages":
"The object-oriented paradigm emerged in the 60's, roughly during the time that important notions such as data abstraction, polymorphism, and modularization were applied to the procedural paradigm. Eventually, object-oriented languages also acquired notions of data abstraction, polymorphism, and modularization, but not quite in the same way, and not quite as effectively."

There is certainly some convergence between OOP and non-OOP going on. C.Date wrote that his model now includes abstract data types and inheritance. On the other hand, "Topmind" claims that over time OOP becomes less of OOP and after reading Bloch' book I got the same idea. "It repeatedly seems that the features which make OOP unique are also the ones that cause the most problems." Perhaps "OOP" is too ill-defined term to be useful and we need to go one level down...
But they are depending on state of the data - they don't have "private variables" but instead are accessing "global variables". Most programmers experiences seem to imply that that makes a system *less* flexible.
Not sure what can serve as an analog of "global variables" in RM... If to restrict ourselves with querying operations only, then we can think about them as functions in functional programming: they return some data, and they are free of side effects. And they do not constitute Turing-complete language (at least, "orthodox" SQL doesn't), they are supposed to be embedded into a more powerful language, whether procedural or object-oriented. It seems to me that often OOP is trying to program data access that could be more easily expressed via relational operations

[Mapraputa Is]

Your paragraph, above, seems to imply that you assume from the start that your application will need persistent storage, and for "good reasons" this will be a database. I don't like to attribute things to other people, but this may be because of the types of system you have worked on in the past.
Sorry I said somewhere in this thread that I only question OOP applicability in the area where it overlaps with databases. I should have said it explicitly in my last post instead of expecting everybody to memorize all previous discussion. You are right regarding "the types of system you have worked on in the past" - and I wont say anything about applications that do not need persistence, probably OOP is a good fit there, in any case I have no idea about them. And "simulation" definitely looks like a perfect area for OOP applications. It's only boring business applications where OOP is a questionable tool.
I'm pretty sure that the two most used application types in the world are a word processor and a web browser (you can add the operating system, and web server too, if you like). I posit that none of these particularly benefit from a relational modeling exercise.
But they are accidentally most reusable pieces of software! How many programmers are now writing word processors and web browsers? I suspect that business applications (tied to some particular company) are more common task.

[Mapraputa Is]

Let me rephrase my question: Based on which metrics did/would you decide to learn "Relational Programming"?
None. It happened that my company used a relational database, so I had to learn it, then I even had "normalization of data model" as a topic for my diploma. I was young and stupid, I did not ask myself which model/paradigm/language is better for which tasks. Now I am old and um... yeah... In ANY case, I am interested in such comparison. I wouldn't insist on metrics that much but we do not seem do well without them.
"I find the p/r versions of the patterns are usually more intuitive, simpler, and more flexible than their OO counterparts. However, this may be purely subjective until solid, unbiased, metrics are devised."
Apprenticeship as precision mechanic (hands-on training was required by the planned study anyway, and I felt like doing the whole thing); two semesters of "technical environment protection" (the chemical practicum was like hell for me); almost pre-degree in "technical mathematics"; pre-degree in computer science. Than I realized that I was learning more at the job and by private investigation than at the university.
Then it shouldn't be too different. I asked, because my own "education" in math was almost totally useless but it somehow managed to affect my way of thinking. Or, maybe "preferences" rather than "way of thinking". "Everything that can be measured must be measured"
I know. But perhaps *like* me...
Ah, this is possible... No, really, who can seriously deny use of metrics? :roll:

[Mapraputa Is]

I don't wish to squash your personal epiphany, but I can't help feeling that this sort of analogy is common, whatever the opposing views. For me, trying to explain OO to people with a relational/procedural viewpoint feels like fighting the closed minds of an orthodox church.

Why, squashing my personal epiphany is good. I only cannot stand when people are mad at me, but if you want to squash any my personal belief/statement/epiphany and you enjoy the process, you are invited. This is one thing that I like about this place so much. First time, I remember, it wasn't fun at all when somebody caught me on an error. Now I have mixed feelings, and enjoyment is a substantial part of the mixture when somebody beats all my arguments. Maybe I am becoming a masochist
Since I exceeded smiles limit I continue in the next post...

[Mapraputa Is]

Your own style of argument: (I exaggerate and distort, of course) "The Pope (Date) has said that everything is a database, so why do we need these blasphemous objects as well" fits this model.
Mmm... I am naturally biased here, but I do not perceive my own style of argument as "religious", just a guarded and perhaps reluctant approach to something new when an old approach works Ok. Symmetrically, I understand if Ilja isn't particularly excited about the Relational Model and I wouldn't call it "religious fidelity to OOP" or something. What made me use this word is when he said few times that one needs to "experience" OOP to be able to understand it. I do not think this way about the Relational Model; of course, experience is important and one needs experience to become conversant with it, but the main postulates of RM can be perfectly understood by a bare brain - they are abstract, theoretical statements, after all.
The second moment when I had this impression was in another thread, when someone said "My eyes have been open" - again, I would not use such expressions. The opposite, when some concept apparently exhibits too much of explanatory power, then I feel guarded, chances are it's not a science.
Debating whether or not an arbitrary OO program can be transformed into a procedural one (for example) is almost as pointless as debating how many angels can fit on the head of a pin. Yet discussions of this nature seem prone to such tangential offshoots as the participants struggle to find common ground.
Our discussion *is* rather unstructured. Honestly, this is a surprise to me that we can hardly agree on anything. Particularly, debating "whether or not an arbitrary OO program can be transformed into a procedural one" isn't pointless to me. From "practical" point of view this is, of course, pointless, but if one wants to understand rather than use... The same Luca Cardelli:
"This is, in a sense, the problem of programming in object-oriented style within a typed procedural language. We show that this is possible in principle, given a sufficiently expressive procedural language, but we argue that this would be too inconvenient in practice. Therefore we find that the expressiveness of object-oriented languages cannot be emulated easily by procedural languages."
http://www.luca.demon.co.uk/TheoryOfObjects/Prologue.html
For me, the paradigm of a large central database which carefully guards all the "facts", with real users' applications reduced to small peripheral programs (queries) which must conform to its structure and petition for resources from a sort of relational modellers "five-year plan" sounds more like Communism (or at least Stalinism)
Gee, your picture definitely makes sense
May I gently suggest that religious/political analogies may be spurious (or at least inappropriate) in this context. I recently read a thoughtful article suggesting the limiting nature of all analogy when applied to computer issues. I'll try and remember where I saw it.
Must be Dijkstra's paper, you gave a link to Analogies: as always, it depends. They *can* be useful; after all, how can we learn something new if not through comparison to what we already know? Analogies link known and unknown by highlighting similarities of some aspects, but they do this at the expense of other aspects which perhaps have nothing in common. They are good at the first stages of learning, or to start discussion, then we should develop more elaborate and precise models. I think, Dijkstra was against anthropomorphic analogies where and when more "clarity and rigor" is appropriate.
I wasn't of too high opinion about each communism/church analogy taken separately, what stroke me was that our combined set of analogies was the same
Now, to contradict myself... Religious analogy: in my application it isn't even an analogy, I suspect what people feel about OOP and so-called "religious feelings" are the same, or at least they have a common root. This can be a wrong statement, of course, but it isn't an analogy.
Political analogies: can be useful if applied "up to isomorphism" If we are talking about "organization", for example, then "data organization" and "society organization" might share some patterns.
"Communism" analogy wasn't too instructional in "topmind" arrangement, I agree, and I didn't make it more meaningful either
---------------------------
P.S. Here is "Dijkstra" font in which the paper was written!

[Frank Carver]

How does OOP treat data like code???
This is a very vague notion in me. I'll try to condense it into something more substantial and see whether it will evaporate in process
I see what you are getting at, but I tend to view it in a slightly different way :- not that OOP trats data like code, but that it tries to decouple the distinction between code and data, so (viewing code as more flexible) recommends placing an isolating layer of code around the data.
This technique allows data to be replaced with code which generates it (typically to simplify the input data requirements for a process) or code to be replaced with pregenerated data (typically to improve performance).
Lisp, on the other hand, by explicitly treating code as data, has a different effect. A Lisp program can easily become dependent not only on the structure of the data, but on the structure of the program itself - the antithesis of decoupling!

[Ilja Preuss]

Originally posted by Frank Carver:
Lisp, on the other hand, by explicitly treating code as data, has a different effect. A Lisp program can easily become dependent not only on the structure of the data, but on the structure of the program itself - the antithesis of decoupling!

From all I know about Lisp, it is certainly possible to write such a program, but OTOH I suspect it wouldn't be so hard to encapsulate that knowledge about the structure in a way making it possible to use it without increasing coupling by an unreasonable amount.
Anyway I think this topic is totally orthogonal to OOP - after all the "Common Lisp Object System" seems to be rather popular.

[Mapraputa Is]

How does List treat code like data? I think, by allowing functions to be operands of other functions. It would be more accurate to say that Lisp treat data and code uniformly. How does OOP
treat data like code...
Frank wrote:
"not that OOP treats data like code, but that it tries to decouple the distinction between code and data, so (viewing code as more flexible) recommends placing an isolating layer of code around the data."
You mean to eliminate (at least from conceptual point of view) "distinction between code and data"? Functional languages have a radical solution for this problem - no distinction. Some OO languages emulate this.
From Ilja's paper "Protected Variation:The Importance of Being Closed":
"Uniform access
Languages such as Ada, Eiffel, and C# support a syntactic construct to express both a method and field access in the same way. For example, aCircle.radius might invoke a radius(): float method or directly refer to a public field, depending on the definition of the class. You can change public fields to access methods without changing the client code."
But this is only syntactic sugar, of course.
If the language doesn't support even this, then "placing an isolating layer of code around the data" does contribute to "OOP treats data like code".
Lisp, on the other hand, by explicitly treating code as data, has a different effect. A Lisp program can easily become dependent not only on the structure of the data, but on the structure of the program itself - the antithesis of decoupling!
Mmm... Perhaps it can, but I was amazed how all what I naively believed to be inherently OOP's features - Abstract Data Types, message passing, method dispatch can be much clearer and easily achieved in Lisp - with a half of page of code! And without any superfluous concepts: classes, objects, abstract classes etc. - only lists! If you have time, read this book: Structure and Interpretation of Computer Programs (actually, read it even if you do not have time. Only look at Amazon's reviews: they can make a book on their own
"terrific waste of time"
"This is one of the great classics of computer science."
"boring"
"after the class I burned this book".
"They use Scheme, a language of astonishing flexibility and uniformity"
"This book, and the Scheme language especially, is just horrible'
"The book is an entire CS curriculum compressed into a 1 semester course."
"Most difficult programming book I've ever read"
"Sure the book is challenging, but in the eyes of a computer nerd that's what makes this book so great"
"This book is to Computer Science what the Feynman Lecture notes are to physics: an introductory text that could reshape the mind of the average PdD. It's not about Lisp, it's not about Scheme, it's about computing at the most fundamental levels. If you're an experienced programmer, it will change your way of thinking forever. If you're a novice, it will set you down the right path. Read it and work through every problem. Repeat every few years."
(by the way, last time I read reviews, there were 85 of them, and now - 126! )
[ September 10, 2002: Message edited by: Mapraputa Is ]

[Mapraputa Is]

2.1 Introduction to Data Abstraction
"The basic idea of data abstraction is to structure the programs that are to use compound data objects so that they operate on "abstract data.'' That is, our programs should use data in such a way as to make no assumptions about the data that are not strictly necessary for performing the task at hand. At the same time, a "concrete'' data representation is defined independent of the programs that use the data. The interface between these two parts of our system will be a set of procedures, called selectors and constructors, that implement the abstract data in terms of the concrete representation."
2.4.3 Data-Directed Programming and Additivity
"What we need is a means for modularizing the system design even further. This is provided by the programming technique known as data-directed programming. To understand how data-directed programming works, begin with the observation that whenever we deal with a set of generic operations that are common to a set of different types we are, in effect, dealing with a two-dimensional table that contains the possible operations on one axis and the possible types on the other axis.
Data-directed programming is the technique of designing programs to work with such a table directly. Previously, we implemented the mechanism that interfaces the complex-arithmetic code with the two representation packages as a set of procedures that each perform an explicit dispatch on type. Here we will implement the interface as a single procedure that looks up the combination of the operation name and argument type in the table to find the correct procedure to apply, and then applies it to the contents of the argument. If we do this, then to add a new representation package to the system we need not change any existing procedures; we need only add new entries to the table."
Table-oriented programming!

[Ilja Preuss]

Originally posted by Mapraputa Is:
[QB]2.4.3 Data-Directed Programming and Additivity
"What we need is a means for modularizing the system design even further. This is provided by the programming technique known as data-directed programming. To understand how data-directed programming works, begin with the observation that whenever we deal with a set of generic operations that are common to a set of different types we are, in effect, dealing with a two-dimensional table that contains the possible operations on one axis and the possible types on the other axis.
Data-directed programming is the technique of designing programs to work with such a table directly. Previously, we implemented the mechanism that interfaces the complex-arithmetic code with the two representation packages as a set of procedures that each perform an explicit dispatch on type. Here we will implement the interface as a single procedure that looks up the combination of the operation name and argument type in the table to find the correct procedure to apply, and then applies it to the contents of the argument. If we do this, then to add a new representation package to the system we need not change any existing procedures; we need only add new entries to the table."
Table-oriented programming!

And that is *exactly* how polymorphism works in an OO language! It's just that the language disburdens you from handling with tables directly. So, if you write something like

foo.bar();

in an OO language, you are doing nothing more than telling the runtime environment "please look up the actual type of foo, than lookup the combination of that type and the bar method name in the jump table you generated, to determine which actual procedure to call".
So, if you look at it that way, OOP is just a very convenient way of table oriented programming!

[Ilja Preuss]

Originally posted by Mapraputa Is:
"placing an isolating layer of code around the data" does contribute to "OOP treats data like code".

I don't follow this reasoning - just because I speak to my parents through a telephone doesn't mean treating my parents like telephones, so it seems to me.

I was amazed how all what I naively believed to be inherently OOP's features - Abstract Data Types, message passing, method dispatch can be much clearer and easily achieved in Lisp - with a half of page of code! And without any superfluous concepts: classes, objects, abstract classes etc. - only lists!

Yes, those concepts are not much more than syntactic sugar. I didn't take a close look yet, but I guess that working that way, you will discover that there are certain tasks, snippets of code you are doing time and again. You might want to write some macros to simplify writing your table oriented programs. I suspect that you would probably come up with concepts that would strongly resemble classes and the like, building your own version of CLOS - an OO extension to LISP!

If you have time, read this book: Structure and Interpretation of Computer Programs

It's on my wishlist for some time - besides nearly hundred others. Sadly I only manage to read 1-2 a month... :roll:

[Ilja Preuss]

Originally posted by Mapraputa Is:
Symmetrically, I understand if Ilja isn't particularly excited about the Relational Model and I wouldn't call it "religious fidelity to OOP" or something. What made me use this word is when he said few times that one needs to "experience" OOP to be able to understand it.

I don't think I said exactly that. In fact I think you already *do* understand OOP to a reasonable extent. What I wanted to say is that you probably need to experience it to know *when, how and why it is usefull*.

The second moment when I had this impression was in another thread, when someone said "My eyes have been open" - again, I would not use such expressions.

Well, Kekul� had his eyes opened about the structure of benzol by dreaming about snakes. It seems as if the human brain sometimes just works this way - it needs some form of silly trigger to grok something...

The opposite, when some concept apparently exhibits too much of explanatory power, then I feel guarded, chances are it's not a science.

I don't think I know anyone who would say that OOP opened their eyes about how the world works, or the like - I know quite a few who would say that a specific experience opened their eyes for OOP, though. I am not sure wether you confused those two.

Analogies: as always, it depends. They *can* be useful; after all, how can we learn something new if not through comparison to what we already know?

I believe that analogies are a good way of getting new ideas - but the only reliable way to learn something is to test those ideas against reality. After all, that is how science works.

Now, to contradict myself... Religious analogy: in my application it isn't even an analogy, I suspect what people feel about OOP and so-called "religious feelings" are the same, or at least they have a common root. This can be a wrong statement, of course, but it isn't an analogy.

Well, there certainly *are* people who are so enthusiastic about OOP that they want everyone to "see the light". But I would ask you to not lump all OOP proponents together - in my experience, the more experienced ones are rather pragmatic about the virtues of there favorite paradigm. I hope I am...

[Frank Carver]

How does List treat code like data? I think, by allowing functions to be operands of other functions. It would be more accurate to say that Lisp treat data and code uniformly
Not quite. In Lisp (and several other languages and language groups) programs have direct access to the code (even the code which is running at the moment). Most programming dogma rejected self-modifying code a long time ago, yet it is often held up as one of the key features of Lisp.
Meanwhile, I remembered another couple of Alistair Cockburn's articles which I reckon are well worth reading in the context of this discussion. In particular, honestly try the exercises, then consider the designs he describes, and see how any natural tendency toward "data-driven" or "table-driven" design might fit in:
Object-Oriented Analysis and Design, Part 1
Object-Oriented Analysis and Design, Part 2
I despair sometimes that there are so many good articles, and so little time to read them.

[Thomas Paul]

Originally posted by Frank Carver:
Not quite. In Lisp (and several other languages and language groups) programs have direct access to the code (even the code which is running at the moment). Most programming dogma rejected self-modifying code a long time ago, yet it is often held up as one of the key features of Lisp.

Which is one of the reasons that Lisp is so popular in the AI world.

[Mapraputa Is]

Ilja wrote:
And that is *exactly* how polymorphism works in an OO language! It's just that the language disburdens you from handling with tables directly.
Hm. "disburdens"- and how does it achieve this? We still have to provide all needful information, right? So instead of saying things clearly and directly, we use a bunch of artificial concepts like classes, interfaces, or, worse, "polymorphism" and "inheritance"?
And regarding *exactly*, I am not sure. Java adds static type checking to the picture, but this may not be an inherent feature of OOP.
So, if you look at it that way, OOP is just a very convenient way of table oriented programming!
Sigh. I know it sounds that I am taking quotes out of context to mindlessly blame OOP, but I swear I do not specifically look for them! Today I was reading "lambda" weblog and saw a link to "Java Infrequently Answered Questions". I was intrigued what "Infrequently Answered Questions" means, I didn't know it has anything to do with OOP, but...
"The previous two questions show that a programmer needs to be very careful when extending a class, and sometimes just in using a class that extends another class. Problems like these two lead John Ousterhout to say "Implementation inheritance causes the same intertwining and brittleness that have been observed when goto statements are overused. As a result, OO systems often suffer from complexity and lack of reuse." (Scripting, IEEE Computer, March 1998) and Edsger Dijkstra to allegedly say "Object-oriented programming is an exceptionally bad idea which could only have originated in California." (from a collection of signature files). I don't think there's a general way to insure being safe, but there are a few things to be aware of..."
http://www.norvig.com/java-iaq.html#del
"just a very convenient way" - looks much worse than "goto" to me :roll:
I don't follow this reasoning - just because I speak to my parents through a telephone doesn't mean treating my parents like telephones, so it seems to me.
Unless you are in the same room! But I agree that "Lisp treats code like data and OOP treats data like code" - it isn't that simple :roll:
Yes, those concepts are not much more than syntactic sugar.
"To be more specific, it seems to me that the object world manages to introduce far too many distracting confusions and irrelevancies into a subject that (some might argue) is complicated enough already. Surely it would be better to avoid those confusions and irrelevancies and deal with a methodology in which the only complications are ones that are intrinsic to the topic under investigation?"
http://www.pgro.uk7.net/cjd4a.htm

It's on my wishlist for some time - besides nearly hundred others. Sadly I only manage to read 1-2 a month...
I understand What's on your wishlist, if it is not a secret? I am thinking how we can extend our bunkhouse, and publishing "wishlist" looks like an interesting idea...