{
  "date": "December 3, 2014",
  "text": "* \"TOP\" is short for \"TableOrientedProgramming\", TopMind's brand/view of relational + procedural. \"Mind\" comes from the belief that most of software engineering is based on psychology (WetWare) and not \"hard\" (objective) science or math.\r\n\r\n** \"Topmind\" is '''too arrogant sounding''' I will admit. It was a mistake on my part. People put their shields up when they see it. I considered changing it many times. Actually, I started out using something like TabLizer, but it got swallowed in an EditWar. Given a choice, I'd go back to TabLizer, but TopMind is too entrenched on this wiki now, similar to \"Indian\" meaning native American despite being a poor naming choice. As a compromise, I often go by \"top\" or \"-t\" instead to avoid the fuller, arrogant-sounding version. -- top\r\n\r\n* There are roughly three categories of debate categories that cause a lot of wiki steam: -t\r\n** 1. New \"fads\" -- People often claim new stuff is better without doing the homework to demonstrate it first. I pressure them for specific evidence rather than vague, BrochureTalk. (Sometimes new stuff is better, but a good portion of claims are fads.)\r\n** 2. WetWare matters. Non-personal programming is mostly for communication among multiple humans, not so much machines. See TopsLaw.\r\n** 3. Economics -- I usually use some form of economics to evaluate options, but some lean toward ArgumentByElegance, ranking \"purity\" or \"brevity\" above all. See GreatLispWar.\r\n\r\n* Favorite opinion summary: \"EverythingIsRelative and a RDBMS is currently the best relativity tool (especially if relational is done right).\"\r\n\r\n* Favorite quote about self from others: \"I often don't agree with Top, but I have to admit that sometimes he makes me think.\" (paraphrased)\r\n\r\n* Favorite historical person: '''Socrates''': A man who was put to death for asking uncomfortable but probing and important questions. \r\n\r\n* Favorite quotes by self (yes, I do amuse myself. Somebody has to.): \r\n** \"If I am delusional, at least my hallucinations are internally sound and consistent.\" (Based on the accusation that I am too delusional to know that I'm delusional.)\r\n** \"So if I define your digestive system as a \"type system\", then whatever comes out is \"types\"?\"\r\n** \"People still need software to track toilet paper for NASA's restrooms.\" -- A reply to the suggestion that I write for allegedly wimpy domains instead of \"important\" domains. I pointed out that the best technique for some domains differ from others and that I made no universal claim about one-technique-fits-all, unlike the alleged \"important moon rocket\" guy.\r\n** \"Open-source programmers like to hand out nukes to every foot soldier.\"\r\n** \"How many beauty pageants do you have to fail before you finally realize you may be a little ugly? [Lisp]\"\r\n** \"We are not optimizing math or physical processes, we are optimizing human-to-human communication.\" (TopOnWhyTopIsHated)\r\n** \"I know WetWare being difficult to measure is frustrating, and tempts one to go look for their missing iWatch where the light is brighter, even though it was lost in a dim area.\"\r\n** \"The tag may \"affect\" what the operator sees as the type, but it is false that it always \"is\" the type that a given operator \"sees\". You might walk into my country with a police badge from your country and say the badge makes you a \"peace officer\". However, my country may choose to ignore that badge and instead check to see what kind of underwear you are wearing or who your dad is in order to qualify you as a \"peace officer\" in my country. Thus, to say you \"are\" a peace officer is misleading or wrong: it's relative to the country (operator). There is no universal \"is\". And you may be \"associated with\" a badge, but that may be meaningless in a given country because that country may not use or care or recognize that \"associated with\". Your badge is ignored in some countries: it's existence on your shirt is meaningless. Thus the answer to whether object X \"has\" or \"is\" type Y is relative.\" (TypesAndAssociations) \r\n** \"A consistent mess is better than in inconsistent mess.\" (IsObjectOrientationMoreComplex)\r\n\r\n* Believes relational principles are under-utilized in many applications.\r\n\r\n* Believes OOP is probably a personal preference rather than a universally, objectively superior paradigm and that the topic of software engineering is sorely lacking in science and empirical evidence, yet many practitioners see their view of BestPractice as a universal truth. See DisciplineEnvy.\r\n**OOP reminds me of Homeopathic Medicine. Practitioners, truth, liars, etc. There are some natural medicines that work, and there are some OOP advantages too. But to believe that \"There is only one truth\", yet at the same time to see severe inconsistency from one practitioner to the next, is a clash. And this is very common among all homeopaths and OOP advocates. Very scary. It's also about consulting, book sales, and profits too. Not to mention those little $50 bottles of lactose sugar and dust. Magic dust, that is. -- AnonymousDonor\r\n** ''The industry seems to finally be waking up to the fact that OOP was over-sold as an overriding technology. See SplashOneOne (and NoSilverBullet for a history). I declare partial victory for our side. --top''\r\n** ''However, recently FunctionalProgramming fanatics seem to have grabbed the industry hype banner dropped by OOP and are running around with it now. Often it's in the guize of \"mass parallelazation will make everything faster and allow hooking up magic cloud services willy-nilly\"; MagicLegos. Time to put on my debunking warrior suit again? --top''\r\n** [\"FunctionalProgramming fanatics\" claim \"mass parallelazation [sic] will make everything faster and allow hooking up magic cloud services willy-nilly\"?  Really?  Where have you seen that?]\r\n** Give me $80 and I'll tell ya.\r\n** [Ah, so you're making it up.  I see.]\r\n** No, I just want to profit off of your fanaticism.\r\n\r\n* Finds it horrifying how much of \"computer science\" depends solely on AdVerecundiam (ArgumentFromAuthority). This wiki is filled with ivory-tower academics, often devoid of real-world experience and knowledge of economics, who dismiss empirical science and testing using a wide range of excuses, often ranking designs on criteria they personally find intellectually titillating, not focusing on what owners and customers want out of a tool. Battling AdVerecundiam creates a lot of heat and tension, but it's good for the industry. I feel I can make IT a bit better if I can add a little science back into SoftwareEngineering, even if it steams up The Church a bit. Some engineers, academics especially, have a '''bad habit''' of GoldPlating certain aspects without looking at them from a business or economic standpoint. Isolation in ivory towers and/or not understanding the resource tradeoffs of business owners or managers seems to be part of the cause. The main purpose of code is to communicate among teams and future developers, NOT MACHINES. Machines are secondary. Often these developers are not heavily versed in mathematics such that \"high-brow\" programming that focuses on parsimony alone can trip them up and complicate organizational staffing. '''The ivory-tower crowd typically does not want to consider economics and staffing, but rather want to see it ALL from a mathematical perspective'''. This is what lack of well-roundedness in analysis can result in, and it's a big mistake.  (See StaffingEconomicsVersusTheoreticalElegance, TopOnWhyTopIsHated, AreWeBiasedTowardLaborIntensive) --top\r\n\r\n** \"Clutch\" analogy discussion moved to StaffingEconomicsVersusTheoreticalElegance.\r\n\r\n* Believes relational imposes a consistency and discipline in systems design that OO allegedly lacks.\r\n\r\n* Believes that procedural can scale easier than OO because one can allegedly divide the application up into relatively independent \"tasks\" or \"events\" that feed to and from a central database.\r\n\r\n* Believes that non-trivial taxonomies, relationships, and structures should be data instead of code because data is allegedly easier to customize one's view of in order to inspect, study, and test. SyntaxFollowsSemantics.\r\n\r\n* Believes that SoftwareEngineering is far more about psychology than \"purest\" disciplines like math. About the only purest concept is believed to be OnceAndOnlyOnce, and it is perhaps just a guide rather than a hard rule.\r\n\r\n* Believes that the majority of most algorithms can be reduced to DatabaseVerbs and DeclarativeProgramming if one knows how. (Converting to the full extent possible is not always the most practical route, however.)\r\n\r\n* Believes that OO makes the mistake of trying to find/force global domain abstractions, when in fact they should be kept local to specific tasks using queries and modules. Believes that abstractions are generally relative to use.\r\n\r\n* Believes '''set theory''' is more powerful and more general than \"sub-type theory\" often used by OO, but the logical extension of this view leads more or less to relational rather than OO.\r\n\r\n* Believes \"refactoring\" is often a euphemism to hide the fact that OO cannot handle changes as well as originally claimed.\r\n\r\n* Perceives the \"classic\" DataStructures (stacks, bags, lists, etc.) to be archaic concepts to be used only for local, smaller, temporary sets of data. See AreTablesGeneralPurposeStructures. \r\n\r\n* Believes many of the justifications given for OO designs are based on a flawed set of ChangePattern assumptions. OO proponents allegedly have an unrealistic sense of how requirements change over time because OO doctrine tends to highlight certain change patterns that OO is good at, but ignores other equally valid variations that OO has a harder time with.\r\n\r\n* Believes that the distinction between code and data should be phased out to help achieve the holy grail of SeparateMeaningFromPresentation.\r\n\r\n* Perceives this wiki to have an anti-RDBMS bias.\r\n\r\n* Prefers not to use RealName''''''s because criticizing OO is allegedly harmful to one's career.\r\n\r\n* Used to do heavy development with NimbleDatabase''''''s such as FoxPro. (I don't think it is the ideal language, but it taught me many table-oriented concepts.)\r\n\r\n* Generally focuses on custom business applications.\r\n\r\n* Generally a fan of DynamicTyping.\r\n\r\n* Recently curious about TclLanguage (resigned), MultiParadigmDatabase, and TopsQueryLanguage.\r\n\r\n''Added by visitor''\r\n* Generally does not agree on the definition most people use (TopDefinitionForSyntax, TopOnTypes)\r\n** ''The syntax thing was an internal working definition and should have been deleted, but I can't delete it now. As far as \"types\", there is no \"most people use\" definition for it. It has no consensus definition at this point. I admit that I often create working definitions when existing definitions are lacking or too vague to clarify what I am talking about. I make it a point to label its usage as only a working definition, but sometimes either forget, or the disclaimer gets lost in the middle of long, heated debates. You are welcome to suggest a better term, but I will ask you to justify it if you complain heavily about my choice. --top''\r\n** ''I admire the \"flag-free\" [AKA \"tag-free\"] typing model. See ColdFusionLanguageTypeSystem. Tags are anti-WYSIWYG, similar to having nulls in strings.''\r\n\r\n* Believes that a milder form of Intelligent Design is or can be a legitimate science, but agrees that evolution is by far the stronger candidate. Has proposed mining DNA for patterns similar to SETI's efforts (ID@Home), although believes such an endeavor is unlikely to find anything. But it is a hobby and not government money, so \"waste of time\" is not an issue. Think of it as looking for \"alien Monsanto's\".\r\n\r\n----------\r\n\r\nSome of my favorite topics\r\n\r\n* DatabaseNotMoreGlobalThanClasses\r\n* SeparationAndGroupingAreArchaicConcepts\r\n* ProgrammingWithoutRamDiskDichotomy\r\n* TableOrientedProgramming (TOP)\r\n* MaspBrainstorming - Trying to merge TOP and a language as a unifying concept\r\n* ArgumentsAgainstOop\r\n* SoftwareGivesUsGodLikePowers\r\n* GoodMetricsProduceNumbers\r\n* SoftwareDevelopmentIsInvesting\r\n* MaspBrainstorming (a take on Lisp)\r\n* SoftwareEngineeringIsArtOfCompromise\r\n* SimulationOfTheFuture - How to choose among multiple design options\r\n* SimplifyingRdbms (Relational would be more popular if \"done right\")\r\n** DynamicRelational and MultiParadigmDatabase\r\n** SmeQl\r\n\r\n------\r\n\r\nIndustry terms that are BS or too fuzzy to be useful beyond a rough notion:\r\n\r\n* CouplingAndCohesion\r\n* BusinessLogicDefinition\r\n* EnterpriseApplication\r\n* SoftwareEngineering\r\n* Types (useful in a general sense, but still fuzzy)\r\n\r\n----\r\n'''OO Criticism Summary'''\r\n\r\nMost of my criticisms of ObjectOrientedProgramming can be summed up as follows. \r\n\r\nIf you consider subtype-heavy OO (one \"flavor\" of OO), then I generally reject it as described in LimitsOfHierarchies and ThereAreNoTypes. I just find sub-typing too artificial and limiting to fit real world classification needs. AlexanderStepanov, a person with more clout than me, has also made similar complaints about subtyping. \r\n\r\nThen there are OO methodologies that de-emphasize sub-typing. These OO methodologies tend to reinvent NetworkDatabase''''''s (a kind of NavigationalDatabase), which ChrisDate and others have adequately addressed the problems. OO proponents often emphasize the integration of behavior and data as the selling point of their NavigationalDatabase-like arrangements of code. However, I have failed to see a good argument made for this. \r\n\r\nI would like to see OO proponents explain this alleged behavior connection better. We don't seem to \"connect\" when explanations are sought. Behavior could be integrated into tables if it was helpful I would note (See ControlTable and ObjectsAreDictionaries). \r\n\r\nBut, I have seen that technique only provide relatively minor improvements because one-to-one relationships between data and behavior are generally rare or temporal. Thus, TableOrientedProgramming and behavior-data integration are not necessarily orthogonal. -- top\r\n\r\nThe \"algorithm\" for the problems I see in OO would look something like:\r\n\r\n  If tree-centric OO being analyzed then\r\n\tLimitsOfHierarchies and ThereAreNoTypes squash trees.\r\n  else\r\n\tOO is mostly an app-built NavigationalDatabase, which\r\n\t_ is inferior to RelationalDatabase theory.\r\n\tif integration-of-data-and-behavior compensate for problems of navigational then\r\n\tThe benefits of the integration are elusive or difficult\r\n\t_ to articulate. Putting code in relational databases is\r\n\t_ also possible, but provides only incremental benefits.\r\n\tend if\r\n  end if\r\nThe majority of arguments eventually lead to this same pattern. A few will defend navigational in itself, but it is the integration that most OO proponents eventually focus on.\r\n\r\nAnother way to essentially say the same thing:\r\n\r\n* Data-drien (sometimes called DeclarativeProgramming) is generally superior because one can transform their view of the information to however they see fit, not just how the original programmer thought to group stuff. (Note that I don't claim to put everything into declarative form, only much more of it than an OO'er would.) See CodeAvoidance. It is all about decoupling meaning from presentation (SyntaxFollowsSemantics), and decoupling is good, no? Further, it increases cross-language and cross-platform information sharing.\r\n\r\n* Relational tables are a better building-block than webs of dictionaries AKA maps AKA navigational, which is what OO is based on. Dictionaries/maps are too small a unit to provide a consistent and grokkable foundation. There is no existing \"map math\" that is nearly as usable and powerful as \"table math\" (relational). Maps are old school. See ObjectsAreDictionaries.\r\n\r\nIt is essentially declarative-centric tables versus behavior-centric (code-centric) dictionaries (OO). That is the summary of the battle when you get right down to it.\r\n\r\n(I suppose one should consider declarative-vs-behavior and tables-vs-dictionaries somewhat orthogonal. For example XML proponents are really selling declarative dictionary webs, as an XML statement is essentially a dictionary with an implied \"tagName=\" element.)\r\n\r\n----\r\n\r\nIdeal TableOrientedProgramming system or environment according to TopMind:\r\n\r\n* A RelationalLanguage similar to BusinessSystemTwelve, or at least FP-like in nature. TopsQueryLanguage\r\n* A table engine built into language libraries such that table API calls can be directed toward BigIronDatabase''''''s if needed with little or no change other than driver selection.\r\n* Powerful \"table browser\" than can be used to view tables and query results.\r\n* A \"dynamic relational\" database (see MultiParadigmDatabase) that can be static-relational (like Oracle) if tables or columns are deemed \"static\" by the designer.\r\n* \"Column-based views\" in addition to table views.\r\n* For preferred language features, see http://www.geocities.com/tablizer/prtips.htm\r\n\r\n------------\r\n\r\nMy History\r\n\r\nDuring an internship in college I encountered a little bit of dBASE II (ExBase). I thought the idea was pretty inertesting, but had so much on my plate that I ignored it after the internship. In college I also encountered a statistical package called MiniTab in my second semester of statistics that performed CollectionOrientedProgramming techniques to get statistical results from data. One could define the data once and do a zillion operations on that same data instead of keying it in all over again for each statistical operation. And, there was no programming involved (it may have had that option, but we did not use it). I also had a small APL assignment in one course. Although I didn't think APL was that practical outside of math, it helped in part to get the CollectionOrientedProgramming gears clicking in my head yet more. (I don't remember any of the APL, so please don't ask.)\r\n\r\nI remember a 3D graphics assignment in which we had a bunch of linked shapes and graphical transformations (rotate, scale, extrude polygon, etc.) that comprised the image model. It was a fun project, but had one major drawback. It used Pascal linked lists. I kept thinking to myself that there had to be a better way to manage complex structures of such things. It seems I spent most of my coding on CollectionOrientedVerbs issues rather than the domain (graphics). I was one of the few who completed the final assignment due to all the coding required. It was crying out for a database of some kind. I started thinking back to ExBase, MiniTab, and APL.\r\n\r\nAfter graduation I eventually landed a position that used ExBase. It was not the first database I encountered in the working world, but certainly the most nimble. It made tables so easy to create, edit, and view that I started putting all kinds of things into tables, including code. \r\n\r\nWhen OOP started becoming popular I realized that it ignored CollectionOrientedProgramming techniques, instead building by hand, or clumsy methods, complex internal structures. It was only a minor improvement over the Pascal linked list mess. Microsoft tools such as Excel and Word created their own little internal OO model of the paes/sheets (and later DOM with the same idea). It was just like my college graphics 3D modeling system, with similar problems. A pointer nightmare, OO was the GO-TO of data structures. (See HiddenDatabaseSyndrome and NavigationalDatabase.)\r\n\r\nHard-wiring the methods to the linked list may have reduced some typo errors, but still didn't factor CollectionOrientedVerbs issues into a consistent, automatically-\"inherited\" protocol for dealing with collections. OOP was inside-out: collection handling should be put on the outside, not on the inside of the \"objects\" where there is no central coordination of common collection idioms. Encapsulation allowed too much \"creativity\". All the talk of reuse, but that ain't reuse.\r\n\r\nWhen I realized that OOP was spreading like wild-fire, I decided it was time to start countering by showing the virtues of CollectionOrientedProgramming, relational in particular because of its value in the biz world, and demanding solid OOP evidence instead of tolerating brochure-like buzzwords. I thus turned into an anti-OO evangelist. \r\n\r\n----\r\n\r\n'''Topmind FAQ and AQ'''\r\n\r\n''Q: Tables and most RelationalLanguage''''''s are not TuringComplete, thus they cannot solve every algorithm.''\r\n\r\nA: Completely solving every algorithm is not their purpose any more than solving every algorithm is the purpose of RegularExpression''''''s. Table techniques may solve 0% or 100% of the problem, but usually it is somewhere in between. Procedural code (or some other paradigm) is then used to do the rest. Tables and relational are a high-level tool to greatly help simplify a majority of tasks. They are often like a power drill compared to a hand drill: they will greatly simplify drilling, but will not do the entire job by themselves.\r\n\r\n''Q: I don't like using tables and databases because I have to go through the DBA to get anything done, and she is always busy.''\r\n\r\nA: This is mostly a political issue, not a technical one. If an OO \"class master\" was in charge of changing and overriding parent classes, you would have similar complaints. Also it would be nice if more languages supported built-in tables or NimbleDatabase engines. See DbasGoneBad.\r\n\r\n''Q: Some say you are \"anti-science\". Is this true?''\r\n\r\nA: No. I believe in science as an empirical system to find, test, rank, and disseminate the best models of reality. However, some seem to feel that science is ArgumentFromAuthority: \"If the great Dr. Foo says Zerktron makes programmers 76% more productive, then it's true!\" Hogwash! That's dark-age science. -t\r\n\r\n''Q: I like using tables, but I'd rather use an OO language than a procedural language. Why should I give up OOP for TOP? What's in it for me?''\r\n\r\nA: It just may be all subjective. Tables and relational better fit my head, but maybe not yours. Note that I think TOP and OO are not really orthogonal. Non-trivial classification information (taxonomies) and relationship information either are going to be in code or as data (tables). Having a given set in both places is a violation of OnceAndOnlyOnce. OO proponents sometimes say that having such in code improves behavior-handling, but I have yet to see a convincing demonstration.\r\n\r\n* ''OnceAndOnlyOnce is a source issue, not a representation issue. If your model is defined in one place, it doesn't matter how many places it exists. If the db is generated from the class model, or class model from the db, or both are generated from something else, OnceAndOnlyOnce isn't violated.''\r\n\r\n* A: I am not sure what you mean by \"source\" versus \"representation\". Perhaps this relates to issued raised in CodeGenerationIsaDesignSmell.\r\n\r\n* ''\"source\" is the definition, the one thing you edit. Everything else comes from the source; representation maybe isn't the best word for that - in compiler terms it's 'the binary'. OnceAndOnlyOnce sometimes requires a few gyrations that are similar to code generation. Code generation can be problem if it's something you have to muck with by hand after it's generated, but the point is to generate whatever you need from a single point of definition. See ThePragmaticProgrammer.''\r\n\t\tTransientCodeGenerationIsGoodDesign -- PeterLynch\r\n* If you fill in tables that generate OOP code that is never hand-edited, are you really doing OO?\r\n\r\n* ''The behavior isn't generated, only the layouts. The behavior has to be coded somehow, regardless of the paradigm.''\r\n\r\n* That is still code. \r\n\r\n''Q: If TOP can be used with OOP, why all the fuss, Gus?''\r\n\r\nAs described above, they tend not to be orthogonal in my opinion. (I fixed a typo that may have been misleading.) There used to be a long discussion about this orthogonality issue, but it was deleted by somebody.\r\n\r\n''When you say that TOP and OO are not orthogonal, you mean that the more TOP I use the less OO I use and vice versa? That contradicts your other statements about the use of procedural.''\r\n\r\nI don't see any contradiction. Procedural is generally shaped by task and only task. OO on the other hand tends to build NounModel''''''s and noun taxonomies in code. If you take noun taxonomies and noun relationships out of the code and put them into data, then you basically no longer have OO. Encapsulation: the database wraps the data, not behavioral classes. Polymorphism usually depends on explicit or implicit sub-typing (inheritance), which is a code-based taxonomy. Like I say above, non-trivial taxonomies don't belong in code.\r\n\r\n[If you have procedural code performing the behavior for a data structure, knowledge of the data structure is in the code, it's just not as explicit.]\r\n\r\nI am not sure what you mean here. If you mean that databases and datastructures must still be implemented in code, that is true but not code that an application programmer sees. I am looking at this from the app developer's perspective. They usually don't care how datastructures and databases are implemented. It could be OO, FP, procedural, or really fast bacteria. \r\n\r\n[...but the code still need to know ''something'' to get at the data. If a procedure operates on a field, it needs to bind to it somehow. It has to know the field name or index or enum or something that it can use to get at the data.]\r\n\r\n''Procedural is no more shaped by task than OO, it just divorces data structure from operations. The data structures used in procedural programming can't be replaced by a database.''\r\n\r\nIf I need anything more complicated (or potentially more complicated) than a non-nested hash/map array or list, then I prefer tables. See DedicatedStructuresVersuRdbms. And I generally only use hashes for local, short-lived items.\r\n\r\n''Then you work in a very different world than the rest of us.''\r\n\r\nI guess so. To me tables seem very logical. They are visually compact (compared to code), flexible, and offer a consistency in noun modeling I just don't see in OO. I have encountered other table heads also, so I know I am not alone. I didn't start out using table-oriented tools (although my early designs show hints of it), but when they came it was as if I always knew them. It was, \"where the hell have you been for the last few years?\" \r\n\r\n''I'm not talking about your head. I'm talking about the work you do.''\r\n\r\nSee: AreBusinessAppsBoring\r\n\r\n''Why?''\r\n\r\nPerhaps I misunderstood the original question.\r\n\r\n----\r\n'''I am looking at this from the app developer's perspective. They usually don't care how datastructures and databases are implemented.'''\r\n\r\nI challenge that assertion. I'm an app developer. I've worked with many app developers. Not only do we care how data structures and databases are implemented, we implement them every day. -- EricHodges\r\n\r\n''You implement database engines every day??? You compete with Oracle and/or NimbleDatabase vendors??? There must be a misunderstanding here. Perhaps it is the difference between \"implementing a database\" and \"implementing a DBMS\". The first sometimes means domain schema design. ''\r\n\r\nDatabase != RDBMS.(Which brings to mind SyntaxAcrossLanguages) Any collection of data is a database, whether it's a linked list, hashtable, serialized object, flat text file, XML document, Perl DBI, or Oracle RDBMS. Some of these are easier to work with than others, but many times you don't need the full power of an SQL RDBMS. If you're just implementing an application's config file, why not use the registry, an INI file, or a .properties file instead of making your users install MySQL? -- JonathanTang\r\n\r\n{If you already have a database available for other parts of the application, then why not use it? Besides, table engines don't necessarily have to be installed separately. See NimbleDatabase.}\r\n\r\nI don't implement DBMSs today, but I have in the past. I competed with Oracle and won for several years. I don't mean schema design. I mean implementing database management systems. I implement data structures every day. I am an application developer. DBMSs are applications. -- EricHodges\r\n\r\n''Well, that differs from my interpretation of \"application developer\". Anyhow, you are technically correct with regard to the meaning of \"database\", but the term has been bent in actual usage. I will try to be more explicit in the future.''\r\n\r\nI mean what you mean by the word \"database\". I've written DBMSs. I don't mean data structures by that. I mean distributed servers that manage large volumes of data, relationships, transactions, etc. at high speed. They are applications. I am an application developer. -- EH\r\n\r\n''You mean custom, app-specific database engines? I have not encountered too many who have done that. I believe it was you who claimed that you found RDBMS too slow for a certain application or need. I cannot really comment on that because I have not seen the requirements and the reasons why RDBMS were not fast enough or whether they could be tuned for it. I never claimed that RDBMS were the best solution for 100% of all applications or shops. Nothing is.''\r\n\r\n[There seems to be some confusion, in the above discussion, between \"database\" and \"relational database\". The latter term is a subset of the former.]\r\n\r\n''Well, there does seem to be confusion of some kind.''\r\n\r\n----\r\nHey Top,\r\n\r\n1. I responded to a question you asked at the bottom of ObjectRelationalMapping\r\n\r\n2. I seem to recall you saying that it wasn't possible to automatically generate well-designed N-th normal form schemas, that humans had to do it. Am I recalling correctly? If so, who demonstrated this? Got a URL? Or was it dependent on starting point, e.g. starting with a non-normal form Excel spreadsheet being used as a poor database?\r\n\r\n''Sorry, I don't recall such a discussion. I will get back to you if I later do. -- top''\r\n----\r\n\r\nWhat are these \"generators\" you keep talking about as an alternative to grammars?\r\n\r\n''You mean like the examples in AlternativesToRegularExpressions? I don't know where I first heard about them, but they are explained more in O'Reilly's \"LexAndYacc\" book. They are basically just substitution rules for defining what the \"parts\" of a grammar are. They are a pretty powerful declarative technique. I guess I am sort of attracted to declarative stuff, eh?''\r\n\r\nThat's not surprising. Anyway, it's very misleading to talk about stuff '''from''' Lex and Yacc as an alternative '''to''' Lex and Yacc.\r\n\r\nAlso, since I know those two tools exceedingly well (but am not likely to buy the O'Reilly book), I believe you're talking exclusively about Lex. Yacc's \"substitution rules\" are just rules.\r\n\r\nI don't recall the word \"generator\" being used for any such thing, though. Maybe that's unique to that book? Or maybe my memory's just bad...\r\n\r\n''I don't know where I first heard the term \"generator\". Anybody else know the origin/source? Maybe I got it mixed up with something else. Also, I did not propose them as an alternative to Lex/Yacc.''\r\n\r\nWell, Lex and Yacc are often called \"parser generators\" (though lex is actually a DFA generator). But that doesn't make them replacements for grammars, that makes them ways of implementing machines that accept a (parse) a language matching a particular grammar.\r\n\r\nThen there are GeneratorsInPython; a specialization of CoRoutine''''''s. These can be used to implement parsers (that page gives an example); but that's not a replacement for a grammar either.\r\n\r\nAnd none of this has much to do with relational vs OO anyway, at least not that I can tell.\r\n\r\n''I don't see where anybody implied they were related, except possibly data-centric versus behavior-centric thinking. -- top''\r\n\r\n----\r\n\r\nDogma - \"let's just say we'd like to avoid any empirical entanglements.\"\r\n\r\n----\r\n\r\n'''\"OO is Like Goto's\" Rant'''\r\n\r\nI have never seen an objective comparision/study of GoTo fans versus block fans WRT productivity. If you know of one, please let me see it. Otherwise, you are only speculating.\r\n\r\nI suspect their development was just as fast as blockers, but not as fast when reading other's code. This is because there were no accepted lists of \"goto patterns\" ever developed. Each experienced goto'er developed their own patterns with no known effort to consolidate them. (More on patterns later.)\r\n\r\nPlus, they were never able to explain their philosophy in detail, something they have *in common* with OO'ers. Block statements are generally considered more *consistent* from programmer-to-programmer, and nesting of blocks provides visual cues to the nature of the flow that goto's have no identifiable counter-part. I have never heard/read a goto fan claim there is a clear visual component to goto's. (I suppose you could draw lines with pens, but that is an extra step.) Then again, I have not seen many attempts to document the thinking process of goto fans.\r\n\r\nOO is basically NavigationalDatabase''''''s of the 60's resurrected as Dawn of the ead zombies with a new name, and that navigational is the Goto of structuring because it lacks the consistency of relational, and thus parallels the consistency problem that goto's had (see above).\r\n\r\nAlmost every OO fan's design is significantly different han another's. The Design Pattern movement is an attempt to remedy this, but is as futile as an attempt to form Goto patterns. \r\n\r\n''Then you don't understand design patterns at all. The DesignPatternsBook didn't create those patterns; those are the patterns that were found to be used by just about all OO programmers. It was a study of real working patterns found in the wild. (Hence the fact that each pattern had a \"Known Uses\" section.) Those patterns were already well established, and are quite consistent throughout the OO community. To say it lacks consistency is to admit you don't know what you're talking about.''\r\n\r\n* I am not suggesting that goto fans would have to create goto patterns from scratch. Even my gotos (when forced to use them on old compilers) had certain patterns to them. Others appeared to have had goto patterns also. However, nobody seems to have made an attempt to document and catalog them. As far as patterns adding consistency to OO, such is covered under OoLacksConsistencyDiscussion.\r\n\r\n** Of course, goto patterns have been cataloged and documented. And much more - these patterns have been implemented as ''higher level control structures'', if/then/else, and various forms of loops. The most successful DesignPatterns are the ones that get legislated later.\r\n\r\n*** That is an interesting way to look at it. However, I believe that if one really thinks about GOF-like patterns hard, it will eventually lead to relational designs. GOF patterns are largely just data patterns hard-wired into classes. Relational turns them into relational algebra instead of physical code. (http://www.geocities.com/tablizer/prpats.htm) It is a higher-level abstraction IMO. I believe that the logical evolution of task flow leads to blocks (from gotos), and the logical evolution of data structuring leads to relational. Goto's are the navigational equivalent of behavior. OO is a mess of data pointers, and goto's are a mess of behavior pointers. I know you will probably disagree with this viewpoint. GOF only formalizes the goto's, not eliminates them. It would be like presenting a bunch of repeating goto patterns instead of IF blocks or other structured statements:\r\n\r\nThis is a \"goto pattern\":\r\n\r\n  if (x != 1) goto B:\r\n  ....\r\n  goto G\r\n  B:\r\n  if (x != 2) goto C:\r\n  ....\r\n  goto G\r\n  C:\r\n  if (x != 3) goto D:\r\n  ....\r\n  goto G\r\n  D:\r\n  if (x != 4) goto E:\r\n  ....\r\n  goto G\r\n  E:\r\n  ....  // \"otherwise\"\r\n  G:\r\nThe modern \"cleaner\" solution is a case statement (with no \"break\" statements):\r\n\r\n  select on x {\r\n\tcase 1: {....}\r\n\tcase 2: {....}\r\n\tcase 3: {....}\r\n\tcase 4: {....}\r\n\totherwise: {....}\r\n  }  // end select\r\nGOF is like the first. It simply documents the pointer messes, not fixes them. Look at Visitor versus relational or data-driven alternatives (DoubleDispatchExample). OO sees it as a code pattern, but I see it as mostly a data pattern, and thus the clutter of data references (pointers) is removed or reduced from code.\r\n\r\n. . .\r\n\r\nSecond, 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.\r\n\r\nRelational 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.\r\n\r\n* A fractured, desperate analogy if I've ever seen one.\r\n\r\n** 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.\r\n\r\n----\r\n\r\n''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).''\r\n\r\nI 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.\r\n\r\n----\r\n\r\n'''Response to claims made against me'''\r\n\r\n* '''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. \r\n\r\n* '''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. \r\n\r\n* '''Creates too many new topics''' - See above about the \"#\" problem.\r\n\r\n* '''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.\r\n\r\n* '''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.\r\n\r\n* '''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.\r\n\r\n* '''Has only dealt with \"simple\" applications''' and thus is uninformed about \"real\" applications - This is covered just below and in DomainPissingMatch.\r\n\r\n* '''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. \r\n\r\n**{ '''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.)}\r\n** 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.\r\n\r\nSee also PatternsOfClaimsAgainstTop.\r\n----\r\n\r\nMy 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\r\n\r\nMy 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.\"\r\n\r\n* What exactly is \"advanced programming\"? Sounds like a DomainPissingMatch.\r\n\r\n* \"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.\r\n\r\nThat's because most shops don't know how to do OO well, I've had exactly the same experiences. You can't blame OO because people do it badly. Most programmers learn procedural programming first, and that kinda cripples the mind when it comes to learning to do OO well, it's very common. Those who do it well, find it very successful and very easy and natural.\r\n\r\nAs 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!\r\n\r\n* 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.\r\n\r\n* 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.\r\n\r\n* 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.\r\n\r\nIt is an absolute truth that OO has advantages over procedural, period. It's also an absolute truth that every methodology has advantages over other methodologies, given the right context. Does that mean OO is perfect? No, nothing is perfect; every methodology has weaknesses or contexts in which it isn't suitable. There are times when OO isn't the right solution, so what, no-one disagrees with that, sometimes functional is better, sometimes procedural is better, we can admit that, you can't. You get grief because it's obvious you have an axe to grind, you don't have an open mind, and you endlessly rant against OOP; basically, you do nothing but cry wolf constantly, you can't be surprised people attack you, ignore you, and ridicule you, because you never stop asking for it.\r\n\r\n''OO is currently being \"marketed\" as the end-all-be-all, and NOT Yet Another Paradigm.''\r\n\r\nThat's what marketing people do, so what, they d that with everything.\r\n\r\n''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. ''\r\n\r\nAgain, 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.\r\n\r\n''As far as me being \"close minded\", show me some kick-ass evidence, and I just may open it. Deal?''\r\n\r\nNo 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.\r\n\r\nPossibly 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.\r\n\r\nPeople 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\r\n\r\n''Perhaps you guys are not really the audience f my complaints. -- top''\r\n\r\nI, 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\r\n----\r\nThe Internet never forgets: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=6hba36%24rmi%241%40nnrp1.dejanews.com\r\n* What point are you making by pointing to that? -- dm\r\n* 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\r\n----\r\nAn interesting topic to ponder is ProgrammingWithoutRamDiskDichotomy. Thinking this way should highlight the differences between OO and relational. The future will blur the distinction more I bet, so one had better get used to thinking that way. \r\n\r\nMeasuringAbstraction is another brain twister.\r\n----\r\nOn a different track: given that one of your primary critiques of conventional OOP is that it creates and enforces a false hierarchy through the class system, what do you think of PrototypeBasedLanguages such as SelfLanguage? Do they avoid this particular problem, or do they just hide the hierarchical structure? Does this approach solve any of the problems you see in class-based OO, and do you see it having any problems of it's own?\r\n\r\n''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.''\r\n\r\nSecond, 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?\r\n\r\n''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.''\r\n\r\nFinally 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\r\n\r\nI 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\r\n\r\n''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.''\r\n\r\nPK, 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.)\r\n\r\n''I'll have to get back to you on that. Some of the key links seem broken.''\r\n\r\n---------\r\n\r\nExamples of the kind of crap I have to put up with on this wiki:\r\n\r\n* ''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)\r\n\r\n* \"May be TopMind is not Top at all.\"\r\n\r\n* \"Forgive me for telling youbluntly but you are either delusional or suffering from UnconsciousIncompetence.\" (TupleDefinitionDiscussion)\r\n** 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.\r\n\r\nIf I can find 10 more of these, do I have permission to go into VictimMode?\r\n\r\nRelated: FrustrationOverNotGettingOopDiscussion\r\n--------\r\n'''Mental Blocks that OOP Proponents Generally Seem to Have'''\r\n\r\n* They view databases as primarily or only as \"storage mechanisms\". (DatabasesAreMoreThanJustStorage)\r\n\r\n* Don't seem to care about InerfaceFactoring. They don't realize that most OOP interfaces are essentially hard-wired variations of DatabaseVerbs.\r\n\r\n* 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.\r\n\r\n* 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.\r\n\r\n* 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.\r\n\r\n* Have a frighteningly heavy belief in ArgumentFromAuthority. That is why they are not bothered by their lack of external evidence.\r\n\r\n* 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. \r\n\r\nNote: Not every OO proponent is the same. These are only general \"clusters\" of behavior they seem to present.\r\n\r\n----\r\nOne point about OOP which yound, it must be said, most OO programmers, including nearly all of the fanatics - seem to be missing is that OO is not about data, or data structures. It is about pretending that ''there is no data'', just 'objects'. Objects, from the perspective of the client-programmer, are atomic things, with no subcomponents, just behaviors. They are defined entirely in terms of what they ''do'' - their public methods - not the data they contain. The data, if there is any at all, is just a detail of the internal implementation, a way to represent the state of the object; it can and often should be replaced by a function that calculates the result. From the outside of the object, the data itself isn't just irrelevant, it is '''non-existent'''.\r\n\r\nSome 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. \r\n\r\nOf 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.\r\n\r\nAs 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.\r\n\r\n(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.)\r\n\r\nAs 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?\r\n\r\nYou 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\r\n\r\n''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''\r\n\r\nyou 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. \r\n\r\n''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''\r\n\r\nOf 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\r\n\r\n''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.''\r\n----\r\n\r\nFrom JohnReynoldsFableOnTypes:\r\n\r\n** ''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.''\r\n\r\n** 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. \r\n\r\n** ''If it ever turns out that many agree that focusing on syntax instead of semantics was a bad idea, will you apologize to me?''\r\n\r\n** 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.\r\n\r\nAnd if you claim that I personally insulted you, you have a very serious problem in the CriticalSpirit chapter. I'm sorry to say but the WikiMission is not to manage the overly sensitive personality of one TopMind. Lucky you that you haven't met RichardKulisz yet.\r\n\r\nTop, 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\r\n\r\n''Is this your view of what wiki should be or a consensus view?''\r\n\r\nYes, it is a long time consensus view. See GoodStyle.\r\n\r\n''Sorry, I don't see how that supports your view of wiki.''\r\n\r\n* Edit pages to emphasize the flow of ideas, not the chronology of contribution.\r\n** \"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\".\r\n* Be concise and stay OnTopic for the page.\r\n** 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.\r\n** Yes, sure. But the above dialog extracted from JohnReynoldsOnTypes was way off-topic there. \r\n\r\nThat's what you don't do. But we are open to suggestions as to what is TopOnWiki. What should we do about wiki? Create a never ending ThreadMess to reflect exchanges between the never satisfied TopMind and the rest of contributors? Or what?\r\n\r\n* 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).\r\n\r\n----\r\n\r\nI 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\r\n\r\nTo escape the end of civilizaion, OOP, Terrorists, or Bush?\r\n----\r\n\r\nTop 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.\r\n\r\n----\r\nWe cannot accept TOP to go about trolling redefining everything in computing science. See for example: http://en.wikipedia.org/wiki/Syntax, the bottom of the page definition, applicable to computer science. This definition below is just junk.\r\n\r\n''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.''\r\n\r\n\"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. \r\n\r\n''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\". ''\r\n\r\n* 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? \r\n\r\n* ''How does syntactical constraint rules differ from non-syntactical constraint rules? Lots of things have constraints and rules.''\r\n\r\n''Here is one of your own examples:''\r\n\r\n CREATE TABLE r_users_groups (\r\n\tuser_id INTEGER NOT NULL ,\r\n\tgroup_id INTEGER NOT NULL,\r\n\tCONSTRAINT r_users_groups_pk PRIMARY KEY (user_id, group_id),\r\n\tCONSTRAINT r_users_groups_fk1 FOREIGN KEY (user_id) REFERENCES users ON DELETE CASCADE ON UPDATE CASCADE,\r\n\tCONSTRAINT r_users_groups_fk2 FOREIGN KEY (group_id) REFERENCES groups ON DELETE CASCADE ON UPDATE CASCADE\r\n  )\r\n\r\n''Tell me, Costin, is that \"syntax\" or a \"structure\" or both?''\r\n\r\nTop, 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.\r\n\r\n''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.\r\n\r\nBecause 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?\r\n\r\n''It will go away when you prove ArgumentFromAuthority is practical and effective.'' \r\n\r\nNo, 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.\r\n\r\n''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.''\r\n\r\nNormal 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\".\r\n\r\n''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.''\r\n\r\nThis 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.\r\n\r\n''\"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.''\r\n\r\n----\r\nTo me, \"syntax\" is a string that does not have '''built-in separators''' between the \"elements\". When they are formally separated and the boundaries or isolation is directly encoded, such as put into a tree, then it is not \"syntax\", but a \"structure\". A structure isolates \"atoms\" of the expression, while a syntactical expression leaves that to the reader or parser.\r\n\r\nSyntax:\r\n \r\n  x = a + (b * c)\r\n\r\nStructure:\r\n\r\n\t* assignment (\"=\")\r\n\t\t* accepter (\"a\")\r\n\t\t\t* expression\r\n\t\t\t\t* operator (\"+\")\r\n\t\t\t\t\t* operand_1 (\"a\")\r\n\t\t\t\t\t\t* operand_2\r\n\t\t\t\t\t\t\t* expression\r\n\t\t\t\t\t\t\t\t* operator (\"*\")\r\n\t\t\t\t\t\t\t\t\t* [See AbstractSyntaxTree.]\r\n\r\n[This chart has been mis-formatted some how. I think somebody pasted it in here from some other topic without a lot of QA.]\r\n\r\n------------------\r\n\r\nRe: ''So \"statements\" and \"syntax\" are mutually-exclusive? Where is the math theory for that one?''\r\n\r\n* You don't need math theory for that, you just need to know your English. [from Costin]\r\n\r\n* ''Oh, that's a classic. English as a replaement for math. That's funny. You made my day. -- top''\r\n\r\n** Math is a dialect of many human languages.\r\n----\r\n\r\nCC 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\r\n\r\n''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.''\r\n\r\nUsing 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....\r\n\r\n-----------------\r\n\r\nTopMind - 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.\r\n\r\nI believe SQL has stymied my growth of TOP thinking. What do you recommend for learning and for practice? -- PeteProkopowicz\r\n\r\n''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''\r\n\r\nAren'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\r\n\r\n''I don't think arrays and tables are really that similar.''\r\n\r\n-----------------\r\n\r\n'''My Bulldroppings Watchdog Log'''\r\n\r\n''Where claims are validated or debunked''\r\n\r\nMoved to ChallengeSixVersusFpDiscussion.\r\n\r\n\r\n------------\r\nTop, have you looked at generating MSIL as a run-time target? Has anybody else who has Top's approach? I am looking for how-to documentation. -- PeterLynch\r\n\r\nIs 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.\r\n\r\nMSIL 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.\r\n----\r\n\r\nTop, 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\r\n\r\n''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.''\r\n\r\nNot 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.\r\n\r\n''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?''\r\n\r\n---------\r\n\r\nPageAnchor: Patterns\r\n\r\n'''On Design Patterns'''\r\n\r\nSome 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.\r\n\r\nAnother 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.\r\n\r\nThese also contain some of my opinions and comments about patterns:\r\n\r\n* DoubleDispatchExample (my examples are toward the middle)\r\n* PatternBacklash\r\n* http://www.geocities.com/tablizer/prpats.htm\r\n\r\n-----------\r\n\r\nRe: \"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\r\n\r\nArggg. Evidence please. Relational should get the credit, not OO. Most developers use OO-Lite and only give OO lip-service. -- top\r\n\r\n''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.''\r\n\r\n''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\r\n\r\nIf 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\r\n\r\n''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''\r\n----\r\n\r\nTopMind,\r\n\r\nI'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.\r\n\r\nIt 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.\r\n\r\nTell me, what do you think of it?\r\n\r\n-- DaveFayram\r\n\r\nI have found problems mapping directly from the database schemas to CrudScreen''''''s. 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. \r\n\r\nFurther, 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\".\r\n\r\n-- top\r\n\r\nCouldn'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 CrudScreen''''''s, 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!\r\n\r\nI'll borrow from a Rails tutorial to show you. Let's say we have a table like so in our database:\r\n CREATE TABLE `todos` (\r\n\t`id` INT NOT NULL AUTO_INCREMENT ,\r\n\t`description` VARCHAR( 100 ) NOT NULL ,\r\n\t`done` TINYINT DEFAULT '0' NOT NULL ,\r\n\tPRIMARY KEY ( `id` )\r\n );\r\nThen to make Ruby aware of it:\r\n class Todo < ActiveRecord::Base\r\n end\r\nNow we can get and display all these potential table items at will, with almost no code written!\r\n\r\n todo_items = Todo.find_all # get's all Todo items in Todos table.\r\n todo_items.inject( 1 ) { |n,todo| puts \"#{n}: #{todo.description}\" ; n+1 }\r\nWhich might display something like:\r\n 1: Feed the cat\r\n 2: Clean the cat's box\r\n 3: Clean the cat's box again.\r\n 4: Clean the cat's box yet again.\r\n 5: Shoot the cat. \r\nRails also uses Ruby's \"Needle\" framework to give DependencyInjection to the framework. You might like that, since it basically takes inter-class couplings and generalizes them then allows classes that need dependency mappings to do a table-lookup on them. It addresses one of your major problems with OO. \r\n\r\n''Does this have anything to do with ExpressionApiComplaints?''\r\n\r\nNo. It addresses your concerns about ProtocolCoupling voiced in your ChallengeSixVsFpDiscussion link. Specifically, you seemed to dislike code like this:\r\n def test_criteria\r\n\tcriteria_reader = MockCriteriaReader.new\r\n\treport = InvoiceReport.new(criteria_reader)\r\n\t.....\r\n end \r\nAnd to an extent, you're right. It's true that a user of such code would have to know and name the specific kind of criterion they want. That's no good, it kind of defeats the purpose. We want the code to be flexible. We know we want a CriteriaReader, but we really shouldn't have to say which one (although you might want to explicitly because of testing, like in this case).\r\n\r\nWhat DependencyInjection does is leverage some CollectionOrientedProgramming and some simple reflection to eliminate such scenarios. Instead, we'd see code like this:\r\n # Modified to make it clearer how DependencyInjection can reduce this kind of coupling.\r\n class ReportProducer < CriteriaUsingParentHoobajube\r\n\trequire_services :reporter, :criteria_collector\r\n\r\n\tdef make_report( criteria ) #\r\n\treporter = Reporter.new( criteria )\r\n\t@report = reporter.process\r\n\tend\r\n\r\n\tdef collect_criteria\r\n\tcc = CriteriaCollector.new # The method of criteria collection is decided by \r\n\t\t\t\t# the injection, which is a class name in a table. \r\n\t@criteria = cc.process # this would return the collected criteria (and store it in a local variable)\r\n\t\t\t\t# which could be passed to make_report or otherwise processed. \r\n\t\t\t\t# We can envision a returned array OR hashtable containing \r\n\t\t\t\t# the data, in which case CriteriaCollector is a function-object. \r\n\t\t\t\t# Otherwise .process would return some specific collection type.\r\n\tend\r\n end\r\n\r\nReporter and CriteriaReader are both locally defined constants that ''look'' like class names, but actually they're populated by the framework (and subsequently become like class names). You set up a service provider for Reporter and CriteriaReader (of which one possible implementation is a table), and when the Something class is created, it is automatically fed the correct class references for Reporter and CriteriaReader.\r\n\r\n''Tables are (or can be) a protocol. Calling it an implementation is like calling OOP and implementation of the concept. See WrappingWhatYouDontLike.'' TopMind, talking with you is like playing a game where your goal is to nitpick common definitions as much as possible. Couldn't you respond to the whole blurb instead of trying to blur the definition of table? It was perfectly clear what I meant in that sentence. [''LaynesLaw strikes?'' Not in this case, since we weren't arguing.]\r\n\r\n* I thought the definition issue was \"interface\", not \"table\". Now I am totally confused.\r\n\r\nDependencyInjection is pretty interesting when it's done automagically. It's probably not going to lead us to CollectionOrientedProgramming entirely, but we're not above cherrypicking some features. :)\r\n\r\n----\r\n{Other than \"wrapping away tables\", I am not sure what your general point is here. What are you comparing and what are you allegedly fixing? It is not clear. I don't want a definition battle, I want to know what practical time-savings or code-savings is being delivered by your approach.}\r\n\r\nWe got sidetracked. Initially, I was trying to see what you thought about Rails, and if you hadn't taken a look, you should. Ruby is maybe one of the few OO languages you might like. But anyways, we're talking about DependencyInjection now, which is a different topic. Now that we're clear on the subject...\r\n\r\nIt's not about wrapping away a table at all. We're leveraging a table to make our objects behave well. We're writing generic logic around protocols and using tables to control the specifics of it, to make our OO code more generic. This isn't exactly new, DataDrivenDesign as a principle has been around for years and years. But it is new in the sense that people are bringing it to an area of the code that is usually untouched by the data. \r\n\r\nIn some ways, you personally could view this as a victory for the TableOrientedProgramming camp. Even hardcore OO fans are using tables for simple things like \"which class does what\".\r\n\r\nBut that'd miss the point. I digress.\r\n\r\nAs I mentioned, in your Challenge #6 text, you didn't like the Ruby design put forth, because it required the caller to couple things in an unnatural way (even though that was just a unit-test). It's a valid criticism of many OO constructs. I thought you'd be interested in how people solved it (with a table, or something like it!). \r\n\r\nThat's the point. \r\n\r\n''I think I would have to see a working model comparable to my original version. You seem to be saying, \"here is my generic framework that is the pinnacle of indirection and wrapping such that anything can be made into criteria\". I would like to see that put to practice rather than just being given just a framework with lots of claims surrounding it (and perhaps put in the existing challenge #6 topic). Nor does it seem to take the user away from having to deal with \"Criteria readers\"''\r\n\r\nThis isn't about reproducing Challenge #6. I have neither the time nor the interest for something like that. I am merely responding to a paragraph in it in which you voice a very valid criticism of OO, and show you the OO community response. But I'm going to change the names in the code above and the shape slightly. I kept the names before for simplicity, but I shouldn't have. \r\n\r\nYou still might see a test in this format where you see something like\r\n rg.make_report( TestCriterion.new.process )\r\nBut that would be ONLY for explicit testing of that section of the interface. \r\n\r\n''What exactly is a \"collected criteria\" in your framework? What I did is make the \"criteria\" be a table. How that table is filled up is up the developer. They can create a front-end to fill it up, use a off-the-shelf table browser, copy the info from somewhere else, create a Java API to fill it up, it does not matter. I decoupled the \"criteria processing engine\" from the criteria filler-upper. The engine does not have to give a rat's behind about how that info got in there. Maybe what you are suggesting is that your approach can be made to use any data structure because you supply an adapter interface. But the table can also be as an adapter interface. If the original info comes in as nested arrays or a file, then just convert those into a table. (Some languages have built-in tables and some don't, but that is a language-specific detail.) It is simpler that way. I don't have all these intermediate \"factory\", \"writer\", \"manager\", \"collector\", \"fillerUpperConverter\" things that tend to build up in OOP. -- top''\r\n\r\nThe example as given doesn't specify what a criteria collector would return, it kinda depends on how you want to do it. The program would agree upon some kind of representation for criteria. The point of that class is to allow you to map multiple ways of loading the criterion. The same method (depending on which class was injected) can do different things, reducing the protocol coupling.\r\n\r\nIn this scenario, a table isn't a bad idea to represent the criterion (I imagine you use it as a way of making a group of rules, which you then combine to fetch the report request). You might see many representations based off of preference. My gut response would be an array of constraints, which can translate themselves to SQL (why not just go strait to SQL? Because I might want to change my representation later, or provide multiple flavors of SQL based on vendor-specific tricks). Then I'd write:\r\n\r\n def the_function_that_makes_the_report_via_sql_database( criterion )\r\n\t# ... Whatever\r\n\tquery = \"''SQL that begins the query here''\"\r\n\tcriterion.inject( query ) { |q,c| q << \" #{c.to_sql}\" } # Returns the query\r\n\tquery << \"''finishing SQL here''\"\r\n\t# ... Make the query to the product database with query\r\n end\r\nThat's one possible way, assuming a database backend (which may or may not be best, it depends on what you're dealing with and what kind of constraints-both social and technical-that your environment has). \r\n\r\n''It sounds like another battle where you say that SQL is the ugly stepdaughter to wrap/hide away in the castle basement while I say OO is the ugly stepdaughter to write/hide away. SQL is at least as portable as your specific language API's. Being tied to SQL is no more evil than being tied to Ruby. Either you use an existing query language, roll your own, or settle for something very weak and inflexible. There ain't no way out of it.''\r\n\r\nUmm, could you please, for 15 seconds, ignore perceived slights on SQL? You're missing the forest (DependencyInjection as a means to address one of your problems with OO-with a table, I might add) for the trees (minor implementation details in the example).\r\n \r\n* It appears to depend on what the criteria interface actually looks like. You seem to be making some wide assumptions about what can be wrapped away without worry.\r\n** AAAAHHHH! Stop it! Just drop the concern about the specifics of the return value of CriteriaCollector#process and focus on what we did to decouple the code. It has no bearing on the point at hand.\r\n* Note that I did not say it was unrepairable in OO. My write-up says this: ''\"If the interface user does not supply a specific selection for this attribute, then it would have a default. Jim does not even have to give up OOP to achieve this.\"'\r\n\r\n{I am having trouble making indented text here. There is a tab, but it ain't formatting still.} ''I'd say it's a wikitext parser bug, seems to happen when you mix bullet lists and indents. -- AnonymousGnome''\r\n\r\n''Further, the \"per field\" criteria table is '''not really tied to SQL''' (but borrows some of its idioms). It could be converted to other query language. The other parts (per-report) are tied to SQL because decoupling it would result in having to build an expression language and evaluator, which is reinventing the wheel.''\r\n\t\r\n------------\r\n\r\nMy feeling is that OO as we see it in Java/C#/C++ has been hyped to no end that some of us are finally seeing the cracks in the walls. Those aforementioned languages are horrible examples of OO because they constrain programmers with their static structural nature. -- AnonymousDonor\r\n\r\n''Does this mean that SmallTalk might make a comeback? Good. Debates with dynamic OOP fans are more interesting than static fans anyhow. \"Staties\" are obsessed with speed and making the compiler happy, like having to feed virgins to an ever hungrier volcano. Dynies usually \"get\" AdvantagesOfExposingRunTimeEngine. However, they just don't yet get how messy and inconsistent networks of maps and tree pointers (oop) are compared to relational. -- top''\r\n\r\n------\r\n\r\nMoved discussion to TopDefinitionForSyntax because this one is getting too long (I didn't create that topic, I would note).\r\n\r\n-----------\r\n\r\nIt appears that somebody half-plagiarized my anti-OO web-site:\r\n\r\nhttp://www.devx.com/opinion/Article/26776\r\n\r\nThere are too many things that sound similar to be coincident.\r\n\r\n''Unless (insert overly dramatic murder mystery music here) '''you''' are \"Richard Mansfield\". And you're 217! And... umm... the Phantom!'' \r\n\r\nIt is good to see knowledge spawned from this wiki.\r\n\r\nActually probably from: http://www.geocities.com/tablizer/oopbad.htm\r\n\r\nTo be fair, the similarities may have come from exposure to other writings I leave all over the web. He may have not known it was the same person.\r\n----\r\n\r\nBecause we risk polluting every single viable page on this wiki with your endless trolls, I'll start moving your conversational chaff here, every time it has nothing to do with the subject. Here's an example from EnumeratingRegularLanguages. Do with such extracts what you please, just don't come back polluting the original page.\r\n\r\n[from EnumeratingRegularLanguages]\r\n\r\n''Why is it a \"good test\"? It could be nothing more than a MentalMasturbation lab toy.''\r\n\r\nIt is a good test because it puts TOP in the \"grapes are sour\" position. Otherwise it is a nice example because it is non-trivial, it's short to define and intellectually challenging to solve, thus rewarding for the resolver. If Jayadev Misra and DougMcIlroy say it's a good example, it probably is. Yeah, you can argue that it may not have practical applications; however, DougMcIlroy is notorious for writing some nice piece of algorithmics that benefited millions of developers and end users worldwide, so if he wastes his time solving this exercise there must be some utility to solving such exercises. DonKnuth is also notorious for both inventing such useless exercises and solving exercises proposed by others.\r\n\r\nThe exercises in themselves need not have any immediate practical applications. Solving such exercises is a different matter altogether. And we won't waste time, space and bandwidth here to educate TOP about the benefits of solving interesting exercises.\r\n\r\n''You just admitted that it is MentalMasturbation in a long and round-about way. I won't dispute that it may be educational, but for testing the merits of a paradigm or language for the real world, it is nearly useless. -- top''\r\n\r\nDon't jump your horses top. You can call your very own arguments MentalMasturbation first, if that word gives you a hard on. \r\n\r\nIf it's educational for students, it is also good for evaluating at least a few aspects of paradigms and languages: how they address the writing of algorithmically complex problems. Yeah, it's not relevant for how good a language is for slapping data on the screen, that's true. But it wasn't intended to.\r\n\r\n''If it is a \"good test\" only for certain domains or kinds of problems, then why didn't you say so originally?''\r\n\r\nBecause unless you are irremediably retarded or, alternatively, in obnoxious trolling mode, this qualification is implied in all software-related discussions. \r\n\r\nLike it has been explained to you over and over again, there's no paradigm/programming language/software tool that claims to be the perfect tool for all the software problems in the world. Conversely, there can be no test case/example that covers every aspect of software development. Get it? Asking others to repeat this every step of the way and making a lot of fuss about it is just ConversationalChaff. \r\n\r\n''If being domain-specific or narrow-use is implied (I don't agree, but let's go with it for now), then it is a UselessTruth unless it gives hints about WHICH domains or uses it is applicable to. Otherwise it is like saying, \"Tool X can be good in some situations.\" From the reader's perspective, clearly it leaves a gaping hole as far as what and where. -- top''\r\n----\r\n\r\n** Why don't you use relational-like principles and put a marker on the topics you think are good (or keep your own private list), and then mirror them to your own personal wiki where the world can see your cleaner better wiki and grand brilliance and will eventually use your VIEW of wiki instead of this one. Filter, don't delete. Deletion is for the primitive pointer-heads. You don't have to piss off so many people to have your own wiki country the way you want. --- top\r\n** This intervention is very disingenuous. You have a hidden interest in creating a wiki where everything goes, so that even your rants are as valuable as any genuine piece of knowledge on SoftwareEngineering. Too bad, you won't get it that easily, especially not by cheap attacks on me. \r\n** The sin of deletion is far more evil than the sin of addition (assuming that is my sin) in my moral wiki book. At worse I am dumping trash on the street, not bombing it. And second, I don't propose an \"everything goes\" wiki. If something is shown objectively wrong, you are welcome to delete it (unless it is used as a training example to warn newbies of common gotcha's in reasoning). -- top \r\n** Just like the work \"syntax\" means to you something else , your \"objectively wrong\" means \"anything goes\". And FYI, nobody cares about your morals, top. -- CostinCozianu\r\n** ''Just because I was allegedly wrong on the syntax thing does not mean that everything I touch is wrong. '''If that is the best shot you have, I am pretty safe on other grounds'''. It is a minor side issue anyhow. Nothing pivotable depended on that. It was meant as a working definition for the context, not as a formal global declaration.''\r\n\r\n----\r\nTop:\r\n\r\nI moved some of the TQL stuff to separate pages,\r\nbecause it seemed like someone else had lumped it into your page.\r\n\r\nDid you move the TQL stuff back to this page? If so, please forgive me. I don't mind if you move it back.\r\n\r\n-- JasperPaulsen\r\n\r\n''I did not move it here. I have a suspect, though, but it is not polite to name until proven guilty.''\r\n\r\n----------\r\n\r\nPageAnchor: Examples_Complaint\r\n\r\n'''Regarding FP Examples and Applicability'''\r\n\r\nRe: \"[topmind] makes no apparent effort to extrapolate on his own what can be done with it beyond the (admittedly oversimple) example.\"\r\n\r\nYou are absolute right. I am unable to extrapolate to actual stuff I face in my domain. Either I just have some kind of mental block, or it is just not applicable to some domain (such as custom biz apps). It appears that if CollectionOrientedProgramming is available and/or built into the language, then many of those kinds of techniques are less useful because the language or COP tools tend to provide for very similar things already.\r\n\r\nRegarding HigherOrderFunctions, I have mentioned that \"eval\" and it's cousins can do similar things. FP proponents suggest that eval is slow and not as \"clean\" as HOF + closures. I will agree with the \"slow\" thing, but often speed is not the bottleneck in practice (as I encounter it). The thing is, '''in practice I don't need to use eval that much either'''. Maybe it appears roughly once every 1,500 lines-of-code. Why is this? One explanation is that I am simply unable to see a need for it. I look, but do not find. What I can I say? \r\n\r\nBut a more likely explanation is that generally the '''regularity found in toy HOF examples does not really exist in the real world'''. Those examples would fall apart if injected with the kind of irregularity that I actually observe. [See Example 1 below]\r\n\r\nRegularity is tough to find once you factor out the low-hanging fruit. This is what motivated me to start the LifeIsaBigMessyGraph topic. Based on observations of requirements and software change I have observed over the years, there is no Regularity Cop, no Tree Cop, no Limit-Dimensions-to-X cop that reigns in randomness from the real world. It really is a big messy graph. Order and patterns are sometimes found, but we don't know if they are fleeting or permanent. Any regularity in our code is mostly just imposing a UsefulLie in order to be able to deal with the real world as humans, '''not because the real world is inherently ordered'''. \r\n\r\nIt is tough to use abstractions to model something that is not really abstract by itself. Abstraction is about hiding what is irrelevant, but in the biz world irrelevancy is often fleeting and dynamic. Pressure to boost productivity or find a new marketing angle often drive managers to experiment with new ways to look at things. We are beyond the era of mass production (at least in the US), so what is left is digging new subtleties out of the environment to get a jump on the competition by taking advantage of things others have so far ignored. Thus, formerly irrelevant things become relevant.\r\n\r\nHOF's just assume too much independence of operations. Simple variations can be handled by eval instead, and complex ones tend to degenerate into multiple interweaving factors such that '''IF statements are more forgiving of change'''. Things \"degenerate\" in ways similar to why trees fall apart (LimitsOfHierarchies) on a larger scale. HOF's don't handle multiple factors very well because they assume neatly packaged behavior that can be and will stay relatively isolated. See EmployeeTypes for more on multiple interweaving factors.\r\n\r\nI don't like long-running nested IF statements either, but in many cases there is just no simple or stable regularity. That is life, not my limited ability to extract it. Even if I do find a pattern, it may disappear tomorrow as some new requirement throws a monkey-wrench into my formally nice abstractions. Sometimes it is helpful to break them up to give an artificial division in order to deal with things as smaller chunks, but it is still rather forced and contrived. It is the artificial UsefulLie described above: it is for human sanity, not necessarily to model the actual world and its change pattern.\r\n\r\nThis is why I keep asking for examples in my domain. I want to see solutions that relate to real patterns that I observe; not phony ones or ones that are applicable to writing compilers. I don't give a bleep about compilers and neither do millions of other programmers, and least not for real work (there are many compiler hobbyists). If FP works great for some domains, that is fine. I don't question that. But '''the implication is that it is generally affective for all domains'''. I wish FP'ers would clean up the scope of their claims and bragging. The FP GoldenHammer talk is getting tiresome. I've heard a similar tune from OO zealots for too long. But I am glad to see FP'ers challenge some of the OO'ers. (Being an almost lone critic of OO was getting old.) But the FP'ers are making the same mistakes all over again by over-extrapolating dogma and mistaking success in some areas for general-purpose success. I guess it is just the HolyWar fad cycle.\r\n\r\n----\r\n'''Counterexamples:'''\r\n\r\nCounter Example #1 in Ruby, using ActiveRecord. \r\n''Purpose:'' Using a HOF as a lexical convenience to iterate through a collection of database records.\r\n''Notes:'' The comment 'You care from here on' shows where the simple scaffolding ends and the real HOF work begins. Now, the key thing to understand about this example is that the method 'each' is that it was defined and written literally years before the \"ActiveRecord\" class came out. It is a HOF that is inherited by collections. By using an HOF, the same code can iterate across any kind of thing that includes the \"Enumerable\" base.\r\n\r\n ''# Sets up a ORM to the Customer table, assume customer has some fields''\r\n ''# and a group of addresses.''\r\n class Customer < ActiveRecord::Base\r\n\thas_many :addresses\r\n end\r\n\r\n ''# Sets up an ORM to the Addresses table, assume address has a fields:''\r\n ''# street, number, zip and city''\r\n class Address < ActiveRecord::Base\r\n\tbelongs_to :customer\r\n end\r\n\r\n ''# You care from here on, the previous code only told you what the object relationship is.''\r\n my_cust = Customer.find_all\t''# Finds all customers, this was in error before, WikiAteMyEdits ''\r\n my_cust.each { |customer|\r\n\tputs customer.name + \": \"\r\n\tcustomer.addresses.each { |address|\t''# Note the nesting of HOFs, this is harder to do''\r\n\t\tputs \"t #{address}\"\t\t''# in eval-based systems.''\r\n\t}\r\n\tputs ''# Puts an empty line.''\r\n }\r\n''# End example 1''\r\n\r\nThere you go top. A simple example of how HigherOrderFunction''''''s and Object Orientation can make everyday operations easy. Making these operations simple and generic without HOFs and OO is actually very tricky. Allowing them to nest properly is also kind of tricky with pure eval (although you ''can'' do it, I won't deny that). What's neat about this is that you get simplicity (this is as easy as this kind of code gets) and it's an everyday operation. \r\n\r\nIf you want me to extend this example further by showing how HOFs could be used to swap \"view\" logic trivially in the inner loop, I can do that too. But, it shouldn't be too hard to see from this example.\r\n\r\n-- DaveFayram\r\n\r\nIf I am interpreting this right, you are displaying a one-to-many relationship. Also, if you are only displaying one customer, you don't need the outer loop, so I am assuming the number of customers displayed is to be open-ended. Here is how I typically do it (JavaScript-like pseudo-code where \"&\" is concat, I hate \"+\" for concat): \r\n\r\n // Approach 1\r\n rs = query(\"select * from customer natural join addresses where \" & criteria);\r\n prev = '';\r\n while(row = getNext(rs)) {\r\n\tif (row.custID <> prev) {\t// description only if different\r\n\tprintln(row.custName & ':');\r\n\t}\r\n\tprintln(\"t \" & row.address);\r\n\tprev = row.custID;\r\n }\r\n\r\n // Approach 2\r\n rs = query(\"select * from customer where \" & criteria);\r\n while(row = getNext(rs)) {\r\n\tprintln(row.custName & ':');\r\n\tadrs = query(\"select * from addresses where \" & criteria);\r\n\twhile (adrow = getNext(adrs)) {\r\n\tprintln(\"t \" & adrow.address);\r\n\t}\r\n }\r\n(Note, natural joins are not supported by many RDBMS, but I use column naming conventions that usually make an explicit join almost as short, if given a choice.)\r\n\r\nI am not sure what the actual pattern of repetition is, so I don't know what to make \"generic\" in this example.\r\n\r\nGenerally report writers (like Crystal) are used for fancier versions of one-to-many reports, which deal with this kind of thing declaratively for the most part. Each \"level\" is a \"band\" in the IDE. ColdFusion has a built-in mini-framework for doing this also using a \"group=\" attribute of the \"<output>\" tag.\r\n\r\n-- top\r\n\r\nTop, you're right. WikiAteMyEdits somehow. I added the nesting because I wanted to make it harder for eval to duplicate without sacrificing a real-world feel. I have corrected the offending line of code to be \"find_all\" rather than \"find(1)\". \r\n\r\nNow, note that the code I've presented has the line count of your shortest example, but with fewer symbols (of course, that's a rather loose count, is '{' a symbol worth counting? Depends on the context.) Also, if you read the Ruby version aloud, it more closely matches an English definition of what the code does. \r\n\r\n-- DaveFayram\r\n\r\n''For one, the difference is minor. Second, most of the bloat in mine is caused by SQL and you did the equivalent of the join before the portion you are comparing. Thus, it is a bit misleading to count that. Second, it looks like somebody did some database reinventing in your example. Note that I agreed somewhere that FP can reduce loops, but only about 5 to 10 percent of most of my code is typically devoted to loops. Thus, even if by chance you reduced all loop sizes by 50 percent, the total would not be much more than 5%. As far as \"English like\", that is debatable and marginally important in my opinion. I don't necessarily want my code to be too \"English like\". And, you seem to have a lot of wrapper classes. I could make wrapper classes to shorten the query stuff also. Further, letting Ruby do the join instead of the database is sort of reinventing the database. With larger data-sets those kinds of things become performance, concurrency, and integrity issues. -- top''\r\n\r\nThe class code above the \"You care from here on\" comment was ''strictly'' so you knew the relation. The fact that it's also working code that does what is necessary for the database linkage is just me boasting, I guess. Either way, this code interfaces directly to a database. Ruby does no \"re-invention\". In fact, this Ruby code knows several dialects of SQL and how to speak them efficiently. So I can start out developing in SQLite, then move to MySQL when I deploy, then move to Oracle when I get too popular for my own good. \r\nSo there is no \"re-invention\" going on. Ruby just binds to it and lets me speak more naturally. If you look on my UserPage, you'll see that you can still use SQL when you come across a query too complex to trivialize in the above fashion (but there are precious few). \r\n\r\n''But then you have a DiscontinuitySpike where you have to undo and then rework your code to use SQL instead of Ruby for the task. If you start out with SQL, then you don't have to delete all the Ruby code that was not quite strong enough.'' Top, there is no DiscontinuitySpike. You need to \"rework\" any code. You can mix-n-match. It's easy to see where you need to use SQL, and where you don't.\r\n\r\nAlso, I wanted to point out. If you get a 5% average reduction of code size from these \"tricks\", on a medium-size project of 500000 lines (and this is '''medium'''-sized, not large), you just saved yourself 25000 lines of code. If you came up to me and said, \"Hey, I have an easy technique that works within several programming paradigms, allows your code to read more like English without being overly verbose, and will save you 25000 lines off your half-mill project. Want it?\" I'd take it, and never look back. That's the kind of holy grail that software engineers are always on the lookout for. So don't tell me that in a 30 line example, 5% is insignificant. No serious program is 30 lines. Hell, par time I work on what I consider a small project with a LMCO group, and it's still 200k lines. \r\n\r\n''If you factor in DiscontinuitySpike (above) the 5% may be erased. Plus, there is the training cost. SQL can be used with many languages. Having to learn a new collection-oriented API for each new languages is a violation of OnceAndOnlyOnce. Note that in this specific example, I don't even agree with 5% because your \"join\" is either done elsewhere or wrapped. I can wrap simple joins also to reduce code. '' \r\n\r\n* I think you misunderstand OnceAndOnlyOnce here. There is no extra configuration. The extra relations (like join tables) need to be made explicit in at least one place anyways (otherwise it's a massive pain maintaining a database-centric app after a handoff). What I think is best is how you're focusing on the database joins and not on the HOF part of the code, but even if you did... you're right, later it generates an SQL join. It's library code, doesn't matter. Shall we count the cost of your FoxPro library code?\r\n* ''I am not sure what you mean in the first part. As far as the libraries and counting code is concerned, you are right that libraries complicate the counting. But the above is more like one would find in ASP or PHP, not FoxPro (PHP only assuming somebody made some API's that stored the result set pointer with the row array).''\r\n* Libraries are not part of code counts. Even if they did it'd be a net win. If a library takes 5x the code to make a complex operation trivial for the caller (say, 50% as big and less error-prone), you'll end up with a reduced code count in a non-trivial project. \r\n* ''If libraries are not counted, then counts would favor languages with huge or domain-specific libraries (in that domain). We couldn't tell whether the count was lower because of bigger or domain libraries or because of FP. Plus, I think it is unfair to make a big distinction between custom libraries and those packaged with the language itself.''\r\n* A library is code you don't have to maintain. So it's free code, and doesn't go in code counts. You're absolutely right that this means very specific tools win big because of this. That is actually a feature, not a problem. The point of code count comparisons is that we get some idea of the effort involved. It's not a very good metric, but if a 50 line program is 1 line in another language, then you should use that other language unless it's not feasible due to deployment or customer requirements. This is actually one of the reasons people like Lisp so much. They make DomainSpecificLanguage''''''s for problems as they go, with very little overhead in Lisp. So their code-count shoots down over time, because their DomainSpecificLanguage lets them do repetitive operations clearly and with little code.\r\n* ''But custom sub-languages are essentially a custom library, which you wish to count. Anyhow, I don't see how sub-languages relates to the topic. If I make a library that simplifies common SQL idioms, my code would be smaller.''\r\n* In some languages, the difference between a sub-language and a library is nil. These languages even include big names like Python, Ruby, and Lisp. I don't mind counting them or not counting them. When I count code, I count how much I have to write and maintain. So if I write a custom library, it goes in the count. If I download it and it has an active developer/maintainer community, I don't. \r\n* ''Without further details about what where the repetition is, it is hard to know what would be library-able here.''\r\n* Well, the fact that there is an \"each\" should give you at least a small hint. Can you really not extend that any further?\r\n* ''You FP fans are overly concerned with loops. My code does not have that many loops. The biz apps I face are chalk full of funny arbitrary-looking business rules, not bucketfuls of loops.''\r\n* You know what the sad thing is, Top? You don't seem to realize how bad you portray your skills when you say things like this. You really don't. That's why it's so hard to keep a straight face when talking to you.\r\n* ''I don't care what your face does, just produce shorter code or go away.''\r\n* By your own admission, I have. \r\n* ''Only about 5% for loops if some itchy caveats are ignored. Hardly a slam dunk.''\r\n\r\nBut even saying that, I think the code reduction is more significant in practice. I have a peer in my Weather group. We each wrote different applications to edit different kinds of weather data. I edit weather balloon data, he edits (very advanced) radar-based wind profiler data. My program ''does more'' to data (radar-based wind profiler data is very accurate and less prone to error compared to the balloon data). My code is about half the size of his, and the main difference in our style is I use functional tricks in C++ and he doesn't (he uses the Visitor pattern more though, and he uses singletons a lot).\r\n\r\n''Is this comparing Ruby to C++? Dynamic languages almost always have a smaller code-size count than static ones. I once started writing a hobby MIDI music editor in C, but later decided to convert most of it to FoxPro, and achieved something like a 5-to-1 code-size reduction. And, I was not even trying to write compact code since it was for me only.'' \r\n* No. I'm just saying when I apply functional techniques to a similar field where someone doesn't, my experience shows significant code reduction. \r\n* ''If it is different languages, how do you know it is not a language difference or a programmer sytle difference? If he uses OO visitor, then he probably likes bloat anyhow :-) I cannot really tell without seeing the code.''\r\n* We both used C++. I apply functional and OO techniques.\r\n* ''Well, I cannot inspect it. Maybe there are non-FP shortcuts that you both didn't try. In my long-running OO debates, often the presented example bloat turned out to be the fault of the particular language, not the paradigm itself.''\r\n* No you can't. You'll just have to pretend that at least one person in the world isn't aggressively lying to you. We used the same language, same libraries. The main difference is that he never used functor-related patterns and I did. You can argue C++ adds bloat (and I'd agree wholeheartedly), but since we both used it that seems to have been removed as a factor.\r\n* ''I am not necessarily accusing you of lying, I just don't know the whole story without seeing actual code side-by-side. Anecdotes point every which way and have proven misleading in the past to me. There are a lot of ways to bloat up code. Note that C++ does not have Eval() either.''\r\n* You don't need to accept it as true. ''However'', lots of people have evidence like this. It suggests that maybe (just mayyybe) you should try it yourself and verify it. If it doesn't work, oh well. You lost maybe a day or three of productivity. If it does work, you stand to gain many days back. It's a gamble, but the odds get more favorable for you every time you hear another anecdote. \r\n* ''GoldenHammer anecdotes are as common as air. I even get emails from fans of APL-derived languages claiming tons of simplification due to its built-in collection-handling.''\r\n* I think at some point the sheer number of qualified engineers saying, \"This rocks!\" should pique your interest. I try to listen to the buzz of my peers. Filtering is of course in order, but at some point you have to go, \"This is reaching critical mass, maybe I should try it instead of being a stubborn mule about it.\" \r\n* ''It is more like, \"A is great! It even walks my dog!\", then \"X is great!\", then \"Q is great!\", \"D is great! It allows my dog to walk me!\"....''\r\n\r\nIn the real world, that's about as close a comparison as you can get. \r\n\r\n-- DaveFayram\r\n\r\n''Another thing, it appears that your approach resembles my second approach as far as how it \"hits\" the database. The first approach I used is generally much more efficient network-wise because it gets the result once rather than keep hitting the DB for each customer. [topic link to be inserted when I find it].'' \r\n* Why TopMind, are you saying that performance matters? How cute. How many times have you told us that performance is irrelevant? That approach is plenty fast, people use it all the time. If I need it faster, I'll make sure all the CGI serving processes are on the same server as the database. I dare you to claim this doesn't scale. :) \r\n* ''Network performance tends to be a bottleneck in biz apps far more often than executable run speed. Nested queries like that are generally considered \"bad form\" and will get you labeled as a newbie by DBA's. It is often not a big deal, but something to watch. It is a technique that does not scale well. For example, if there are 300 customers, then the bunched approach makes only one query to the DB while the nested approach makes 300. That makes a big difference on a busy network. If they are closely connected as you mention, it may not matter much, but still limits the options available to the box and network config people because they must always use a close connection. Besides, it does not cost significant code to do it the \"right\" way. I agree that code simplicity usually trumps performance, but sacrificing performance in this case does not buy us significant code simplicity, and perhaps none. I've shown you can do the same thing with about the same amount of code and get the single query. It is just that you seem more comfortable with your approach for some reason. That is a psychology issue.''\r\n* So, you feel fine using eval, but heaven forbid you stress the database. I'll write the app first. If the network bottleneck becomes and issue I'll fix it. Just like you'll write your app, and if your horrendously inefficient code ends up being a bottleneck, you address it. You've dismissed this kind of complain ''so many times'' I'm amazed you have the audacity to say that it doesn't scale. However, if it really bothers you, it's trivial for me to Record.find_all and then used the cached data to infer my relationships locally. Despite that, many professional and busy websites use this approach without problems. \r\n* ''My experience is that network is the bigger bottleneck so I focus on it more rather then optimize after the fact. And like I said, it does not cost noticeably more code, so there is not a big tradeoff taking place. That optimization is free. And, I can assure you it is frowned on in the industry in general by many. There is a wiki topic on this, but I still cannot find the $@#! thing. WikiNeedsSearchTerms.''\r\n* Since the database access part of the code isn't what we're focusing on in this discussion, I think we can leave the performance of this out of the equation. Certainly, it is no slower than the equivalent code written in eval() (indeed, it should be faster). It's fun to see you pimp the same \"That won't scale.\" argument that J2EE-lovers love to pimp, even if it's in a different form. \r\n* ''Transferring info or requests between applications (such as Ruby to RDBMS) is usually going to be far more expensive than an eval(), which stays in a single language/app-space. Plus, I did not use eval in this case. It is no big deal but a minor factor to keep in mind. Nested queries like that are usually the first things put into optimization target lists when performance problems appear and a majority of DBA's will give you the evil eye for doing such often.''\r\n* What on earth are you even talking about, Top? You just jumped to step 1 of your argument algorithm. Unless your interpreter is in the same memory space as your database, you're going to get the same cost when using a socket to talk to a database. Eval offers nothing here that a HOF doesn't, unless you count more overhead to parse the data at runtime in a new context. I can't believe you're arguing for optimization here. You're making an utter fool of yourself. Please focus on the HOF portions of this and stop harping on minor SQL foibles. You wanted a real life example of using HOFs, and I gave you one. You're doing that thing I said you'd do, \"Pick a random, insignificant facet of the code and return to step 1, changing the subject.\" Stop it. It's rude.\r\n* ''You appear to be the one focusing on that, not me. Twice I've said it is not that big of a deal. I am curious, if the DBA or architect ordered you to remove the nesting, could you find a suitable replacement? I have seen it happen to other developers who've done that. One guy's name was something like Johnson Sushi. I ended up helping him do it and achieved a 7-fold speed improvement. I've never seen that for Eval(). I take that back, it happened once in the 286 days with eval. MooresLaw does not seem as applicable to networking. Whether removal of nesting is the \"right\" choice, it is generally considered a \"best practice\" and developers are expected to follow it. I've even seen it mentioned in a cert study guide. Ruby is flexible enough to bend with such requests though I hope. Personally, I am not going to write nested loops like that. '''It makes one LOOK bad''' regardless of the actual merits. It is not that I care too much about popularity (as you can see by my wiki anti-following), but if the alternative is not much different in cost, I will go with the flow.''\r\n\r\n----\r\nHey TopMind, as far as I know, your web site has no content about WebServices and ServiceOrientedArchitecture. What you think about them?\r\n\r\n''KissWebServices. If it is within an organization, as you probably would have guessed, I would generally recommend going with a RDBMS.''\r\n----\r\nWhat you don't realize is that you will reinvent OO programming over and over again in your code. Have fun. \r\n\r\n''This has been suggested before, but hard to check because NobodyAgreesOnWhatOoIs. The concept of treating function dispatching similar to data dispatching is a pre-OO idea, I would note (DataAndCodeAreTheSameThing).''\r\n----\r\nIt seems to me that C2 is now in its \"fourth age\"\r\n\r\n1. Patterns\r\n2. XP\r\n3. Philosophy and Religion\r\n4. TopMind\r\n\r\nIt's just everywhere, TopOnThis, TopOnThat ... Top, get your own Wiki, and Ward might even make it a SisterSite, but for godsakes top, just leave it alone. We know where you stand already, and we're sick of seeing it repeated everywhere we go. And to everyone else sick of him: just don't feed the troll. Just let him ramble in silence. Please. -- ChuckAdams\r\n\r\n''Every philosophy is considered a \"troll\" until books such as \"Learn TOP in 21 Days\" start popping up. Then it is \"best practices\". This happens because there is not enough \"science\" in computer science. This field is like YoYo's and Hulahoops: fads fads fads. TOP is as good or bad as any other cockamamy fad. See:''\r\n\r\nhttp://www.geocities.com/tablizer/science.htm\r\n\r\n''By the way, it is NOT me creating \"TopOn\" topics. That is part of Costin's EditWar intimidation methodology.''\r\n\r\nNo, that is Costin trying to make it obvious how many pages you are destroying with your continuing arguments from ignorance. If you haven't studied a topic, just keep your trap shut, you don't know what you're talking about anyway.\r\n\r\nWould you rather prefer to clean up your ThreadMess''''''es by deleting them?\r\n\r\n''Is that how you treat all the other threadmess?''\r\n\r\n* There are no ThreadMess''''''es quite like yours, Top. Yours are particularly uninformative, gratuitous and sprawling.\r\n\r\n* ''That is usually the cost of having unpopular opinions (even right ones). Yes, I do blame it on my adversaries. They are against SelfStandingEvidence and pro-ArgumentFromAuthority. In my opinion, that is the main cause of the mess, NOT me being bad, manipulative, or wrong. I generally '''don't have the same problems with those don't hold those evidence views.''' ''\r\n** I try to evaluate your views neutrally, but I must confess that I am often unsure what you are driving at. I know that one of your long-term themes is something roughly like \"OO is overpopularized and is not a panacea\", and when I paraphrase like that, I agree, '''but''' I think OO does have benefits, without being a panacea, '''and''' I'm not sure you'd be happy with such a weak paraphrase. Similarly, I agree that some problem domains cry out to be modelled as tables, or in my own thinking, as multi-rooted trees, sometimes covering the same graph - but I'm not sure you'd like that paraphrase. And that's on one of your most famous topics. In other of your commentaries, I'm just not sure what your point is. And I'm not one of your \"adversaries\", although once in a while you act like I am (habit, I'm sure :-) -- DougMerritt\r\n\r\nPageAnchor: \"Greymaster\"\r\n\r\nOne of the reasons that I seem to get '''dragged into long debates''' is that the other party will spot something and make an issue out of it. Example: \"What? You think try/catch blocks are bad? This is yet more evidence that you are stupid and have a wimpy domain. If you are stupid about try/catch, then why would anybody trust you on this topic?\" I make the mistake of taking the bait and then start a long debate on try/catch to try to defend myself. Then during the try/catch debate some other similar thing comes up, and I then let myself get pulled into that. I am not saying that this is good or bad here, but seems to be the pattern that causes the alleged ThreadMess. On the whole I feel that I make pretty good cases that what my adversaries feel are black-and-white issues are really grey. I am the '''Greymaster''' :-) -- top\r\n\r\n* What the hell's wrong with try/catch blocks?!?!?! :-) -- DougMerritt\r\n\r\n* '''Don't you tempt him''' to start a TopOnExceptionHandling. You can surely manage to do something with error codes and if/else, don't you? Therefore try/catch is redundant.Since he claimed that higher order functions and closures are also redundant when all one needs is to eval strings, he needed supporting evidence to show that language designers are incompetents and are in love with redundancy. Now trying to convince him otherwise is an exercise in futility. -- Costin\r\n* I was just joking! But hey, as long as it is in fact a page with Top in the title, as opposed to being part of an otherwise purely informational page, no big deal if anyone wants to debate him, right? -- DougMerritt\r\n* ''There is already AvoidExceptionsWheneverPossible. I didn't create it. See also SeparateIoFromCalculation.''\r\n------------\r\n\r\nHere is my interpretative summary of how the TopOnPreparedStatements debate is going:\r\n\r\n* Top: Here is a way to use your own wrappers to protect from SQL hacking...\r\n* X: Prepared Statements (PS) are better because they keep values separate from commands so that hacking the values will never spill over to command interpretation.\r\n* Debate about complexity of PS approach versus alleged extra security for complex dynamically generated SQL.\r\n* X: Some drivers support named parameters for SP's.\r\n* Top: That may limit portability of code and some shops still don't have named parameters.\r\n* Somebody suggested that data and commands are not really separated after all, that their driver eventually mixes them when it sends the values to the DBMS.\r\n* Top: If that is the case, then our approaches are no different from a security standpoint\r\n* X: PS's are still better because their code is written by expert driver writers and better tested. \r\n* X: Here is a link to some OSS source code for such a driver...\r\n* Top: Why not just take that source code and use it for our own wrappers then? One can copy their alleged quality routines.\r\n* X: It is still better because it is different SQL than what the application sends. It is internally generated SQL.\r\n* Top: Why does that make a difference? The hacker tweaks the values, not the rest of the SQL anyhow? \r\n* ...\r\n\r\n-- top\r\n\r\nYes, some of the debaters are not making very good points, or making them poorly. My suggestion: Forget about the fact that others have written layers that do what you propose. What you propose isn't bad, if done right, and people do it all the time. The key point about prepared statements is that ''often'' (not always), their implemented by the DBMS itself in ways that address security concerns (which can certainly also be done in other ways), and that improve performance (which can't typically be done from outside the DBMS). So they have an important place in the toolbox.\r\n\r\nFurther suggestion: Remember that you don't have to respond to every troll. It's OK to admit when you've learned something you didn't know before or when you've made a mistake. (Which you do sometimes, but usually spoil with a \"yeah, but...\", creating another series of troll-sized openings.)\r\n\r\n-- DanM\r\n----\r\n'''Discussion about ResponsibilityDrivenDesign''' (moved here from OoIsAnthropomorphic)\r\n\r\nI wish to better understand how ResponsibilityDrivenDesign fits in here. I am not here to bash it, just understand how it applies here. If your boss says, \"Bob, get me a cup of strong coffee as soon as possible\", then that is a responsibility-based command. However, to me it is better abstraction to simply ask for a cup of strong coffee, assign a priority, and let something else take care of who or what actually does the task. \r\n\r\nI realize that reward and punishment systems are needed in the real world, but this does not apply to most software today. We generally don't need/use that technique in software. (If later we find out it makes a great technique, that is great, but that is not today.)\r\n\r\nTo me, responsibility ignorance is \"better abstraction\" because it is no longer a high-level detail. It may require noun-2 and noun-7 to carry out the task today, but we may want to change that to noun-4 and noun-9 tomorrow. It should be an implementation detail because it can. Abstraction is about removing unnecessary details for a given need. Well, \"who\" is an unnecessary detail. Using the above analogy, the boss could say, \"Staff, get me strong coffee. It is top priority\". He does not need to think about whom, but only ask for what. It is unnecessary to specify a \"who\" (if reward systems are not a factor).\r\n\r\nYou could perhaps convince me that modeling the human world makes it easier for some people to relate to software systems built on that principle, but to me it just seems anti-abstraction. Why model software around the limits of humans? I want to transcend human limits if possible. I don't want to be bound by details that are necessary for the human world but not for the software world. If you feel that familiarity outweighs fuller abstraction, I can perhaps agree with that, for I probably do the same in other areas. But I want to clarify that this is indeed a sacrifice being made.\r\n\r\n-- top\r\n\r\n''Responsibility doesn't seem to matter when you use a system. Its importance is more obvious when you are building a system. It would be nice if we could ask computers to perform tasks for us without teaching them how first.''\r\n\r\n----\r\n\r\nA response to IfYouDontLikeItYouDontUnderstandIt:\r\n\r\nIn your particular case this is a misrepresentation. It's relatively simple to explain a viewpoint on Wiki and indeed it's been done when arguing with you many times, but more ever more precise and detailed explanations you demand often depend on knowledge you don't have and aren't willing to obtain. This is a classic HostileStudent trick. You can explain relativity in a paragraph to someone who just wants to know what it is, but when explaining it to someone who's going to take issue with every detail and demand so-called SelfStandingEvidence the short version won't be adequate - if, indeed, anything would be. Further, in your case, it's much more \"if you understood it, you could present a reasonable counterargument\", rather than \"if you understood it, you would like it\". -- ChrisMellon\r\n\r\n''Generally you guys use Argument-by-Elegancy. What exactly does FP improve, for example? Why can't I get a strait answer? Some suggested signif code size reduction, but the less fanatical wanted to distance themselves from that. If it improves maintainability, then give some change scenarios and show how those change scenarios can be made with less line, block or named-unit changes (see ChangePatterns). We can '''count''' that. GoodMetricsUseNumbers. Please tell me why FP (or any paradigm) is immune? Why is it allegedly special? -- top''\r\n\r\n* Now, TOP, this is one more instance of your dishonesty. A straight answer has been given to you. Yet you whine \"Why can't I get a straight answer?\". Because you're a troll, that's why. Because despite your repeated claims to innocence you walk and quack like a troll. Therefore you are a troll. -- Costin\r\n* ''Let me ask you something. Out of the 20 or so FP examples or arguments, what are the '''top two''' in your opinion? Just pick two. That's all I am asking.''\r\n* Before you ask any further troll questions, I need you to state if you were given or not a straight answer, specifically by me. And in case you were given an answer what was your response.\r\n* ''You mean a strait answer on why FP is allegedly immune from GoodMetricsUseNumbers? No, I have not gotten a strait answer to my recollection. -- top''\r\n* Don't try to change the subject, top. You said \"What exactly does FP improve, for example? Why can't I get a strait answer? \". I told you, in quite a few occasion exactly what FP improves, Do you or don't you remember. Now to such an idiotic question like \"why FP is allegedly immune ... blah, blah\", you won't get any answer other than that your dishonesty will be exposed.\r\n* ''I honestly didn't know that was the phrase you were referring to. There were multiple candidates to match your pronoun. As far as your FP examples, they basically take the form of \"if you do X, then FP can simplify it\". The problem is that most of your X's are not necessary under my style of programming. Thus, I will agree that under some circumstances FP will save code. Any paradigm has areas where they help code-size some. If you mean a numeric metric besides code-size, then I missed it. Some of you seem to be shifting back to the elusive \"elegancy\" metric. I am not sure what your stance is. -- top''\r\n\r\nJust to be clear - I am not an FPer (although I use some FP techniques). The \"you guys\" are not a coherent group. I'm speaking only for myself above. -- ChrisMellon\r\n\r\n''Lack of signatures has made it hard to keep track of who shares what opinions.''\r\n\r\nI agree - I'm trying to be diligent about signing, but when blocks get broken up into threads they get lost, and then when other people interject.... -- ChrisMellon\r\n\r\nTop, the above is the kind of reputation I mean, and one which I think you would do well to overcome, by making an effort to project the right kind of appearance in arguments. You may believe yourself to be e.g. open-minded, reasonable, not a HostileStudent, to argue fairly, etc, but even if you are all such things, you need to do more to project the appearance of being such. Doing so would eventually sharply raise your average reputation with the average wikizen. -- DougMerritt\r\n----\r\n''Maybe we both have our own problems. Maybe I won't bother to learn \"proper\" CS vocab, and you won't bother to articulate your vague but strong feelings about why something is significantly better using numeric metrics. The thing is, numeric metrics are needed with our without my alleged vocab understanding. Verbal mantra and philosophy don't cut it. The existence of such metrics are '''outside of me'''. If you believe your techniques are immune to numeric metrics (described above), then we have a fundamental philosophical disconnect. '''Numerical metrics keep scientists honest''', or at least clear. If you claim objective benefits, your obligation is to produce numeric metrics. If my vocab becomes an issue in evaluating such metric results, then you have a legitimate complaint. But until that happens, the ball is in your court.''\r\n** Top. Look carefully at my name: \"DougMerritt\". Your rant, here, is on a topic I have never discussed with you, but you are addressing it to me. I didn't realize until now, that you don't really pay attention to anyone's name. No wonder there have been all these times I said \"Top, why are you reacting that way? Look, you know me, you '''know''' I don't give you a hard time like some others do, I have at least some sympathy for your position\"...but no, you never knew that, did you? Because you never even noticed the difference between me and other people you talk to. How very sad for you. Because people do vary. It's not just you against the whole world. Well, it doesn't have to be, anyway. It's you against the world if you '''insist'''. -- DougMerritt\r\n** ''You may be right. Sometimes in the heat of battle I didn't separate the opinions and responses very well. I will make an effort to pay more attention to that in the future. Also, the way anonymous is often mixed in with signed responses can make it hard to know if something is a continuation or a new person. -- top''\r\n** True. Thanks. DeleteWhenCooked. -- Doug <last edit early Apr05>\r\n\r\n* Tops Metric Rule #1: If you cannot put numeric metrics on your claims, then they are probably subjective.\r\n\r\n* Tops Metric Rule #2: Numeric metrics are necessary, but not necessarily sufficient to provide good evidence. Numeric metrics can be bad.\r\n\r\nNote that even though numeric metrics may not produce agreement, they can be very helpful in narrowing down where the differences are, such as disagreements over the probability of some change pattern happening. In other words, they can be a good communication tool even though they are not necessarily a perfect communications tool.\r\n\r\n-- top\r\n\r\n[Long rant formerly here deleted. No point.] -- ChrisMellon\r\n\r\n'''Tough''''''Mind''' are you still stopped from editing (e.g. no visible keyword) these days? And are you ever locked out completely without read ability like I do? -- dl\r\n\r\nYes. It comes and goes. -- top ''completely blocked?''\r\n* If you get locked out completely for more than 10 minutes and if you are behind a firewall, I have an explanation. -- dl\r\n\r\nAlso I have marked Have''''''EyeBeenBanned for delete. I hope '''Top'''doesnot'''mind'''.\r\n\r\n----\r\n\r\n(Moved from the highly trimmed InternationalUiExample)\r\n\r\nI actually have a question for you. Do you, right now, in your professional development work where you get paid to make applications, presumably using TOP, use a database to store everything, totally eschewing files? Have you created your own toolchains for the creation of applications? What did you use to create these toolchains? Are these toolchains perfect? If you can't answer any of these questions to my satisfaction, then you've got a hell of a lot of nerve telling anyone that their tools are inadequate.\r\n\r\n''If it is a single-person project, then a database is not justified. If it is a multi-person project, then I think it would be justified and at times others have even agreed with me to some extent. However, because files are still in styles (bad rhyme), it is too much lobbying. Note I am often discouraged from using TOP in practice, and have cut way down on my lobbying. People who go with the flow have better careers, I observe. TOP was far more tolerated in the ExBase/FoxPro days. The industry evolved backward. \"Radio killed the video show\".''\r\n\r\nApparently not - if you go to the site TopMind cites on his Wiki homepage [http://www.geocities.com/tablizer/], you'll note that it's static text. I expected it to be generated dynamically from a RDBMS using instructions stored in an RDBMS... \r\n\r\n''That website started out small. I never set out to create a hundred or so pages. If I had to do it all over again, I would probably use wiki-like technology, perhaps with MySql so that it is easy to transfer to other ISPs if needed. (That was not a viable option when I started out, I would note.)''\r\n\r\n----\r\nTop is not the only one who advocates this stuff. I also independently advocated this approach and agree with most of his ideas, I just never was exposed to the discussion until I stumbled across this Wiki. I also came across another similar viewpoint at http://grumpyoldprogrammer.myblogsite.com/blog who I think perfectly sums up our complaints with this quote:\r\n\r\nDuring the creation of large programs, OO developers found that the classes at the top of their inheritance hierarchies became impossible to change, as any changes would have totally unpredictable consequences for the many subclasses that depend on the classes higher up. Consequently, good developers adopted a discipline of creating 'abstract base classes': classes at the top of the hierarchy that defined public members but provided no functionality. This use of empty, functionless classes became so useful and common that it became formalized as the concept of an interface. Interfaces are useful as they (can) provide an explicit boundary between one piece of software and another, so reducing coupling. Interfaces became a founding principle of Microsoft's COM and are playing an increasingly important role as they are rediscovered in .NET.\r\n\r\n''Put simply then, if you take the inheritance out of inheritance it becomes a useful concept.''\r\n----\r\nI stumbled upon a 1990 paper by William Cook, \"Object-oriented programming versus abstract data types\" [http://www.cs.utexas.edu/~wcook/papers/OOPvsADT/CookOOPvsADT90.pdf], that TopMind really ought to read.  The paper's analysis of OOP data abstraction (which it refers to as PDA, procedural data abstraction) is closely related to some of TopMind's criticisms; multi-dimensional code tables even make an appearance.\r\n-- MaxStrini\r\n----\r\n\r\nMoved discussion to BundleSubstanceMismatch.\r\n\r\n----\r\n\r\n'''Vandal watch:'''\r\n http:RecentChanges?page=TopMind?days=3\r\n http:posts?TopMind\r\n\r\n----\r\nTopMind, how can you be contacted? The email on your tablizer site doesn't work. I am interested in your Fox Music Sequencer.\r\n\r\n''Try:''\r\n\r\nhttp://www.geocities.com/tablizer/FOXSEQ_B.zip\r\n\r\n''It will likely require some retrofitting for your environment.''\r\n\r\nThx. Downloaded, will try at home. By the way, I love your OOP Critisism and your tablizer site in general. Was all over it for a few days, really nice articles and as a web developer, I can't see the use for OOP in most cases.\r\nAnyway, I think we will have to be in contact, since I believe I might have questions about the sequencer. I understand you wouldn't want to leave your email on a public resource, so I'll instead leave mine. Please write me so that I trace your contact. louigi.veronaREMOVETHISFIRST(at)gmail(dott)com\r\n\r\n''How about you put any questions here or on TheAdjunct (when its fixed). If that doesn't work out, then we can try email. Thanks, Top.''\r\n\r\n\r\nQUESTION:\r\n\r\nokay - first problem - how do I start the app? I see only two exe files and one bat and neither of them starts. Player.exe closes instantly with Invalid Property Value error.\r\n\r\n''I guess I forgot to meantion that what's there is mostly source code, not a compiled version. As such, it requires FoxPro to run. Perhaps I can generate a compiled version to give you, but it's been a looong time since I've done such. Do you have FoxPro, by chance? If so, what version? -t''\r\n\r\nnope, have no FoxPro unfortunately. But I would be very grateful to you if you do compile it for me, so that I can get a binary version. I am not a very strong programmer, so I am afraid I can really get mixed up woth all the compilation and such. But I am a good musician. ;)\r\nps: wrote you a letter to an e-mail I found by chance on the Internet, maybe it's a valid email and it reaches you.\r\n\r\n''If you are not familiar with FoxPro, integrating it into your existing system may be a tall task. Remember, it assumed a Windows-95 environment. I half-modernized some of it, but not enough. Hmmmm....''\r\n\r\n----\r\nTop, so many great ideas on this page. If you could just separate all the OOP stuff away on another page, maybe they'll come out even brighter (too much blood, besides this wiki is choke full of OOP debates). I too dream about a dynamic database (or at least a complete relational library in a dynamic language, maybe lua or python). I think and do relational computation in my programs whenever I can. About the TOP vs OOP debate, it's very simple. In the end, it's just means of abstractions and means of composition. OOP constructions allow for abstraction, but very limited composition (you can only compose computation through virtual methods), while relational (as everything math) takes it to the core so you get much more expressive. my2c -- CosminApreutesei.\r\n\r\n''Please see ArgumentsAgainstOop, and keep up the hope. --top''\r\n\r\n----\r\nTopMind: I've really enjoyed perusing your geocities \"Programming Wisdom\" site; now that geocities is closing, I really hope you'll set up the site somewhere else - would be a shame to lose all of your 'programming wisdom'.\r\n\r\n''Yeah, that's a bummer about Geocities closing. If I move it, I'll lose the page ranking built up in search engines over the years. All that stuff needs a re-factoring anyhow, but I'm not in a mood to do it right now. Geocities still gets ad-able hits on many of its little sites. It would be more prudent to only remove the low-ad-hit sites. Thanks for the reminder. Is C2.com wiki next to kick the bucket? -t''\r\n\r\n[Want hosting for your stuff?  I'll give you space for free.  Email me if you're interested. -- DaveVoorhis]\r\n\r\nI'll consider it. Thanks for the offer! -t\r\n------\r\nIn response to: It seems to me that TopMind (who's real name took less than three minutes of googling to find) just wants to prevent current and future employers from finding out about some of his poorly supported opinions on technical matters and his equally lacking abilities to engage in constructive discussion about those opinions.  I'm a big fan of anonymity and pseudonymity on the Internet in general, but if a site has a RealNamesPlease policy, hiding one's real views on technology is a pretty poor reason for violating it.\r\n\r\n''Truth and hard-biting criticism is not always popular. The business world rewards diplomacy and conformity for the most part, which is at odds with the first set of actions. Further, sometimes I lose my cool after about 2-dozen personal insults directed my way, and I retaliate with counter-name-calling. And I disagree with your characterization of my psychology and style, and most of my detractors have not presented any hard evidence against most of my pivotal opinions and statements, and frankly rely far too heavily on ArgumentFromAuthority. I believe strongly in GoodMetricsProduceNumbers, but some here don't and feel it's okay to insult me personally as punishment for holding this view. Perhaps if somebody volunteers to be a moderator (VolunteerWikiModerators) and prevent personal insults, the tone may be more conducive to RealNamesPlease. I will not use real names in an atmosphere of blatant personal rudeness. --top''\r\n\r\n[''\"most of my detractors have not presented any hard evidence against most of my pivotal opinions and statements\"'']\r\n\r\n[I don't recall you presenting ''any'' evidence, hard or otherwise, '''for''' most of your pivotal opinions and statements, and they frequently run counter to generally-accepted principles (when we point this out, you call it \"ArgumentFromAuthority\" or \"attacking sacred cows\", but it's more like making FacePalm-inspiring schoolboy blunders), and your arguments frequently display a clear lack of education and refusal to gain it.  That's not what I'd call \"truth and hard-biting criticism\", but your use of that phrase to describe what you do gave me a good laugh. Thanks for that.]\r\n\r\nWhy should I care what \"generally-accepted principles\" (GEP) are? I'm not even sure there is such a thing because it depends on who you ask. FP fans are often not OOP fans, and vice versa. If there was such a thing as GEP, then they too '''should be tested''' with science, just like everything else. And, you complain about my not reading up on your pet HobbyHorse''''''s (HH) because you are too lazy to gather, shape, and present the evidence yourself. It's a sorry excuse. It's a social intimidation trick to get others to read up and care about your HH's. Scenearios and numeric metrics would work better for that goal, but you don't know how to do them from what I've seen, lacking a certain communication ability to explain to those outside of your narrow think-alike friends what is really \"good\" about your HH's. You need to work on that; I'm not going to compensate by trying to figure out what you are thinking myself. -t\r\n\r\n[That would be eminently reasonable, if not for the fact that the \"generally accepted principles\" to which I refer are nothing less than the rudiments of ComputerScience itself.  Go learn them.  Until you do, your contributions will be deemed uneducated at best, and idiotic at worst.]\r\n\r\nAgain, ComputerScience has done a great job on machine performance issues, but has a dismal record on the software creation and management side. It has provided some interesting ideas, models, and idioms for software, but has not found an objective way to test them relative to competitors. -t\r\n\r\n[So you claim.  As has been pointed out numerous times, that is the domain of SoftwareEngineering, business academia, HCI research and so on, which have produced ample publications.  However, if your claim is that there is insufficient published research providing objective language comparisons and therefore an apparent lack of numeric metrics in favour of (say) ObjectOriented languages, that is still not a sound reason to reject them, because there are equally valid logical, rational, elegance, or even personal reasons to choose them.]\r\n\r\nI never said there were zero numeric studies, only that compared to hardware/performance they are extremely sparse. And the substitutes you list are just not good enough, often because they focus on a narrow set of aspects or because they are based on unrealistic or uncommon scenarios (like the shape and animal OOP examples).\r\n\r\n[Your answer falls squarely in the \"insufficient published research\" category I noted above.  See it, above.]\r\n\r\nPlease clarify with page-anchors or the like.\r\n-------\r\nPageAnchor: science_self_hypocrisy\r\n\r\nRe: \"I don't recall you presenting any evidence, hard or otherwise, for most of your pivotal opinions and statements.\"\r\n\r\nFor the most part I believe WetWare makes the biggest difference in one tool over another, and everyone's wetware is different. It's difficult to offer objective evidence for such, because it's subjective, and falls under psychology and related fields, which is still a fuzzy art; and it's different per individual. Given that, I do try my best to '''describe the mental processes''' behind my tool/language/paradigm/technique choices where I can. An example can be found at LispLacksVisualCues, PageAnchor: \"peripheral_alpha\". This is the kind of evidence I can provide for my preferences, although most don't seem to care, searching for the Universal True Paradigm/Formula instead. Related: FastEyes. -t\r\n------\r\nHello TopMind, \r\nlooking at your page it seems that we share similar ideas with you. We hope you won't consider this as a spam but you might want to look at our project (bandilab.org).\r\n\r\n''I believe it is more similar to RelProject than to TqlRoadmap, I does look interesting --LuxSpes''\r\n\r\nI was thinking the same thing. Anybody recommend an existing topic to list or discuss that tool? --top\r\n------\r\nRegarding your \"summary judgement\" about change on CouplingAndCohesion: And in fact, that whole discussion at the top of the page about change seems to be an unhelpful digression. A discussion about change *might* have clarified the Coupling/Cohesion concepts, but in this case it didn't, and the word \"change\" is not at all central to the actual definitions that follow that discussion. I would think that means that that top part would be better moved or even deleted. -- DougMerritt\r\n---------\r\nTopMind a prime example of DunningKruger effect, the UnconsciousIncompetent mind fails to grasp it's own incompetence and since it cannot see the limitations then concludes it is superior. -- BottomMind\r\n\r\n''You guys almost never prove me \"incompetent\" in terms of the issues involved. If you claim X is better than Y when I claim otherwise, then PROVE X is better than Y using sound science and measurable evidence. Kick with me science, not personal opinions about how stupid dumb or lame I allegedly am. Prove I am wrong FOR THE READER TO SEE, don't just claim I am wrong. True, I don't know a lot of academic lingo, but you don't need lingo to RaceTheDamnedCar. The engine doesn't go faster JUST because the builder knows more lingo. It's YOUR job to turn your grand knowledge into a better engine to beat the pants off of my car and show how stupid I am. See CategoryMetrics for suggested ways to measure my alleged dumbness. --top''\r\n\r\n{Almost every debate between you and other WikiZens that remains on this Wiki is a potent demonstration of the truth of BottomMind's comment, and clear evidence of how \"stupid\" (your choice of word, not mine) you are.}\r\n\r\n''It's never objective measurable metrics, just summary vague opinions. If you can't find a way to measure the shortcomings of my favorite techniques or tools, THAT'S NOT MY PROBLEM, IT'S YOURS. You claim you are 10 times smarter than me, so your great brain should be able to come up with metrics and objective evidence. But you don't. And IBM and Oracle made the same \"mistakes\" I did (\"bags\"), yet are far more profitable than you. If they are also incompetent, the IT world has far bigger problems than me because that would imply that our economic system rewards grossly incompetent companies over long periods of time. -t''\r\n\r\n------\r\nYou mean UNTIL? Don't need it. I explained already, but somebody deleted the explanation without asking permission. \r\n\r\n''If you want to start a page about the merits of various loop constructs, go ahead. But, please don't put your idiocy there. The question is clearly not about until.''\r\n\r\nNext time, Sir, please don't delete others' material without permission. I know you personally think it's \"idiocy\", but I think your shit is also idiocy. But I respect your right to be an idiot by not deleting your drivel.\r\n-------\r\n\r\nMost of our thoughts and opinions about logic, are based on unspoken assumptions about the validity of the human mind in its present state as a reality-parsing mechanism. The idea that we have no other alternative is untrue and irrelevant if it were true. \r\n\r\nIts untrue because we do have other alternatives - traditions both mystical and modern point to feelings, intuition, inspiration, and God-inspired experiences (including drug-induced) as an alternative mechanism of knowledge. The thinker who discounts these routes to knowledge is stuck with his own discursive reasoning as the source of paradox-resolving truth, and see above as to why that can never happen. This is why philosophy is stuck, and those who grasped its natural limits (e.g. Heidegger's whole philosophy, Nietzsche with his discourse on the meaning of truth, modern string theory and the whole of Eastern thought basically) recanted from the faith in logic and reasoning that pervades arguments of this kind.\r\n\r\nThe faith in logic is shallowly rooted in human experience and is eventually discarded when the primacy of emotions and our inability to logically parse them is realized. Sorry if my wording offends.\r\n\r\n[Logic and mathematics are perhaps the only manifestations ''not'' rooted in human experience, and although emotions are certainly cognitively significant, there is no logical or empirical reason to believe they are anything but neurological phenomena.  Feelings, intuition, inspiration, and other subjective perceptions -- spiritual, chemical, or other -- are certainly sources of creativity and personal enlightenment, but their unrepeatable and unverifiable nature makes them useless as sources of scientific knowledge.]\r\n\r\n* ''Semi- or non-scientific knowledge may be all we have in some cases.''\r\n\r\n* [Then it's not scientific knowledge.  It's perception or speculation.]\r\n\r\n* ''But if we ''have to'' make a decision, then we have little other choice than to live from the bottom ranks of the EvidenceTotemPole when the meaty levels are not yet available. You cannot tell your boss/customer, \"Sorry, we cannot settle on a design until we complete our OfficialCertifiedDoubleBlindPeerReviewedPublishedStudy!\" They will replace you.''\r\n\r\n''Logic is the language of debate and science for good or bad. The alternatives are very difficult to communicate and compare. I'm not saying intuition has no value, only that it's not transferable between minds the way logic and math and repeatable experiments are. And it's often the other party who claims their claim is \"logical\". I just hold them to such claims. I don't even outright dismiss ArgumentFromAuthority, but do get pissed when one tries to pass off ArgumentFromAuthority AS \"logic\". I will hold such claimers to such claims. If they want to fight with logic, then they have to choose logic as their weapon and follow through. They can't claim they are a better swordsman and then pull out a gun. -t''\r\n\r\n------\r\nI have moved my comments about Table based programming and the MAX language/system to MaxOopsRelational. Sorry for using your space.-- DavidClarkd\r\n------\r\nHey... top... I thought the wiki was dead, but I guess not. Hey man, it's a cool idea, thanks for getting it all out there...\r\n------\r\n\r\nPageAnchor Complaint-004\r\n\r\nHi top!\r\n\r\nI am a new visitor here, and after reading your debates with others in a dozen pages, I conclude you must have some kind of psychological issues. You seem completely unable to even entertain the possibility of ever being wrong or uninformed about anything, and automatically assume anything outside of your own limited sphere of knowledge must be worthless.\r\n\r\nIn short, you are not really discussing programming issues here, you are simply defending your own fragile ego. You do not even LISTEN to what people say, other than to pull a random statement out of context to use as an attack vector. You demand \"Absolute Proof\" and refuse to accept any argument given to you on the flimsiest excuses. Meanwhile you do not hold yourself to the same impossible standards, since you present no proof whatsoever to back up any of your own positions.\r\n\r\nYou are frankly one of the worst trolls I've ever seen anywhere online. Quite an achievement, really. It boggles my mind how patient people have been with you here!\r\n\r\nNow the funny thing is, I'm an old fart myself, and I find keeping up with modern advances a chore. I love low-level programming \"to the metal\" and would probably still use assembly if I got away with it, but reluctantly use C, and even more reluctantly C++ if I really have to. I have an instinctive dislike for OOP as well as higher order functions, and everything else you don't like, because my mind habits were formed in an earlier era. Just like you, I long for \"the good old days\" of ad hoc hacking that will never come back!\r\n\r\nBut I am still not on your side in this fight, because I am at least humble enough to take an objective look at the new advances and to put in the required effort to understand them and try them out (even though I really don't want to). And when I do, I frequently find I understand exactly WHY these practices are objectively so much better than what I've been doing. I still can't make myself LOVE them, and I mostly still work as I always did, because it works \"well enough\", and because I am skilled in it on a very deep level. I respect the fact things have moved on, but I still want my raw pointers to unprotected memory, dammit, because that's what I'm an expert in dealing with and I'm too old to be a newbie in better practices!\r\n\r\nI could respect your POV if you were just lamenting the fact progress has left you behind and made your hard-won expertise more or less obsolete. It happens to all of us eventually, and it sucks. But you think you can actually fight against progress and win, and that's just sad...\r\n\r\n--an observer\r\n\r\nThank you for your honest opinion. If I am delusional, I am not aware of it. Repeatedly accusing me of being ego driven and/or delusional is not going to change that fact. My self-diagnostic is outright broken IF I am delusional. I realize a good many WikiZens, perhaps 70%, don't like my opinions, but so far I don't see any iron-clad evidence my opinions are objectively wrong. I don't see ''clear'' logic against them.\r\n\r\nRe: \"Meanwhile you do not hold yourself to the same impossible standards, since you present no proof whatsoever to back up any of your own positions.\"\r\n\r\nWhat do you mean by \"impossible\"? Usually I get into heated debates with people who honestly believe and ''insist'' their opinion is \"objective\". I simply hold them to that. If you claim and insist Fords are objectively better than Chevys, then you are obligated to give the evidence. I may appear \"annoying\" for doing so, but if you make insistent claims like that, you frankly deserve heavy scrutiny. And I never claimed any X ''objectively'' better than some Y such that I'm not in that boat. (If I did in the distant past, I renounce it now. I was naive back then.)\r\n\r\nAnd generally I believe that most things about software are subjective or relative: ProgrammingIsInTheMind, and that's why I cannot prove that my claims are objective: they depend on assumptions about the human mind '''rather than some ''external'' truth'''. My debate enemies appear to mistake their internal mind model for universal truth. I honestly believe that is their primary general failing. (Aspects of psychology and WetWare are potentially measurable, but neither side usually has such evidence, relying on anecdotal observations instead. Related: LaynesLaw.)\r\n\r\nAs far as OOP, The industry appears to be coming around to agree with me: it has places where it is useful, but that place is ''not'' everywhere. See OopNotForDomainModeling. The OO-should-be-everywhere zealots are dying off. I am no longer the outlier on that. -t\r\n\r\n------\r\n\r\nI just read a LOOONG debate page where you took a strong position *against* the sound practice of using non-blocking IO (every other programmer in the world just had a collective facepalm moment!), and refuse to see any \"business use\" for it. You refused to hear ANY argument directed at you, and dismissed them outright, apparently without even attempting to grok what point is being made. Then you systematically used petty squabbling and misdirection to have your way.\r\n\r\nThis is a strong pattern with you.\r\n\r\nYour standard debate approach is to refuse to accept an argument because \"its not a realistic business scenario\". Then people try something else, and you retort that's not a a realistic business scenario either. Eventually, they find you have excluded any and all examples they can possibly think of, so they politely ask what the heck a realistic business scenario is to you: Could you *please* provide an example of a plausible and realistic business scenario, so that I might demonstrate how this technique fits into it?\r\n\r\nWhich you of course REFUSE to do, since that would provide an opening for your opponents to penetrate your defensive screen - as long as you maintain the \"right\" to shoot down any suggestion on grounds that are only defined inside your own head, you can't lose.\r\n\r\nOr so you think. Of course, you're losing all the time! The only one you're fooling into believing you are winning the debates, is yourself. Any casual observer like myself sees your obtuse posturing exactly for what it is: someone desperately trying to save face while being in it WAAAAY over his head!\r\n\r\nYou like to oppose any \"newfangled fancypants\" techniques on the grounds that \"rank and file\" programmers couldn't possibly understand them. The truth is of course that it only takes rank and file programmers an hour of study to learn these techniques, and most of them already did so long ago. The only one that still hasn't done so and who is being left out of the loop, is YOU!\r\n\r\nIt is obvious your inherent brain power is not what's holding you back, it's your stubborn refusal to use it to learn new stuff. If you had spent even a tiny fraction of the time you waste fighting against new ideas learning them to expand your toolbox, you'd have been a master programmer by now. But you have instead spent DECADES of effort RESISTING anything new that came your way. This immature ego-defensive behavior has eventually turned you into an irrelevant fossil. And a cranky one at that.\r\n\r\nSometimes I come across an application that is so overall BADLY DESIGNED and UNRESPONSIVE it makes me wonder how the hell anyone could produce such a piece of crap even if they tried. Now I know - there actually exists at least one programmer out there who actively refuses to learn anything new about his craft, and who will not recognize a good thing (such as non-blocking IO!) if you hit him over the head with it. If nothing else, you've given me closure on that longstanding issue. Thanks, I guess.\r\n\r\nIf anyone reading this don't believe anyone would actually fight against a universally accepted good thing such as non-blocking IO, here it is, in all its horror:\r\n\r\nhttp://c2.com/cgi/wiki?NodeJsAndHofDiscussion\r\n\r\n''Where did I refuse to offer a business scenario? I'm a bit offended by that. The whole NodeJS thing still looks like a solution looking for a problem to me, except perhaps some kind of instant-messaging-like app. As far as a \"common need\", it is hard to measure and verify such objectively. Perhaps the best we can do is describe the need and the reason for the need the best we can and LetTheReaderDecide if the scenario fits their own situation. There's a point where debating how a common a need is becomes pointless and repetitive and is merely an AnecdoteImpasse. If I could bet on it in Vegas, my money is still that NodeJS is a fad (or at least is over-hyped as a general solution). I was mostly right about OOP, after all those years of '''similar complaints against me; only the tech has changed'''. I should turn your complaint into a fill-in-the-blank version where the tool name is. You(s) did a shitty job of selling NodeJS as a general web solution in my opinion. If you disagree, so be it. My description of the biz world is as accurate as I can make it and is not stated with an any attempt to manipulate the truth. If your observations of the world differs, so be it. We can AgreeToDisagree about the biz world without making it personal, I would hope. As I mentioned elsewhere, personalities tend to gravitate toward certain flavors of projects and companies such that we may be biasing our own experiences without knowing it just by being a human individual. It's perfectly possible there is something about my personality that keeps pulling me into dysfunctional Dilbertian companies with goofy and unpredictable IT staff and clueless managers. Talking to others, it seems the norm, but maybe there is a similar filter to those I talk to. And I like keep saying, almost every \"unresponsive\" situation I encounter with apps I design is related to the database and NOT app-side blocking or non-blocking. '''I'm being honest''' when I say the database is usually the bottleneck in my experience. -t''\r\n\r\n* [NodeJs is a single product; in time, it will almost certainly be eclipsed by other products.  However, evented I/O is almost certainly here to stay.  See the bottom of NodeJsAndHofDiscussion (search for \"Here's a business-oriented case\") for an example of the kind of application for which evented I/O -- what NodeJs implements -- is appropriate.]\r\n\r\n''And I do wish I could figure out WHY you think NodeJS is great. I tried, but I am just not getting something; there is a communication gap somewhere that keeps getting in the way. If the fault is me and I am really am the stupid idiot stubborn jerk you make me out, we'll, I don't know how to fix that because I'm very normal and logical and rational TO ME and I don't see my mistake. It's like we are looking at the same landscape and you see rainbows and  unicorns while I see smog and mules. -t''\r\n\r\n* [I think you could perhaps make a bit more effort to appreciate the fact that there are kinds of applications and approaches to programming that are outside of your experience but that are perfectly valid.]\r\n\r\n* The flip-side of that is that you shouldn't assume or insist that your niche should shape all of programming. I keep stating that it's fine to LetTheReaderDecide if a given scenario or staffing pattern fits their OWN shop/experience, but my debate enemies don't seem satisfied with that, instead insisting their niche or assessment of programmer behavior is more common/accurate as if I or the reader are bad for not taking their word for it.\r\n\r\n* [I don't know that anyone here is assuming or insisting that their niche should shape all programming.  Where do you see that happening?]\r\n\r\n* I'll link to it if I encounter such again. I don't remember the exact spot.\r\n\r\n''And note '''I do use OOP'''. Just not the way the original fad-pumpers suggested.''\r\n\r\n* [How did \"the original fad-pumpers\" suggest you use OOP, and how does your use of it differ?] \r\n* See OopNotForDomainModeling\r\n* ''The notion of OOP for domain modelling died along with the popularity of object-oriented databases in the early 1990s as the Web drove SQL DBMSs to the forefront.  Using it for computational modelling, not domain modelling, is now almost a given.  In that sense, almost no one is using OOP the way you suggest \"the original fad-pumpers suggested.\"  On the other hand, I'm not convinced that's what \"the original fad-pumpers\" pumped, either -- at least for general-purpose programming.  Are you sure you're clearly distinguishing OO databases from OO programming?''\r\n* My experience is that it wasn't until the late 200X's that they gave up on the domain modelling tilt. If your experience differs, so be it. AnecdoteImpasse.\r\n\r\n''Re: \"BADLY DESIGNED and UNRESPONSIVE\" -- If you feel such an app is representative of my design style, then bring it or a close facsimile HERE. We are lacking good ''actual'' examples. Bring it on!''\r\n\r\n------\r\n\r\n[Please keep the \"see also\" at the bottom]\r\n------\r\nSee also: TqlRoadmap, RelationalLanguage, CategoryRelationalDatabase\r\nSee EventDrivenProgramming, ProceduralMethodologies, ObjectRelationalPsychologicalMismatch, DataDrivenPrograms, ArgumentsAgainstOop, CodeAvoidance, TopIsNotEvil, BottomMind\r\nSee TablesAreCollections for what may be considered the 'opposite' approach.\r\n-----------\r\nCategoryHomePage"
}