Subj : Re: Polymorphism sucks [Was: Paradigms which way to go?] To : comp.programming,comp.object From : Chris Sonnack Date : Mon Aug 15 2005 08:06 pm 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. 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 :-). >> 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. >> 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. PART OF GOOD SOFTWARE DESIGN IS DOING THAT BREAK DOWN. >> 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? When will you load the system configurations? When will you load the user's personal configuations? 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? >> 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. (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. 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. 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 that matter, how would you represent a parse tree, HTML tree or XML tree in code? > 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. >> I don't think I'm losing this argument at all! In fact, I'm quite >> sure that, were it being judged purely on its debate points, you'd >> have lost it long ago. > > You are delusional. One of us certainly seems to be. I'm content to let history judge. > 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. > 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. (You DO understand that no subroutine calls are made by the code while it is being parsed, don't you?) > 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. 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. Again, you need to distinguish between data trees and taxonomic trees. 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). >> 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?) > 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"? 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.) > 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. -- |_ CJSonnack _____________| How's my programming? | |_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL | |_____________________________________________|_______________________| .