Top Mind

  if (x != 1) goto B:
  ....
  goto G
  B:
  if (x != 2) goto C:
  ....
  goto G
  C:
  if (x != 3) goto D:
  ....
  goto G
  D:
  if (x != 4) goto E:
  ....
  goto G
  E:
  ....  // "otherwise"
  G:

  select on x {
	case 1: {....}
	case 2: {....}
	case 3: {....}
	case 4: {....}
	otherwise: {....}
  }  // end select

. . .

Second, as the same information has to be involved in mutiple patterns, you still end up with a mess. The best solution is a relational database, not yet more overlapped goofy code patterns.

Relational is like code blocks and OO is like goto's: Spaghetti pointers. Goto's are just a big messy graph of flow, and OO is a big messy graph of relationship pointers.

• A fractured, desperate analogy if I've ever seen one.
  • I think it is a good one. Data pointers are data's version of goto's. PointersAreEvil. Goto's are one form, Navigational structures are another form.

Hi top, I am an expert in java (what I think). I have gone through the discussion on TOP as well as the tutorial. I want to know which basic constructs should be added to java and which one should be eliminated. Also give me justification for each. I have few in my mind and I am sure that I can defend that java with OOP in much better than java with TOP. (or it's worst to convert to TOP).

I find it hard to work with statically-typed languages and tables. Maybe there is a "static TOP" philosophy, but I have not persued/studies it much, preferring a dynamic approach. By the way, would your evidence work with say Python? If not, then is OO only better under static typing in your opinion? I suggest we clear up this issue before going further.

Response to claims made against me

• Ignores OO Evidence - It is repeatedly claimed by some that I ignore good OO evidence. If you have something that is good evidence, let's run it by other OO proponents to see if they agree it is ood evidence. If a majority of OO proponents seem to agree that the presented evidence is "good evidence of OO benefits" in or related to the domain of custom business software, I promise I will study it very closely. But, it does not sit well if you present evidence that even other OO proponents think is questionable, yet use that to conclude that I purposely ignore OO evidence or "don't get it". You can place any such candidate evidence in OoEmpiricalEvidence.

• Repeats his opinions over and over - A lot of people do this on wiki. It seems some of you tolerate duplication if it backs your viewpoint, but not if it doesn't. Why is the GoldenRule not applicable in this case? Also, part of the problem is that wiki lacks a document position marker cnvention similar to the "#" for URL's. (PageAnchor) It is tough to factor without a finer granularity. "See 38% of the way down on topic FooBar" is awkward and not sufficient over time as text changes. It is like requiring fewer functions, but that results in larger functions that do multiple things, which most agree is bad (there is a name for that which escapes me right now). Either I create more topics, which also generates complaints (see below), or I duplicate. I am stuck between a rock and a hard-place. I agree though that some of my writings should be cleaned up and better factored and that at times I have been slothful, but I am not alone in my sloth.

• Creates too many new topics - See above about the "#" problem.

• Is rude to other people - I strive hard to be diplomatic, and have improved with time. I have a personal rule not to shoot unless you shoot first, and shoot with equal counterforce rather than greater counterforce. I suppose the more noble approach is to never retaliate when someone else gets personal, but I find it hard to sit still while being ravaged. I believe it is rare that I have made personal attacks without first being attacked myself. If I do it often, I am honestly not aware of it.

• Is imprecise - I find my adversaries imprecise on many occasions also. Unfortunately, software engineering is a gray art, and thus lacks mathematical precision in many cases. It comes with the erritory. See DisciplineEnvy. However, a relational viewpoint offers more consistency than an OO viewpoint in my opinion. Most of my imprecision comes from dealing with limits of existing conventions and tools, not the base theory of relational-centric thinking.

• Thinks OO is only about trees - Often when I see somebody talking up the alleged benefits of trees, I give my opinion. However, some mistakenly take this to mean that I think OO is only about trees and inheritance. I never claimed it was. Note that some OO proponents do believe inheritance is OO's main selling point.

• Has only dealt with "simple" applications and thus is uninformed about "real" applications - This is covered just below and in DomainPissingMatch.

• Is against abstractions - I use plenty of abstractions. However, they tend to lite and local (See HelpersInsteadOfWrappers). Formal, grand abstractions turn out to be the problem.
  • { Is quite often a hypocrite - Tables are a large abstraction, wrapping several Cee calls (or other lower level code). For example, one could never easily use a table language to program a table language. Tables and databases are much higher level and much abstracted. Lite and local would be using a plain array, linked list, or associative arrays (even those are large abstractions - might one just use lite and local pointers to pointers? In fact, even pointers are abstractions. Darn dong dang it. Oh, I'll add that all scripting languages are large abstractions.)}
  • This seems to be based on a comment in PractitionersRejectFormalMethodsDiscussion. I'll let that topic address the issue. Also, I assumed the context was abstractions that us as developers (custom business applications) write and maintain, not those that come out of a pre-packaged box. Otherwise we'd also have to talk about AMD CPU chips, etc.

My impression of an OOP zealot: "I don't have to provide open evidence. If you were smart like me, you would just feeeeeeeel how good OO is in your bones." -- top

My impression of Top: "I'm smarter than all you ther programmers, even though I do very little advanced programming and mainly work with databases. It doesn't matter that a large majority of the best programmers in the industry feel OO has value, their opinions are worthless."

• What exactly is "advanced programming"? Sounds like a DomainPissingMatch.

• "Large majority"? I don't think so. Non-OO fans just get less press. Who would dare publish an article on procedural methodologies. It ain't sexy these days. A lot of shops I encounter are ambivalent toward OO. They like pre-packaged components, but don't write their own classes, or write them in a procedural style. There seems to be peer pressure to use more OO, as if it is like eating one's vegetables and brushing teeth before bed, but they just don't feel comfortable enough to go full-out with OO.

As you said top, it is a grey industry, no solid proof exists of just about anything, but the fact that so many people find OO of great value, either means it "is", or you're smarter than everyone else, my bet is the former!

• If it is all subjective, then it is not a matter of being "smarter". I can agree that it may indeed all be subjective. I have no problems facing that potential conclusion. But OO is pushed as an absolute truth, and those who question it are made to feel like Luddites.

• If I were super-smart, I could write everything in assembler. We wouldn't need complexity-management techniques because our powerful brains would just grok everything without the need for code organizational conventions. TOP is to help compensate for the weakness of the human mind, not the other way around. Part of TOP is about using a declarative approach so that one can transform and view information in a form one is more mentally comfortable with. If I had a mega brain, then I might not care what form info is presented in. Instead, I am mortal, so custom transformation helps my head.

• Even if your allegation was true, why does it other you that someone might think they were smarter? Studies suggest that most people have an inflated perception of themselves anyhow. It is human nature that is not going to change. I don't really mind if somebody thinks they are super-smart as long as they are willing to explain their thinking rather than just say, "trust me without explanation because I'm smart". I respect articulation, not claims of hidden brilliance. Intellectual "battles" are supposed to be how real geeks socialize. It is mind-sports. Fake geeks rely on ArgumentFromAuthority.

OO is currently being "marketed" as the end-all-be-all, and NOT Yet Another Paradigm.

That's what marketing people do, so what, they d that with everything.

How many "Learn Procedural Patterns in 21 Days" or "Learn Functional Patterns in 21 Days" books do you see at the bookstore compared to OO ones? I thought so.

Again, who care's what books are selling in the bookstores? If you think you have solutions then promote them, don't knock others, too many people have had positive experiences with OO, you aren't going to get anywhere trying to attack that juggernaught.

As far as me being "close minded", show me some kick-ass evidence, and I just may open it. Deal?

No deal, I'm not here to convince you of anything, that's your job. If you think your Table stuff is so cool, then put up or shut up. We're programmers, you have to show us, we aren't the marketing guys, and knocking OO will just get you ignored and ridiculed as usual. YOU WILL NOT EVER DISPLACE OO, so quit trying, instead, promote your own ideas without bashing OO, and we might just start to listen, until then, we won't.

Possibly in the wider software industry, which has always been very much hype-driven. But most people I know on Wiki are not wedded to OO. Costin, Doug, me, WilliamUnderwood, DanMuller, and several others have all contributed non-OOP ideas and examples to several pages. But we don't have to bash OO to do so.

People would be much more receptive to TableOrientedProgramming if you did not pit it in opposition to OO. Most of us, even partial TOP-supporters, have had positive experiences with OOP; we really don't care whether that's your experience or not, we want solutions that work for us. If you make us give up our objects to adopt tables, you aren't going to find much support. If you try to find ways to let objects and tables coexist, as Will and Dan and myself have all tried, you might just come up with something useful. -- JonathanTang

Perhaps you guys are not really the audience f my complaints. -- top

I, too, have put a lot of thought into the topic of synergistic coexistence; it's interesting, and the classic approach, e.g. that Java takes, clearly needs sharp improvement. -- DougMerritt

• What point are you making by pointing to that? -- dm
• Me neither. Who cares what happened 6 years ago anyhow. OO tends to force one to have to think more about a ram-disk dichotomy, that is all it seems to be saying. Perhaps my mistake there was implying "can't" instead of "more difficult". -- top

MeasuringAbstraction is another brain twister.

Somebody keeps promoting the myth that I claim that OO is about only about hierarchies. It is not true. I correct them, but they never seem to read the corrections. Without trees OO is just a huge sea of dictionaries (objects/classes) with no overarching structure or rules. It lacks consistency and discipline compared to similar info converted to relational. I think some people like OO because it gives them the freedom to be structurally sloppy. Trees at least gave the hope/illusion of a larger structure helping out. Prototype-based OO can still have a hierarchical tilt, I would note. Clone-and-alter and formal inheritance are not that much different.

Second, do you think that, when all the hype involved in it is laid to rest, that OOP will still have a useful place in a broader multi-paradigm programming system? Conversely, do you see TOP as a singularly powerful system, or part of a continuum of possible methodologies (along with ProceduralProgramming, FunctionalProgramming, NotationalDesign, LogicProgramming, FiniteAutomata, and so forth, and yes, even ObjectOrientedProgramming) which should be applied as the situation warrants?

I believe that people gravitate toward paradigms which fit the native way that they think. Unless paradigm X is proven objectively better, it makes sense to find the one that best fits the way you personally think.......if the world will allow it. As far as mixing, see MixingParadigms. It is hard to perfect them all unless you are either a rare sponge-head or live 200 years. Thus, we must pick and choose with care.

Finally have you ever explored the conceptual connections between RelationalProgramming?, LogicProgramming and ConstraintModels? It has always seemed to me that there was a fundamental similarity between these three paradigms, but I have rarely seen any literature discussing it. -- JayOsako

I believe that Prolog's been roved equivalent to the RelationalModel, and could really be viewed as the first relational programming language. Not sure on the exact paper. I read about it in TheArtOfProlog? (ISBN 0262193388 ). It's given just a passing mention, but I think there's a bibliographic reference in there. -- JonathanTang

Perhaps, but I doubt Prolog will come close to ever being mainstream. Maybe something in-between or snuck in through relational is a better way to sell it to wider audiences.

PK, another question: what, if anything, is your opinion on ZigZag, and offshoots such as Gzz (and FenFire? (Unfortunately, the current versions all seem to have dropped CLANG, the cell-manipulation language that was developed for Gzz.)

I'll have to get back to you on that. Some of the key links seem broken.

Examples of the kind of crap I have to put up with on this wiki:

• Of course you overlook th fact that you can't metafy code like that. That whole paragraph shows a serious misunderstanding of how languages and code actually work. You should take some classes and learn how to really program, then come back and read this. (from CodeAvoidance)

• "May be TopMind is not Top at all."

• "Forgive me for telling youbluntly but you are either delusional or suffering from UnconsciousIncompetence." (TupleDefinitionDiscussion)
  • All they had to do was find a single example that punched holes in my alternative definition. Instead they spend their time insulting me. Why is it my detractors are long on insults but short on evidence? They keep insulting me, and then later I am either proven right or the issue is not as simple/descrete as they first thought. Early on I took such insults personally. Now I realize it is a good sign that I am onto something.

Related: FrustrationOverNotGettingOopDiscussion

• They view databases as primarily or only as "storage mechanisms". (DatabasesAreMoreThanJustStorage)

• Don't seem to care about InerfaceFactoring?. They don't realize that most OOP interfaces are essentially hard-wired variations of DatabaseVerbs.

• Don't understand the power and flexibility of declarative (data-centric) programming. They see something magical in behavioral wrappers, but cannot for the life of thm articulate with examples precisely what that magic is. But I have already described the power of a declarative viewpoint: mainly that one can customize their view of information and do "math" on it.

• Don't see the advantages of relational over map-based data structure management. They seem to reluctantly agree that map-based systems have less consistency and less viable "maths" than relational, but seem to think they provide some flexibility that relational lacks to compensate for the lack of map consistency. But, they cannot produce external examples to justify this compensation viewpoint.

• Don't understand that EverythingIsRelative. They cling to the idea that there is one single proper formal view, interface, or taxonomy of everything; and that this can be officially captured as OO interfaces. See the "total calculation" discussion in DatabaseNotMoreGlobalThanClasses for an example.

• Have a frighteningly heavy belief in ArgumentFromAuthority. That is why they are not bothered by their lack of external evidence.

• Regarding, "Why does somebody who disputes the existence of objectivity ask for objective evidence?", I tend to view objectivity on a continuous scale. But either way, nobody has presented OOP evidence that even a majority of OOP proponents will agree is "good and relatively objective" (let alone non-OOP proponents). If and when that happens, then we'll have a subject of investigation of this issue.

Some will object that there are such things as public instance variables. My reply is that those are by their nature a violation of the paradigm, an acceptable compromise as a practical matter but not actually part of OO. Such compromises are quite common in real OO languages, and in most ostensibly OO code; the implications of this regarding the validity of pure OO is left as an exercise for the readers.

Of course, one aspect of this is that, strictly speaking, the concept of an 'object-oriented database' is a contradiction in terms. The people who came up with it simply didn't understand OO, period, and those who promote it do not either. The only way to make it work is for the database as a whole to be the sole object (otherwise, too much data has to get passed about and shared and related for it to work as OO), in which case it's just a wrapper around the real DBMS. Furthermore, the Database Object can't be a source of data - which, as I pointed out above, does not exist in OO - but must instead be a generator for other objects. It simply doesn't fit.

As for classes, they aren't really part of OO either; as Holub has pointed out, the class hierarchy is just a programmer convenience, a way of keeping track of what objects can do what and of grouping similar objects together so as to minimize repetition. Focusing on the classes or prototypes is to literally miss the forest for the trees.

(Another interesting aspect of this is that the separation between 'basic data types' and 'true objects' in some languages is nonsensical; the lowly int, whether in Java, C++, C, or Fortran, fits the definition of an object - an uniform and self-enclosed thing which has a set of defined behaviors - better than many user-defined objects I've seen. The fact that they are allocated on the stack instead of the heap, and aren't accessed by a reference and thus can't be used polymorphically, is simply a compromise in the language design; in the case of Java, it is a compromise that was probably unnecessary.)

As for mathematical rigor, I think that the current approaches are misguided; they focus too much on state, and too little on behavior, which is what OO really is all about. To define OO rigorously, there will have to be a calculus not of encapsulation, but of binding disparate methods together into a whole. Good luck with that, right?

You will note that this is simply a description of what OO is, at least from my own understanding; it says nothing about whether this is a sensible way of programming or not. Even though I'm fairly comfortable with OO, I'm not entirely convinced that it is a sensible approach; I certainly don't think it is the only one, or else I'd have dropped Scheme and C in favor of using Smalltalk and Java exclusively by now. But then, after reading the NASA article, I'm beginning to wonder if we aren't all fooling ourselves, and that maybe we should chuck HLLs entirely and concentrate on writing really, really carefully designed and vetted assembly code. Don't worry, I'm sure that the feeling will pass soon enough... - JayOsako

Perhaps this should be moved to DefinitionsForOo. I realize that some think OO is about putting behavioral wrappings on everything, and to a large extent I agree. But I think a more declarative approach is superior to a more imperative approach (behavior-centric) because there are more "maths" for declarations, such as relational algebra. Plus, behavioral wrappings waste about 40 to 80 percent of their interfaces on essentially DatabaseVerbs. This is because OO does not factor similar kinds of actions into a central spot/interface because encapsulation dictates that each "noun" be self-handling. If you are self-handling, then you cannot share your interface commonalities (InterfaceFactoring). If OO did, it would end up reinventing a database. -- top

you may be right about moving it. I was (as usual) being tongue-in-cheek, and much of what I wrote was hyperbole, but the main argument was genuine: that if OO is to be seen as a separate paradigm at all, it has to be from the Method-Interface perspective. Otherwise, 'object' is just another name for an AbstractDataType variable, with the addition of an excessively elaborate system of code reuse (inheritance) and a lot of buzzwords. Of course, that is exactly how most programmers use it, so perhaps the real truth is that ObjectOrientedProgrammingIsaMyth?.

It is not a myth, just inconsistently defined. Hmmmm. I wonder if defining it as maps with potential functions in the cells, and defining it as behavioral wrappers leads to the same thing more or less. Gotta ponder that one. -- top

Of course, one could argue that about any of these 'paradigms' or 'methodologies' or 'processes' - they are, after all, just conceptual abstractions that we create to make the process of coercing the hardware to do what we want it to easier. In the end, it's all just electrons whizzing about some circuitry in a particular pattern, which we choose to interpret as meaningful because it was our goal to give it meaning... so a paradigm is only as valid as the advantage we perceive it giving us in doing this. Arguing over them is no more meaningful than arguing over whether a God has Buddha-nurture fnord. - JayOsako

Well, after many debates, I can whole heartedly agree that in the end it is probably about which UsefulLie is the most UsefulLie, and it is probably all quite subjective because every mind is different. However, there are some on wiki who believe in authoritative evidence as their primary truth-finding tool, and are almost militant about their viewpoints. Those kind of people are a danger to this wiki and to the scientific process.

From JohnReynoldsFableOnTypes:

• Couldn't you just say, "I would like some more specifics and examples" instead of the "it ain't Nobel material" tirade? Grow some people skills. Even if I am not a coworker of yours, that kind of talk is a bad habit to get into that may leak into your work relationships. Anyhow, I will supply more details soon.

• What does grow more people skills mean? That I should paper you when you have a bunch of nothing and you handwave as if you actually reinvented the wheel? Learn that CriticsAreYourBestFriends. This is not a work environment, it is a wiki environment, therefore CriticalSpirit needs to be encouraged such that worthless content does not pollute and prevent the many readers of this forum to discern valuable advice from ranting. I could care less for you hurt feelings if you considered yourself as somebody who has the working knowledge to revolutionize our understanding of TypeTheory based on arguments of the quality you posted in RunTimeSchemaEngine? and other such stuff. I'll encourage you when you have valid ideas, including some of your OO criticism, but I can't pet you on the back, nor would I do you any service to encourage you to foolishly try on your own the wheel reinvention thingie, I'd rather do you much good to CriticizeBluntly and suggest that some reading on the subject will do you much better than trying to reinvent the subject yourself.

• If it ever turns out that many agree that focusing on syntax instead of semantics was a bad idea, will you apologize to me?

• Write an email to JohnReynolds and ask him for apologies for misleading the hordes of programmers (including me) and countless researchers into the very wrong diection. My critique of your current status of handwaving vis-a-vis RunTimeSchemaEngine? and TopOnTypes has nothing to do with future developments in TypeTheory. And quit polluting wiki pages with irrelevant chaff. These paragraphs need deletion.

Top, please use home pages: I accept and respond to personal critiques, reproaches, etc., on my home pages. Do not pollute topic pages with out of band conversation. Unlike on UseNet the purpose here is to create something that looks more like a dissertation than a chit chat dialogue. -- CostinCozianu

Is this your view of what wiki should be or a consensus view?

Yes, it is a long time consensus view. See GoodStyle.

Sorry, I don't see how that supports your view of wiki.

• Edit pages to emphasize the flow of ideas, not the chronology of contribution.
  • "Flow" is possibly quite subjecive. My philosophy is let everyone expose their opinions, and then clean up it, perhaps in a parallel page, and then convert the thread stuff into a "discussion" topic. Thus, the outline or "clean" version would be "foo" and the discussion would be renamed to "fooDiscussion".
• Be concise and stay OnTopic for the page.
  • I have not knowingly violated this. You felt that complaints about type definitions being tied to syntax was off topic, but I think it is right on topic.
  • Yes, sure. But the above dialog extracted from JohnReynoldsOnTypes? was way off-topic there.

• It is my opinion that proper factoring would eventually clean up stuff. I believe in BrainStormFirstCleanLater. However, but some have prevented me from factoring (see above at about the 60% point).

I can't quite put my finger on it, but since last weekend, I have been thinking of moving across the Tasman to NZ. Any ideas? -- PeterLynch

To escape the end of civilizaion, OOP, Terrorists, or Bush?

Top here's the chaff that was previously on SyntaxDefinition. Do with it what you will, just do not restore it there. I understand your desire to have your private opinion and your private definitions of everything, but we'll try to accommodate that with things like TopOnTypes and TopDefinitionForSyntax, etc.

Sorry, I don't see cut-and-ry Boolean-test formality in that reference. This "battle" seems to be right back to DataAndCodeAreTheSameThing. I did NOT create that topic, and thus am not the only one to share that viewpoint. I might be a minority, but I am not alone. And please stop calling me a "troll", Costin. It is rude.

"Syntax is a string"? Get lost from here. Nobody shares your viewpoint. DataAndCodeAreTheSameThing has nothing to do with syntax. Everybody knows what syntax is, and it ain't a string. To get to the point I'll be concrete. The syntax of Java is the set of grammar rules that define what is a valid Java language element. So syntax is not a string but a set of rules. You may have sloppily referred to the distinction between source code and AbstractSyntaxTree. Calling "abstract syntax tree" not syntax, well, that's obvious, still abstract syntax tree preserves the syntactic structure of the language. The nodes in the AST are syntactic elements.

Not "are", but "can be viewed as". It is a matter of representation. Just about ANYTHING can be turned into "syntax". For example, in Oracle one can "dump" the schema design as syntax. But it is generally stored as Oracle system tables (with a few unseparated expressions for complex constraints in some cases). It is "can be viewed as", not "is-a".

• Repeat after me: syntax is a set of rules that constrain from the infinite set of sequences over an alphabet, which sequences are part of a language. When you say syntax, you do not say the syntax of a program, you say the syntax of a language. So syntax is not a string, get it? Now what is the real word that you trying to redefine as "a string that does not have BlahBlahBlah"? Was it AST?

• How does syntactical constraint rules differ from non-syntactical constraint rules? Lots of things have constraints and rules.

 CREATE TABLE r_users_groups (
	user_id INTEGER NOT NULL ,
	group_id INTEGER NOT NULL,
	CONSTRAINT r_users_groups_pk PRIMARY KEY (user_id, group_id),
	CONSTRAINT r_users_groups_fk1 FOREIGN KEY (user_id) REFERENCES users ON DELETE CASCADE ON UPDATE CASCADE,
	CONSTRAINT r_users_groups_fk2 FOREIGN KEY (group_id) REFERENCES groups ON DELETE CASCADE ON UPDATE CASCADE
  )

Top, even you should know what is that. It's neither syntax nor structure. It is a statement. It is a "CREATE TABLE" statement. That;s one of the chapter in Oracle documentation: the "CREATE TABLE" statement. When you put it as such, it's just its encoding as a string, the strings stays for a "create table statement". It's not syntax, it cannot be syntax. The syntax of Oracle SQL/PLSQL database language can be found at http://otn.oracle.com. The syntax of other flavors can be found at their respective vendors. And they aren't strings.

So "staements" and "syntax" are mutually-exclusive? Where is the math theory for that one? You don't need math theory for that, you just need to know your English.

Because you've been trolling this definition beyond any point of redemption, you probably were trying to say that JohnReynolds definitions of type systems is bad (in TOP's view) because it's tied to what top sees is concrete "strings". Completely bunk: it's tied to syntactic structure, type systems perform type judgements over the nodes in the AST. Get it now? When will we get rid of this EverybodyHasHisOpinion? attitude?

It will go away when you prove ArgumentFromAuthority is practical and effective.

No, it's not effective to get rid of trolls who want to rewrite every word in ComputingScience. But you've made quite a fool of yourself already.

Gee, all these years I missed out on the fficial Computer Science Standard Body. Do they now all sing for ABBA or something? Will they go back to their day job and help guide us strait? If your rules were as precise as you say they are, then we could simply plug something into an algorithm to tell us whether something is "syntax" or not. Wouldn't need humans to determine it. If humans need to be involved in the determination of what something is, then your determination rules are not ripe yet.

Normal humans who speak normal English, know what it is that a word denotes and do not try to change that. When I say "apple", I don't need to provide a computer algorithm to test for "apple-ness". Normal humans can know in 99.9999% of the cases (bar some possibly mutant apples created in laboratory) that a thing is an apple, never mind your call to human unreliability. But if you want to claim that what I call "whales" are in fact apples (by your definition cause now not only EveryOneHasHisOpinion?, EveryOneHasHisDefinition? as well), then I cannot convince you of the truth of the proposition "apple is a fruit".

We can develop criteria for testing "appleness" if it becomes an issue. Some lawsuits over what is "fair" labeling of juice bottles have actually run into these kinds of problems. What is "50% real fruit juice" when sugar and flavoring is added? Do we count volume or weight of the additives? Sometimes we have to turn to ArgumentByVote? for lack of better alternatives. The jury system is an example. The legal system is full of the problems and issues created by the vagueness of human language. EverythingIsRelative whether you want it to be or not. I wish the system had more logic in it, but it does not, and I am only the messenger.

This not legal system, this is a software engineering forums where contributors are expected to possess a minimum amount of education about basic ComputerScience thingies. Or else, keep some quiet and try to learn something for a change.

"Basic" does not mean it possesses precision. "Basic" could mean just a lot of ArgumentFromAuthority because we don't know how to clarify stuff yet.

Syntax:

  x = a + (b * c)

• assignment ("=")
  • accepter ("a")
    • expression
      • operator ("+")
        • operand_1 ("a")
          • operand_2
            • expression
              • operator ("*")
                • [See AbstractSyntaxTree.]

Re: So "statements" and "syntax" are mutually-exclusive? Where is the math theory for that one?

• You don't need math theory for that, you just need to know your English. [from Costin]

• Oh, that's a classic. English as a replaement for math. That's funny. You made my day. -- top
  • Math is a dialect of many human languages.

CC is not willing to compromise. He deletes and moves stuf around to fit his world view as if he possesses a God-given right by some revelation in the mountains. He couldn't put his pet definition of "type" in with the others, instead he deletes all the others. That is going too far. He thinks he's the King, and thus too good to wait in line with the rest of the commoners. You might not like my opinions, but at least I generally leave existing stuff as it was. His WikiSins? exceed a threshold of civility. -- top

Hey, TOP, the guy who refers to John Reynolds as "john" should not open his mouth about civility. And speaking of deletion and civility, it was CC himself that finally deleted the attacks and insults over your real name and protected your anonymity. So you benefited directly from what you complain.

Using first names is a bigger WikiSin? than deletion? Hmmmm. Odd sin math here. And, I have to use deletion-accounting to know if the good deletions outweigh the bad deletions? More complex WikiSin? math....

TopMind - I've seen that there are many problems where TOP would lead to the most direct solution. Now, I typically solve these problems with perl hashes, or a DB and T-SQL. But I have always felt that SQL was not nearly as enabling of TOP as it could be. I wonder if a more elegant language like APL or KDB's Q language (successor to KayLanguage) would be a better approach. I feel like using SQL to approach TOP is like using Basic or C++ - not a clean expression of one person's deep understanding of how to express a particular kind of solution. I want the Lisp, or Smalltalk, or even C, of TOP.

I believe SQL has stymied my growth of TOP thinking. What do you recommend for learning and for practice? -- PeteProkopowicz

What is really needed in my opinion is something like TopsQueryLanguage to replace or supplement SQL, and the various suggestions under SimplifyingRdbms. Aren't the APL successors more for arrays rather than tables? I suppose if they have enough features they can emulate tables. Almost any CollectionOrientedProgramming language is interesting, however. -- top

Aren't arrays and tables pretty similar? I would think an array language would be a natural basis for a DB-oriented language such as KayLanguage. From KayLanguage: "Its greatest use seems to be in the area of managing huge transaction-oriented data bases. In this class of problem K's performance is often staggering." It sounds like the embodiment of your CollectionOrientedProgramming paradigm. TopMind, please read the KayLanguage page and download the KDB demo. It would be interesting to hear your reasoned criticism of the KayLanguage after trying it out

I don't think arrays and tables are really that similar.

My Bulldroppings Watchdog Log

Where claims are validated or debunked

Moved to ChallengeSixVersusFpDiscussion.

Is this related to RunTimeEngineSchema and AdvantagesOfExposingRunTimeEngine? I have not really looked at MSIL. I hear .NET emphasizes static typing, and I am a dynamic typing fan.

MSIL carries an encapsulation of types in metadata which is interpreted at run-time. I am hoping that may allow introduction of types which can be used as generic ones. I have not yet looked in depth, but that is what I hope to find. I was hoping you had looked. Oh well - I will have to investigate further. Thanks.

Top, a request: Please be attentive to the existence of topical pages before beginning an old discussion anew on a related page (or worse yet, starting a new page). See for instance my edits to ExplicitColumnDiscussion. Thanks. -- DanM

I am not sure what you are referring to. I don't see anything "fixed" in ExplicitColumnDiscussion. And I usually do a search for something similar before starting a new topic. I don't always find an existing match because synonyms are used that I failed to guess.

Not a big deal. You had added a comment arguing against SELECT DISTINCT, but there are already at least two pages (pro and con) on this topic, which are now referenced by ExplicitColumnDiscussion. Just trying to keep the amount of scattered rehashing down.

I would note that I was replying to a question originated by somebody else. Is the burden of checking on the originator or the replier?

PageAnchor: Patterns

On Design Patterns

Some have asked about my opinion on OO "patterns". Every paradigm has patterns. See RelationalPatterns, for example. I don't see anything special about OO's patterns versus relational patterns. Some say that OO offers more "behavioral" ability with such patterns, but in my opinion they simply are not skilled in "declaratizing" (data-ify) information so that behavior is less of an issue. Or, they have some unexplained preference for a behavioral view over a declarative one. The more one can data-ify something, the more meta transformations are available, because as I like to say, data is more mathable than behavior.

Another reason declarative approaches seem to be rejected is because they readily don't offer polymorphic abilities. But polymorphism is overrated in my opinion. See SetsAndPolymorphism for more on this.

These also contain some of my opinions and comments about patterns:

• DoubleDispatchExample (my examples are toward the middle)
• PatternBacklash
• http://www.geocities.com/tablizer/prpats.htm

Re: "Remember that people have been doing object-oriented programming since at least the days of Simula in the late 1960s. But OO didn't become a revolution, and dominant in the mainstream, until the 1990s. Why then? The reason the revolution happened was primarily that our industry was driven by requirements to write larger and larger systems that solved larger and larger problems and exploited the greater and greater CPU and storage resources that were becoming available. OOP's strengths in abstraction and dependency management made it a necessity for achieving large-scale software development that is economical, reliable, and repeatable." from http://www.gotw.ca/publications/concurrency-ddj.htm

Arggg. Evidence please. Relational should get the credit, not OO. Most developers use OO-Lite and only give OO lip-service. -- top

I dunno why you lot go on and on about relational vs OO. Both are in practice not what they claim to be. To many, OO is the object structure used in C++. But object orientation is much broader than one particular structure. And OO always has "procedural" components. To many relational is SQL. But SQL is again only one template for data management, and it is not relational in that it does not fulfil the Codd rules. And SQL is useful only within an environment which contains "procedural" components. I cannot see why each resists the others advances. There must be somewhere within OO that SQL syntax is useful.

And I admire your attempts at decomposing SQL into procedural elements. Now if the Lisp experts were producing usable high-level application functions, maybe you would not need to. -- PeterLynch

If you mean TopsQueryLanguage, it is not "decomposed into procedural elements", but merely more easily representable, or implementable, as procedural elements than SQL. That is one of the reasons it is better in my opinion: one can relate to it on both a procedural (step-wise) fashion and in a declarative fashion. It barrows a lot of characteristics from FunctionalProgramming in that way. -- top

There was (is?) a language called Quel, which was the DB access language used by Relational Technologies who marketed Ingres. Ingres early versions were translated to Quel then executed. It may be worth your while to take a look at it - I have not done the research but I believe Postgres has something to do with it

TopMind,

I'm curious what your take is on the Rails framework for RubyLanguage. It's basically an event driven framework for making web applications, but the really special part of it is its activerecord, which transparently and automatically maps database tables and records directly to classes. It does the CRUD for the programmer, even doing things like pluralizing record class names to find the tables. The conventions you must follow when building your tables are minimal (use _id for has-a/belongs-to relationships, etc...) and the framework is fast and powerful.

It seems to me this would simultaneously be very appealing to you (a totally event driven, database-centric app) and at the same time repugnant (the framework is very OO, but allows the database schema to define the classes). It might be at a "just-right" level for you.

Tell me, what do you think of it?

-- DaveFayram

I have found problems mapping directly from the database schemas to CrudScreens. Sometimes it is not one-to-one. It suffers the 80/20 rule. For example, some DB's have a "dateTime" type, but the client may want the form to have two separate input fields, one for data and one for time. Another example is pull-down lists that use a description (obtained via a Join) instead of the key. Thus, I tend to make the DataDictionary's that drive such be independent of the database. A copy operation to start it would be helpful though.

Further, I think the ideal UI framework would be mostly language-independent. It could be described via attributes in tables or perhaps XML (consolation prize). Only the event snippets themselves would be in any particular language, at least from the app developer's perspective. It would essentially be a "GUI browser".

-- top

Couldn't you have at least bothered to google "Ruby Rails" before responding? Rails is a web-centric application system (although the component libraries can be split apart to make non-web apps). Rails can generate CrudScreens, but that's not what I was talking about. Rather, it generates the code to Create-Read-Update-Destroy the data structures themselves, and can even represent relations!

I'll borrow from a Rails tutorial to show you. Let's say we have a table like so in our database:

 CREATE TABLE `todos` (
	`id` INT NOT NULL AUTO_INCREMENT ,
	`description` VARCHAR( 100 ) NOT NULL ,
	`done` TINYINT DEFAULT '0' NOT NULL ,
	PRIMARY KEY ( `id` )
 );

 class Todo < ActiveRecord::Base
 end

 todo_items = Todo.find_all # get's all Todo items in Todos table.
 todo_items.inject( 1 ) { |n,todo| puts "#{n}: #{todo.description}" ; n+1 }

 1: Feed the cat
 2: Clean the cat's box
 3: Clean the cat's box again.
 4: Clean the cat's box yet again.
 5: Shoot the cat. 

 def test_criteria
	criteria_reader = MockCriteriaReader?.new
	report = InvoiceReport?.new(criteria_reader)
	.....
 end 

 # Modified to make it clearer how DependencyInjection can reduce this kind of coupling.
 class ReportProducer? < CriteriaUsingParentHoobajube?
	require_services :reporter, :criteria_collector

	def make_report( criteria ) #
	reporter = Reporter.new( criteria )
	@report = reporter.process
	end

	def collect_criteria
	cc = CriteriaCollector?.new # The method of criteria collection is decided by 
				# the injection, which is a class name in a table. 
	@criteria = cc.process # this would return the collected criteria (and store it in a local variable)
				# which could be passed to make_report or otherwise processed. 
				# We can envision a returned array OR hashtable containing 
				# the data, in which case CriteriaCollector? is a function-object. 
				# Otherwise .process would return some specific collection type.
	end
 end

 rg.make_report( TestCriterion?.new.process )

 def the_function_that_makes_the_report_via_sql_database( criterion )
	# ... Whatever
	query = "SQL that begins the query here"
	criterion.inject( query ) { |q,c| q << " #{c.to_sql}" } # Returns the query
	query << "finishing SQL here"
	# ... Make the query to the product database with query
 end

 # Sets up a ORM to the Customer table, assume customer has some fields
 # and a group of addresses.
 class Customer < ActiveRecord::Base
	has_many :addresses
 end

 # Sets up an ORM to the Addresses table, assume address has a fields:
 # street, number, zip and city
 class Address < ActiveRecord::Base
	belongs_to :customer
 end

 # You care from here on, the previous code only told you what the object relationship is.
 my_cust = Customer.find_all	# Finds all customers, this was in error before, WikiAteMyEdits? 
 my_cust.each { |customer|
	puts customer.name + ": "
	customer.addresses.each { |address|	# Note the nesting of HOFs, this is harder to do
		puts "t #{address}"		# in eval-based systems.
	}
	puts # Puts an empty line.
 }

 // Approach 1
 rs = query("select * from customer natural join addresses where " & criteria);
 prev = '';
 while(row = getNext(rs)) {
	if (row.custID <> prev) {	// description only if different
	println(row.custName & ':');
	}
	println("t " & row.address);
	prev = row.custID;
 }

 // Approach 2
 rs = query("select * from customer where " & criteria);
 while(row = getNext(rs)) {
	println(row.custName & ':');
	adrs = query("select * from addresses where " & criteria);
	while (adrow = getNext(adrs)) {
	println("t " & adrow.address);
	}
 }

 http:RecentChanges?page=TopMind?days=3
 http:posts?TopMind