Polymorphism sucks [Was: Paradigms which way to go?]
in [OOP]
|
From: Dmitry A. Kazakov on 13 Aug 2005 04:43 On Fri, 12 Aug 2005 13:22:31 -0500, Chris Sonnack wrote: > Dmitry A. Kazakov writes: > >>> Do you think fuzzy logic is implemented without binary? >> >> Implemented is a wrong word here. Logic isn't implemented. > > Oh. So....er.... those fuzzy logic tools I was using a few years > ago.... were they grown from, like, seeds or raised from pups? (-: Ah, you meant to implement in the sense to use, to be based on. OK. >>> Multi-state logic is built on binary logic. Learn basic information >>> theory. It ALL can be broken down to 1s and 0s. Every, um, BIT of it. >> >> No, this is wrong. > > (Has anyone informed Shannon?) Hmm, was Shannon aware of Hilbert's program? I think he was. Anyway in the times after Goedel, we know that there is no way to "break" everything down to 1s and 0s. And even if there were one, neither fuzziness nor randomness can be expressed in a deterministic system without some incomputable elements. The simplest example is: you cannot write a non-pseudo random generator. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: topmind on 13 Aug 2005 05:03 [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 <Chris(a)Sonnack.com> _____________| How's my programming? | -T-
From: Chris Sonnack on 15 Aug 2005 12:35 Dmitry A. Kazakov writes: >>>> Multi-state logic is built on binary logic. Learn basic >>>> information theory. It ALL can be broken down to 1s and 0s. >>>> Every, um, BIT of it. >>> >>> No, this is wrong. >> >> (Has anyone informed Shannon?) > > Hmm, was Shannon aware of Hilbert's program? I think he was. > Anyway in the times after Goedel, we know that there is no > way to "break" everything down to 1s and 0s. Are we possibly talking about two different things here? Yes, Goedel showed we can't fully analyse any non-trivial system, but I believe Shannon hasn't been superceded in the sense that anything that *can* be expressed or computed can be expressed or computed in binary. > And even if there were one, neither fuzziness nor randomness > can be expressed in a deterministic system without some > incomputable elements. But they are incomputable by *any* means, right? > The simplest example is: you cannot write a non-pseudo random > generator. Agreed. -- |_ CJSonnack <Chris(a)Sonnack.com> _____________| How's my programming? | |_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL | |_____________________________________________|_______________________|
From: Chris Sonnack on 15 Aug 2005 13:29 topmind writes: >tm> If it has one table, it is still relational. >CS> (This, as stated, is *absolutely* incorrect, BTW.) >>> Prove it. >> >> Here's a table (first row headers): >> >> NAME UID COLOR DATE TYPE >> Alice - Blue 5-3-1948 BG45 >> Bob - Red 5-3-1948 XL220 >> Carol 3345 Red 12-7-1955 E30F >> Dave 7709 Green 9-14-2000 - > Note that "relations" (in a link sense) can be to the > same table, such as a table that can represent hierarchies: > [snip] They *can* be, yes. They can also *not* be. Your initial statement is incorrect *as* *stated*. >> I dispute your "relational==table" definition, so I see not >> one thing that makes this table "relational". It's just a >> (what I'd call) "flat table". > > Well, my definition is correct. The history of > "relational" is based on that usage. Then no doubt you can provide a reference beyond your mere assertion. Even the example you just provided seems to show that it takes a *relation* to be *relational*. >>>> http://en.wikipedia.org/wiki/Database_normalization >>> >>> I dispute that. >> >> Okay..... can you support that disputation in any way?? (Apparently not.) >> The line from that page, "In the relational model, formal >> methods exist for quantifying "how normalized" a database is," >> seems to suggest to me normalization is a fundamental part of >> a relational database. > > Normalization is simply duplication factoring. The principle > exists in just about every code or data organizational > principle. In other words, it cuts across paradigms. But has a very *specific* meaning in relational databases. >> But I do NOT see any relation to answering the question I asked. >> Can you answer it, or were you just throwing words out randomly? > > Sorry, but I lost the context of this section of discussion. No, you didn't. It was IN the post you're replying to. In fact, you quoted it in YOUR post. Here it is again: >You> However, there are different ways to interpret "duplication" for >You> empty cells. Empty cells do not have to take up physical space, >You> especially in "dynamic relational". >Me> Empty cells? Where did that come from? Are you talking about >Me> NULL fields? Row duplication?? What??? >>>> http://en.wikipedia.org/wiki/Relational_model >>>> >>>> It starts out, "The fundamental assumption of the relational >>>> model is that all data are represented as mathematical relations,..." >>>> ^^^^^^^^^ >>>> Sounds interconnected to me. >>> >>> Well, it is misleading. The same link also says: >>> >>> "A table is an accepted visual representation of a relation; a >>> tuple is similar to the concept of row." >> >> How, exactly, do you think that refutes the first quote? > > Maybe it doesn't. Either way it does not appear to support > your assertation that "relation" means cross-table references > in the context of relational. Don't create straw targets. I never said cross-table. But in the interest of moving this along, perhaps there is a problem of lack of precision in words here. By "interconnected" I mean one record referring to another via a foreign key link to a primary key in another record--which, yes, can be in the same table (*typically* not, but that's irrelevant). Where we may still disagree (?) is that, IMO, a "flat table", that is a table with no relationships, is NOT relational. Hence "table" != "relational" >> If the database moves to a different machine (with a different >> name, obviously), then no. The ODBC setup must be tweaked for >> the new hostname. > > The ODBC name is not the same thing as > a "machine name". It is essentially the name of > a configuration, a "reference" to a database (and usually a > locally-stored configuration). Yes. And **IN** that configuration is the machine name. If that changes, the configuration must change. >> You want to store files in a database. What happens when >> those files are very, very, very large? > > That is an implimentation detail. But a very significant one with regard to, um, implementing such a system in the real world. > I don't know what the upper limits are on the leading vendor's > products. Doesn't matter. What happens when I want to store the DB itself in your virtual file system? You can't store a full ten-gallon container inside another ten-gallon container, because there's no room for the container itself. >>>> Or consider this: in a FS, I can define a folder as publically >>>> shared, read-only, and any file I drop in there is available >>>> to those I've shared the folder to. I can casually share and >>>> unshare files just by moving them in and out of the folder. >> >> [...] >> Describe how you think an RDBMS would provide such a simple service. > > UPDATE folders SET shared=true WHERE [folder criteria] You've missed the point. This isn't about how to make a folder shared. It's about the ease of--once having a shared folder--dropping files, or copies of files, into that folder to share them. Or the ease of removing them, or deleting the copies, to unshare them. >>> Just because you are not adept at non-tree searches does not mean >>> the rest of us are also not. >> >> Okay, so describe how you would find Bob's old project files after >> Fred was done changing the attributes? > > How is this any worse than changing tree paths to represent > the newer changed information? Because, as I've said several times before, I can browse around the file system looking for likely folders. (I know this to be true, because I've done it!) I note that, in your reply, you didn't answer my question this time, either. I'll ask it again. Bob's gone, Fred hates him, so he's altered all Bob's attributes. How do you find the project file? -- |_ CJSonnack <Chris(a)Sonnack.com> _____________| How's my programming? | |_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL | |_____________________________________________|_______________________|
From: Chris Sonnack on 15 Aug 2005 20:06
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 <Chris(a)Sonnack.com> _____________| How's my programming? | |_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL | |_____________________________________________|_______________________| |