Subj : Re: Polymorphism sucks [Was: Paradigms which way to go?] To : comp.programming,comp.object From : topmind Date : Sat Aug 13 2005 03:03 am [snipped 3 pointless insults] > > >> Let's recap. You claimed GUI software--note the term: SOFTWARE--was > >> not hierarchical. I showed you that it was. Then you shifted to talking > >> about GUI usage. > > > > I meant it from the point-of-view of the application developer, and > > not the builder of the tool ("boxed" software). If that was not > > clear, I apologize. > > Once, again, I understood and have been answering that way all along. > The code I showed you was a VB **application** I wrote. VB comes out > of the box. 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. However, just because an event-driven tool allows code or flow to be hierarchical does not make the code itself "event driven". Remember, we are mostly talking about technique here, not tools. > > >> Software--in general--is hierarchically structured. It has high-level > >> routines, mid-level routines and low-level routines. > > > > Not event-driven software (from custom app perspective), at least not > > on the large scale. > > Have you ever actually *written* a GUI application of any size? Are you > under the impression that "event driven software" is JUST event handlers? Mostly event handlers. There may be a few large tasks that resemble batch jobs in their structure, but the majority of the code is just handlers. > > 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. > > > The closest thing would be a start-up form, which simply has an attribute > > or reference somewhere marking it as the starting point. > > 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. Like I said before, which form is the startup form can be indicated by attributes or by code (such as a "main") routine. I don't remember which approach VB used, but it does not matter. VB allowed a mix of code styles, not just event-driven. > > 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. Compiled languages often make it harder to load stuff as-needed, forcing one to load everything into RAM up-front. > It's doing a LOT of set up stuff--all (I have no doubt) hierarchically > structured. When I compile all projects in the workspace, it can go > on for several minutes. 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. Just because domain A may use trees does not mean that all other domains should also. That is sloppy extrapolation. Compilers are mostly just "batch jobs", and thus usually will be more hierarhical than the app itself. > > 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. You have demonstrated that trees tend to be common for lower-level tools {systems software}, but there is still the extrapolation problem to other domains. The fact that you have to keep dipping into the systems software wine for examples raises domain suspicions with regard to your evidence. I don't give a flying slht about how to make compilers and DB indexers. That is not what I do for a living. > > As *taxonomical* structures, you can run into problems, and that's > where the idea of duplicate nodes or cross-branches can be an issue > (albeit, in programming, a solvable one). > > (I think you'd do better if you recognized how important and useful > trees are--particularly as data structures--and didn't try to do the > equivalent of claiming we never landed on the moon. Intelligent > people know we did and that trees do occur in many places in nature > and programming and are terribly useful. That you can only push > your own agenda at the expense of another is--in my book--an almost > certain sign of a kook and a fool.) How about you demonstrate them being universally useful instead of insulting me. Philosphers who have carefully pondered the nature of classification systems have come to conclusions fairly similar to mine. Most developers don't spend a lot of time pondering such stuff, but instead copy the techniques they find in "Learn Foo in 7 Days" books with little thought. Those who actually ponder the nature of structure, hierarchies, and change for a fair number of years will usually agree with me. Tree fans tend to hope that argument-from-authority is good enough. > > > >> Not at all, but it has nothing to do with parse trees. > > > > Then please clarify. I see no need to make a distinction > > between control structures and functions because in some > > languages that are the SAME thing. The other languages > > simply "hard-wire" them into the syntax or lang > > definition. > > Agreed with you last time. Once again, it has nothing to do with > (1) parse trees in general and (2) duplicate nodes in a parse tree, > which (3) IS A PURE TREE (no branches reconnect). by duplicating patterns instead of referencing them. > > >> It still looks like you don't know what a parse tree is, so no. > > > > Whenever you lose and argument, you seem to accuse me of ignorance. > > 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. 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. You cannot sweep it under the carpet and ONLY see the tree by ignoring non-tree links/dups. That is cheating, or perhaps evidence you change the picture to fit your world view instead of the other way around. ANY graph can be turned into a tree if dups/CBL's are allowed. Thus, treeing something in itself does not prove that trees are the best tool for managing information. Subroutine calls bust pure trees. That is the facts jacks. > > But regardless of that, I just plain think you ARE ignorant. The feeling is mutual. > > > Prove I am ignorant with details instead of claim it with vague > > accusations. > > The fact that you don't seem to recognize how badly you've lost this > debate or how often I have apparently overwhelmed you with techical > details ought to make it pretty plain that I HAVE proved it. 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. > > > > By the way, here is an example from c2.com wiki: > > Gee, you can copy and paste. Can you *discuss* what you pasted? > > Do you understand why (1) how an "if/else" is implemented is totally > irrelevant, or (2) why a parse tree is a pure tree? Any graph *can* be represented as a "proper tree", but not necessarily a "pure tree". A pure tree has no duplication of nodes or cross-branch links. Most syntax trees of real code are or can be proper trees, but they are usually NOT pure trees. > > > This code: > > [snip] > > Can be represented as a tree: > > [snip] > > Indeed it can. Do you understand what you pasted? By the way, I was the orginal author of that c2 content. > > > >> The code I showed you was developed (by me) as an APPLICATION. > >> As I said last time: > > > > Yes, but I asked for an *event driven* example. That is > > not event-driven, or at least is not the event-driven > > part of the code. > > And, in fact, as a medium-small-sized application, the event-driven > parts are not the bulk part of the application. I showed that to > you to counter your claim that GUI software was not hierarchical. *can be* versus *should be* were addressed above. > > It most certainly is. The event handlers may all exist at the same > level of the hierarchy (although this doesn't have to be true), but > they--if they contain much code at all--will be their own little > hierarchies. I have said many times that on a small scale there are indeed fairly "clean" hierarchies in most code. It is the bigger picture that is at issue. Trees are nice, or at least often acceptable, on the small. I have always agreed with that. > > 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. 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. 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. > > > -- > |_ CJSonnack _____________| How's my programming? | -T- .