Re: The world is not object oriented

[pg]

I am certainly not surprised to see people holding different views, and sometime could be quite different. The purpose of discussion is not try to uniform people's mind, but to expose the diversity.

I only read couple of lines here and there. Let me just pick on one thing I have read:

"First the trivial. Let's take something simple, like day and night. They are different, aren't they? Well, where do you divide the evening between them? "

My OO view is that, time is a class. It has certain properties like year, month, day, hour, minute, and second. Different point of time is just an instance of time, which holding particular property values. Day and night, or the line between them is unrelated here. There is nothing make me feel the need to perceive day as a class, and night as another class. or even day as an instance or night as another instance.

[tilly]

A famous philosopher believed that discussion progressed by starting with a thesis, confronting it with its antithesis. And then they mix into a synthesis. As much as I don't care for that philosopher's political philosophy, there is quite a bit of truth to the concept that the best way to expose people to diversity is to expose them to conflicting views. And interesting discussions frequently start with a significant disagreement, carefully explored.

Let's take your example a little further. Time is a class. A Time object has properties like "year", "month", "day", "hour", etc. What is the relationship then between Time and TimeZone? Does Time only have an hour in the context of a TimeZone? Or is the same split second in London a different Time than that split second in Los Angeles?

Going further, time is a more complex thing than your model holds. For a layman, this NY Times article doesn't do a bad job of explaining why. Attempting to produce a Time class that models the intricities of, say, metrics and varying versions of local time is very hard. Using such a beast is even more insane. Now for 99.9999% of the code out there (maybe more, maybe fewer 9's) the complications don't matter and it makes perfect sense to have a naive concept of Time. But for the fraction of a percent that does, you have a lot of fun waiting. An example in that fraction of a percent is the code used internally by the GPS satellites. (Did you know that GPS not only has to take into account corrections from Einstein's Special theory of Relativity, but also the general? Yup, the satellites are able to detect that their clocks run faster due to being farther out of the Earth's gravitational well!)

On misuse of the tool of OO design, my statement is not that I misuse the tool. It is that the tool simply has natural limitations. Typically those limitations don't prevent us from being able to do what we want (though they may complicate it). Rarely they do. Much more often, people who haven't yet learned a good balance between theory and practice create theoretical but impractical designs.

And finally I admit that if you limit your perceptions, you can shoehorn everything into an OO framework. I've seen people who seem to do this. I have no way to know whether you do - all that I can judge you by is what you write. However your post staked out an extreme position, and I certainly can critique the position that I understood your post to be making. This I have tried to do.

[seattlejohn]

Regarding the difficulty of providing a Time class that accurately captures all the real-world complexity (and at the risk of dragging this OT): Isn't that precisely the goal of the Perl DateTime Project?

I haven't had occasion to use the modules they've produced yet, but what I've read looks promising.

[tilly]

That seems to be trying to encapsulate the complexity of human representations of time.

That doesn't catch the sophistications to the physical descriptions of time added by special relativity, general relativity, or quantum mechanics. (It is rare in normal programming to encounters those, so the omission makes a lot of sense.)

[stvn]

I think pg makes an excellent point here.

Its all in the needs of your application. If your application requires that it uses a different style sheet for the web page based upon it being "day" or "night" in the users timezone, then your concepts of "day" and "night" are pretty clearly delineated. If your application requirements dictate that your user may be crossing time-zones while using it, your defintion of "day" and "night" is then much different, but still very modelable within OO. I find that OO better models "conceptual" objects than it models "real" objects.

To go back to the original example of day/night modeling, it is clear that you are running into the classic OOA/D trap of over-generalization and over-abstraction. Of course you cannot model the entire concept of day and night with OO, but you couldn't describe the concept adequately in natual lanaguage either (at least not on the level of detail needed in a computer system).

In the process of OOA/D you need to know when to stop abstracting things, or you end up with a giant mess of all too specific classes (which will actually make things worse and defeat the whole idea of OO in the first place). You also need to learn when to stop generalizing (which is very much like abstraction, maybe best to say a facet of the act of abstraction). If your classes are too general, you end up with more details/capabilties than you actually need, and again, you've defeated the benefits of OO.

Again, I will say, its just another tool. And like all tools, their usefulness is not so much an intrinsic property of the tool, but instead all in how you utilize the tool.

-stvn

[tilly]

Exactly.

In any kind of programming design, OO or otherwise, the goal is to find a good representation for your purposes. My point is that there often isn't an "obviously natural" representation just waiting to be noticed, and existing OO systems have to stop at partially expressing the full conceptualization that the programmer might have of the problem domain.

OO is one toolkit for producing useful representations. It is a useful one (else it would not have become so popular), but it is not the only one, and it is not always the right one.

[Anonymous Monk]

OO is one toolkit for producing useful representations. It is a useful one (else it would not have become so popular), but it is not the only one, and it is not always the right one.

If a tangent may be allowed here. I think discussing how OO can usefully model the problem space is the wrong angle. Very few problem spaces actually map directly or naturally to an OO model (simulation being one reasonable exception). OO has more to do with how we model our programs than how we model our problem space. Another way, OO is more about how we structure and manage our models, than about how we model.

[hardburn]

day and night could be viewed as another property of the time class or an assertion you could make against an instance of time, base on an artificial line between day and night.

I don't consider day and night to be artificial constructs, because nature does specific things during those times. For most bats, night is the time to wake up and start hunting, while it's time to go to sleep for a robin. The boarder between the two is fractal-like. If you can figure out the fractal's underlieing pattern, it should be easy to program your is_day and is_night methods, since fractal generators are surprisingly simple once you know the pattern. If you can't figure out the pattern, it'll be all but impossible without some artificial agreement.

[BrowserUk]

With the aid of a PC connected GPS, and some fairly well defined celestial mechanics math, determining the time of Sunset and Sunrise at any given location isn't that hard.

Though you would probably need a missile guidance system style local topology map to account for things like local mountain ranges etc. Depending where you live these may exist, but probably aren't avaiable to the general public.

Accounting for refraction and backscatter of light due to the atmosphere will be very difficult as it will be affected by the presence, type and hieght of cloud cover upto several hundred miles from the target location.

Given enough incentive, determining when the last vestiges of Sunlight will cease to fall on a given point on the earths surface would probably be possible, to a fairly high degree of accuracy.

However, whether this would difinitively capture the etheral notion of evening I doubt. What constitutes the start and end of evening is very much determined by a whole range of factors well beyond the scope of any form of mathematical formulea to define.

One example of these factors is social background: Different societies, and different groups of people within any given society, and even the age group of people can have an influence upon whether evening starts at 4pm, 6 pm or 8 pm or any point in between. Even once a computer calculated a specific point as the StartOfEvening, the percived accuracy of the determination would vary depending upon the audience, and may even vary with the same person according to a number of factors. Personally, Sunday Evening notionally starts later in the day -- as defined by my local time including artificial factors like daylight saving time -- than a work day evening. Likewise, evenings seem to start later, or the "afternoon" continues longer, when I am on holiday.

There are many concepts in the real world that do not lend themselves to being viewed as objects, nor even attributes of objects. The question then becomes one of:

Do these concepts have any place in computer programs?

We can represent colours within a computer program more accurately than most human eyes can differenciate between them, even with 24-bits. However, writing a computer program that could quantify any given colour as a "nice colour" would be extremely difficult. Or even a pair of colours as having a "good contrast" or as "complementary" in the fashion designer sense of the terms.

But then, what would be the purpose of having a computer program to do this? A computerised critique of the stars dress choices at red carpet parades?

For exactly the same reasons as it is difficult to produce a computer program to perform these tasks, anything said, or written, has to be taken in the context of where and when it was written. Taking individual words and phrases and ideas, expressed in one context and then considering their merits in isolation from the original context is fraught with problems.