Polymorphism sucks [Was: Paradigms which way to go?] [OOP]

From: Gerry Quinn on 20 Aug 2005 08:10

In article <1124460706.624778.297610(a)g47g2000cwa.googlegroups.com>,
Nicholls.Mark(a)mtvne.com says...

> I'm not sure I believe quantum mechanics, I certainly cannot comprehend
> it, and what people say about it, upsets my largely 19th century view
> of the universe.....well relativity isn't so bad, so circa 1920.

I think Feynman said that all of quantum mechanics is contained in the
double-slit experiment. The following page seems to explain it in good
detail, though I suspect the electron experiment is a simulated
experiment of the sort Feynman would not have approved. Also it does
not discuss the issue of local variable theories:

http://www.upscale.utoronto.ca/GeneralInterest/Harrison/DoubleSlit/Doub
leSlit.html

The following page goes into the key issues a bit more:

http://www.thekeyboard.org.uk/Quantum%20mechanics.htm

Those are two of the first pages I found in Google - I don't know
whether they are the best pages or not, but at a glance they don't seem
too bad and they go into a lot of detail. You may find more.

But anyway, understand the double-slit experiment, or at least know
what happens, and you'll know something about QM.

- Gerry Quinn

From: Gerry Quinn on 20 Aug 2005 08:12

From: topmind on 21 Aug 2005 00:02

Chris Sonnack wrote:
> topmind writes:
>
> > One *can* write hierarhical code in most event-oriented tools
> > similar to how one can write procedural code in most OOP languages
> > if so desired. I don't dispute that.
>
> You still don't seem to understand. If you have a program that
> does just about anything non-trivial, it will have a hierarchy
> of high-level routines that call medium-level routines that call
> low-level routines.

You just don't understand. Repeatly making the claim over and
over does not make it so. Hierarchies are MORE fragile at
a large scale because the real world is simply not tree-shaped.
Trees are for human convenience, not for modeling accuracy.

>
> If you dislike trees so much, think of it as an onion or strata
> in the earth. Put extremely, your main() routine may call your
> keyboard driver, but never vice-versa (in any sane program :-).

It is all a matter of perspective. A keyboard driver writer
may never see a main() either. They are two different issues
with a relatively thin interface between them.

>
> >> Are you under the impression that "event driven software" is JUST
> >> event handlers?
> >
> > Mostly event handlers.
>
> Ah, I think I see the problem. That just isn't so in any serious
> GUI program. I'd estimate that, AT BEST, it could get as high as
> 40% to 50%, but that's a rough guess and seems *high* to me.

Look at the web: it is the biggest "application" there is, and there
is no center. Thus, I see no evidence that scaling leads to trees.
Maybe YOU try to make things into trees, but bad habits can be
applied to anything.

>
> >> The larger the application, the more it does (besides handle various
> >> events). The more it does, the more it's going to be hierarchical.
> >
> > I don't see why this has to be or should be.
>
> Simple. As your own teeth-brushing example showed, any non-trivial
> task breaks into sub-tasks. Therefore, any algorithm of any complexity
> also breaks into sub-algorithms.

Not at a large scale. Besides, that toothbrush example was
for human analysis at the design stage. An actually implementation
may be less tree-like. For example, the actuals to remove the
toothpaste cap may be applicable to filling up a tire by
taking off the air cap, tuning a radio, etc. It is thus
referenced instead of a lone branch.

>
> PART OF GOOD SOFTWARE DESIGN IS DOING THAT BREAK DOWN.

Part of good software design is knowing when to stop
using trees.

>
> >> And you don't think there's start up **code** that sets things up?
> >> You don't think some events result in executing large bits of code?
> >
> > Maybe, maybe not. I don't rely heavily on "startup" events even if
> > they are possible.
>
> Well, once again, I'd have to opine that your lack of experience is
> showing. Let's consider a simple example. A highly event-driven
> GUI program that is spec'd as international.
>
> That means it needs to change all its labels before the user sees it.
> If you don't do that in start up, when will you?

But that is a "side task". The GUI designer generally is not worried
about how that happens. They are just told to allow enough room
for international labelling and may *not have to care* about what
happens
or how it happens at start-up.

Further, a better design may be to do it upon each screen start-up
instead of app load-up. Otherwise you get Java Hourglass syndrome.

Further 2, the startup is simply a task in a sequence, not hierarchy.
Saying sequence X comes before sequence Y is not inharently a tree
thing. Time is just another dimension, like X, Y, and Z space.

>
> When will you load the system configurations?
> When will you load the user's personal configuations?

Same thing.

>
> If a program needs to reference dropdown lists, and those lists are
> very static, isn't it smarter to preload them or preload arrays with
> the data for fast access later?

A sequence, not a hierarchy.

>
> >> Sometimes there's quite a lot of it, in fact. When I launch the
> >> WebSphere App Developer Studio, it takes a couple *minutes* to launch.
> >
> > Because Java and WebSphere suck.
>
> (Now there's an intelligent, adult opinion. Supported by fact, too!)
> ((Yeah, that was irony.))
>
> > Compiled languages often make it harder to load stuff as-needed,
> > forcing one to load everything into RAM up-front.
>
> What do compiled languages have to do with it? WebSphere takes so long
> to launch, because it sets up a lot of stuff then rather than later.
> Something I appreciate, actually. I can start it up and do something else
> for a couple minutes (grab a soda, whatever).
>
> Once booted, it works very slick and fast.

That seems to be the Java philosophy in general, sort of like a jammed
on-ramp but a

free-flowing highway.

> (And, FWIW, I think WebSphere
> is one of the nicest IDE's I've ever used. I believe something very much
> like it is freely available as "Eclipse".)
>
> >> Again, I'd bet you a year's salary the code behind the compile is
> >> hierarchically structured.
> >
> > It does not matter if the code behind it is girbles on a treadmill.
> > How to write compilers is not the topic here.
>
> But coding is, and writing compilers is coding. More to the point,
> it illustrates a point I'm trying to make clear to you. My clicking
> the "Build" button is an *event*. However the code behind that event
> is (1) considerable and (2) hierarchical.

Moot. You are probably wrong about compilers, but it does not matter.
What is good for domain X may not be good for domain Y. Please
stop talking about compiler design.

>
> Compile events are admittedly on the high end of the scale, but the
> point is that events can have a lot of code behind them, and that code
> will (almost certainly--if written well) be hierarchically structured.
>
>
> >> What's gotten lost here is your understanding of the context. What
> >> most of this has been about is the occurrence of trees in nature and
> >> programming. As *data* *structures*, they are natural and vital.
> >
> > Prove it.
>
> It's been proven over and over in these threads. If you can't see it,
> it's because you refuse to see it.

I must be "tree blind" because I don't see it. I see tree
fanatics forcing things into trees. But if I can
be blind and don't know it, then so could you. You are not
the reference point for humanity.

>
> Consider this, though. You've agreed several times that a tree *view*
> of data is useful--at least temporarily. How else would you contain
> the data of that view, if not in a tree-shaped data structure?

For certain things on a smallish scope I have no problem with
trees.

>
> For that matter, how would you represent a parse tree, HTML tree or
> XML tree in code?

HTML and XML are often poorly factored/normalized for that
very reason, repeating the same concepts over and over.

>
> > I don't give a flying slht about how to make
> > compilers and DB indexers. That is not what I
> > do for a living.
>
> Then why are you presuming to tell those of us that DO anything at all?
>
> Fine, consider a business application with a button that causes a database
> query, which returns data, which is parsed, written into a GUI grid for
> the user and also processed some more and put into a chart, which is popped
> up into a new window for the user. Possibly all done in separate threads
> to make the GUI as responsive as possible.
>
> I can only say this: If *I* wrote the code for that "event", you can bet
> your bottom dollar there'd be stratified layers of routines. In a word:
> hierarchical.

Fine. Present your code here and we shall see if that is the only or
best way to do it.

>
> > The duplication of the parse tree node detail is plain as the sky,
> > and you pretend it is not there or that it deserves some special
> > exemption such that your wrong view of the universe is kept intact.
> > Dup is dup.
>
> And ignorant is ignorant. You've already admitted you don't know
> about compilers, and it's clear you don't understand a parse tree
> DESPITE your having copy/pasted one into your last post. I'll try
> to make this clear once more:
>
> The parse tree represents the source.
>
> If an "if/else" statement appears in the source more than once, it
> **must** appear in the parse tree more than once. It's not possible
> to parse the code otherwise.

So. If repeated references to IF's or routines bust a tree, then
it busts a tree. That's (non-tree) life. Humans tend to ignore
the non-tree aspects to make their diagrams cleaner, but it is
still twisting reality.

>
> > Subroutine calls bust pure trees. That is the facts jacks.
>
> This has nothing to do with subroutine calls. THAT'S the facts.
> A call node in a parse tree is just another node.

Itsa *graph*.

>
> (You DO understand that no subroutine calls are made by the code
> while it is being parsed, don't you?)

The routines have to be parsed eventually. Just because it
*delays* working on the non-tree aspects does NOT mean
they don't exist.

>
>
> > Send me a parse tree from a real program, I will mark up the
> > dup links, scan it to the web, and the whole world can see what
> > a graph it really is.
>
> Pointless. It still hasn't sunk in that a parse tree (1) MUST
> contain duplicate nodes if the code uses a syntax element more
> than once, and (2) they are still perfect trees nevertheless.
>
> See, it's just your self-serving definition of "pure" tree that
> makes you think otherwise, and point blank, YOU ARE WRONG.
> NO definition of trees prohibits nodes with similar values.

By that argument *everything* is a tree because any
graph can be turned into a tree if we duplicate nodes
instead of "drawing" lines to the repeatedly referenced
thing.

This is why I made a distinction between pure trees
and proper trees. If we don't make that distinction
then this debate is pointless because both are
interchangable views of the same thing.

>
> Consider this trivial tree:
>
> root
> 42
> 42
>
> It's still a tree. A "pure" tree. It just happens that its two
> leaves contain the same value. Ten seconds later, it might look
> like this:
>
> root
> 42.5
> 21
>
> And it's still the same tree, but with different values.

It is all a matter of viewpoint. In fact a compiler/interpreter
may initially reference the same constant in memory to save
space. (I think I remember reading about such a compiler). Later, it
changes that reference when the value is changed. It is just
different ways to say/represent the same thing. One is not
inharently right or wrong, for they both can return the
right (expected) answer if implemented properly.

Functional programming fans (not to be confused with
procedural) often say one should view information
"changes" as creating a new one and discarding the
old one rather than view it as changing something
in place. In that view, there is no "changed data".
It is all a matter of perspective. One viewpoint
is not objectively right or wrong, at least as
far as producing the right answer. (Although performance
sometimes may be an issue, some argue the interpreter
can hide the difference.)

>
> Again, you need to distinguish between data trees and taxonomic trees.

Why?

> Duplication is not any sort of issue in data trees (unless the tree
> is *defined* as having no duplicate nodes, such as an index might be).
>

I am not sure of your point here.

>
> >> In fact, here's an example of hierarchy in event-handlers: In some
> >> systems, the main window receives events, which it may process and
> >> return as fully processed or pass on to a child element of the window.
> >> That child element may fully process the event OR pass it in turn to
> >> a child control.
> >>
> >> So there ya go--you're even wrong about events not being tree-shaped.
> >
> > I'm sure there are many ways to jury-rig event-driven tools to have
> > hierarchical features or flow if one is obsessed enough with trees.
>
> It's not a jury-rig, silly, it's a very appropriate design. Used by
> many GUI environments. It's very sensible, as it allows the programmer
> to put the event handling code exactly where it needs to be. (Is it
> clear to you that this is how the event-driven environment is DESIGNED
> and not some kludge by the programmer?)

You have an odd view of "event-driven". I pray to the dieties that
I don't have to work with your code.

>
> > In general, the "flow" in event-driven designs is determined by
> > actions of the *user*. The user may click in a tree-wise fashion
> > or may not.
>
> What??? What the *heck* is clicking in a "tree-wise fashion"?

If there is no such thing, then you are admitting to lack of
tree-ness in their actions.

>
> Apparently, you don't understand THIS example, either. Look, we're
> talking about a single click, by the user, somewhere in the window.
> I don't know if you even know this, but in some systems, if you click,
> say, a button that is in a frame in a window, the main window gets
> the event first (in Windows, the "message pump" gets it even before
> then).
>
> *IF* there's a handler there, it *MAY* choose to process the event
> and return. *OR* it may pass it on to the underlying control--in
> this case the frame.
>
> *IF* there's a handler there, it *MAY* choose to process the event
> and return. *OR* it may pass it on to the underlying control--now
> we're talking about the button.
>
> *IF* there's a handler there, it *MAY* choose to process the event
> and return. (*OR* not.)

How is this inharently hierarchical? IMO, there should be a
priority attribute to each event. Maybe the default priority
for a button will be lower than a frame, but it could be
purely tunable. I suppose some GUI's may hard-wire the priorities,
but that is one of many specific design decisions, and still
not necessarily a tree. Priorities by themselves are not
hierarchical.

>
> > The point is that the flow is not hard-wired into the code.
> > The more that is hard-wired, the less "event-driven" the design
> > is.
>
> Obviously, but that has nothing to do with this discussion other than
> to show you just aren't understanding a lot of what I'm saying.

Maybe not. All I know is that it appears to be bullshit.

>
>

-T-

From: Predictor on 22 Aug 2005 11:02

"Do you think fuzzy logic is implemented without binary?"

Binary implementation is not neccessary for fuzzy logic.

-Will Dwinnell
http://will.dwinnell.com

From: Willem on 22 Aug 2005 11:23

Predictor wrote:
) "Do you think fuzzy logic is implemented without binary?"
)
) Binary implementation is not neccessary for fuzzy logic.

But *implementation* of fuzzy logic implies discrete values,
and therefore applicability of binary.

SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

First | Prev | Next | Last
Pages: 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78
Next: Use Case Point Estimation