Top Mind
Top Mind
Some of my favorite topics
Industry terms that are BS or too fuzzy to be useful beyond a rough notion:
OO Criticism Summary
Most of my criticisms of ObjectOrientedProgramming can be summed up as follows.
If 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.
Then there are OO methodologies that de-emphasize sub-typing. These OO methodologies tend to reinvent NetworkDatabases (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.
I 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).
But, 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
The "algorithm" for the problems I see in OO would look something like:
If tree-centric OO being analyzed then LimitsOfHierarchies and ThereAreNoTypes squash trees. else OO is mostly an app-built NavigationalDatabase, which _ is inferior to RelationalDatabase theory. if integration-of-data-and-behavior compensate for problems of navigational then The benefits of the integration are elusive or difficult _ to articulate. Putting code in relational databases is _ also possible, but provides only incremental benefits. end if end ifThe 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.
Another way to essentially say the same thing:
(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.)
Ideal TableOrientedProgramming system or environment according to TopMind:
My History
During 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.)
I 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.
After 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.
When 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.)
Hard-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.
When 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.
Topmind FAQ and AQ
Q: Tables and most RelationalLanguages are not TuringComplete, thus they cannot solve every algorithm.
A: Completely solving every algorithm is not their purpose any more than solving every algorithm is the purpose of RegularExpressions. 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.
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.
A: 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.
Q: Some say you are "anti-science". Is this true?
A: 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
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?
A: 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.
TransientCodeGenerationIsGoodDesign? -- PeterLynch
As 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.
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.
I don't see any contradiction. Procedural is generally shaped by task and only task. OO on the other hand tends to build NounModels 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.
[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.]
I 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.
[...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.]
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.
If 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.
Then you work in a very different world than the rest of us.
I 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?"
I'm not talking about your head. I'm talking about the work you do.
Why?
Perhaps I misunderstood the original question.
I am looking at this from the app developer's perspective. They usually don't care how datastructures and databases are implemented.
I 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
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.
Database != 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
{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.}
I 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
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.
I 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
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.
[There seems to be some confusion, in the above discussion, between "database" and "relational database". The latter term is a subset of the former.]
Well, there does seem to be confusion of some kind.
Hey Top,
1. I responded to a question you asked at the bottom of ObjectRelationalMapping
2. 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?
Sorry, I don't recall such a discussion. I will get back to you if I later do. -- top
What are these "generators" you keep talking about as an alternative to grammars?
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?
That's not surprising. Anyway, it's very misleading to talk about stuff from Lex and Yacc as an alternative to Lex and Yacc.
Also, 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.
I 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...
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.
Well, 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.
Then there are GeneratorsInPython; a specialization of CoRoutines. These can be used to implement parsers (that page gives an example); but that's not a replacement for a grammar either.
And none of this has much to do with relational vs OO anyway, at least not that I can tell.
I don't see where anybody implied they were related, except possibly data-centric versus behavior-centric thinking. -- top
Dogma - "let's just say we'd like to avoid any empirical entanglements."
"OO is Like Goto's" Rant
I 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.
I 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.)
Plus, 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.
OO is basically NavigationalDatabases 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).
Almost 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.
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.
if (x != 1) goto B: .... goto G B: if (x != 2) goto C: .... goto G C: if (x != 3) goto D: .... goto G D: if (x != 4) goto E: .... goto G E: .... // "otherwise" G:The modern "cleaner" solution is a case statement (with no "break" statements):
select on x {
case 1: {....}
case 2: {....}
case 3: {....}
case 4: {....}
otherwise: {....}
} // end select
GOF 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.
. . .
Second, as the same information has to be involved in mutiple patterns, you still end up with a mess. The best solution is a relational database, not yet more overlapped goofy code patterns.
Relational is like code blocks and OO is like goto's: Spaghetti pointers. Goto's are just a big messy graph of flow, and OO is a big messy graph of relationship pointers.
Hi top, I am an expert in java (what I think). I have gone through the discussion on TOP as well as the tutorial. I want to know which basic constructs should be added to java and which one should be eliminated. Also give me justification for each. I have few in my mind and I am sure that I can defend that java with OOP in much better than java with TOP. (or it's worst to convert to TOP).
I find it hard to work with statically-typed languages and tables. Maybe there is a "static TOP" philosophy, but I have not persued/studies it much, preferring a dynamic approach. By the way, would your evidence work with say Python? If not, then is OO only better under static typing in your opinion? I suggest we clear up this issue before going further.
Response to claims made against me
My impression of an OOP zealot: "I don't have to provide open evidence. If you were smart like me, you would just feeeeeeeel how good OO is in your bones." -- top
My impression of Top: "I'm smarter than all you ther programmers, even though I do very little advanced programming and mainly work with databases. It doesn't matter that a large majority of the best programmers in the industry feel OO has value, their opinions are worthless."
As you said top, it is a grey industry, no solid proof exists of just about anything, but the fact that so many people find OO of great value, either means it "is", or you're smarter than everyone else, my bet is the former!
OO is currently being "marketed" as the end-all-be-all, and NOT Yet Another Paradigm.
That's what marketing people do, so what, they d that with everything.
How many "Learn Procedural Patterns in 21 Days" or "Learn Functional Patterns in 21 Days" books do you see at the bookstore compared to OO ones? I thought so.
Again, who care's what books are selling in the bookstores? If you think you have solutions then promote them, don't knock others, too many people have had positive experiences with OO, you aren't going to get anywhere trying to attack that juggernaught.
As far as me being "close minded", show me some kick-ass evidence, and I just may open it. Deal?
No deal, I'm not here to convince you of anything, that's your job. If you think your Table stuff is so cool, then put up or shut up. We're programmers, you have to show us, we aren't the marketing guys, and knocking OO will just get you ignored and ridiculed as usual. YOU WILL NOT EVER DISPLACE OO, so quit trying, instead, promote your own ideas without bashing OO, and we might just start to listen, until then, we won't.
Possibly in the wider software industry, which has always been very much hype-driven. But most people I know on Wiki are not wedded to OO. Costin, Doug, me, WilliamUnderwood, DanMuller, and several others have all contributed non-OOP ideas and examples to several pages. But we don't have to bash OO to do so.
People would be much more receptive to TableOrientedProgramming if you did not pit it in opposition to OO. Most of us, even partial TOP-supporters, have had positive experiences with OOP; we really don't care whether that's your experience or not, we want solutions that work for us. If you make us give up our objects to adopt tables, you aren't going to find much support. If you try to find ways to let objects and tables coexist, as Will and Dan and myself have all tried, you might just come up with something useful. -- JonathanTang
Perhaps you guys are not really the audience f my complaints. -- top
I, too, have put a lot of thought into the topic of synergistic coexistence; it's interesting, and the classic approach, e.g. that Java takes, clearly needs sharp improvement. -- DougMerritt
The Internet never forgets: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=6hba36%24rmi%241%40nnrp1.dejanews.com
An 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.
MeasuringAbstraction is another brain twister.
On 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?
Somebody keeps promoting the myth that I claim that OO is about only about hierarchies. It is not true. I correct them, but they never seem to read the corrections. Without trees OO is just a huge sea of dictionaries (objects/classes) with no overarching structure or rules. It lacks consistency and discipline compared to similar info converted to relational. I think some people like OO because it gives them the freedom to be structurally sloppy. Trees at least gave the hope/illusion of a larger structure helping out. Prototype-based OO can still have a hierarchical tilt, I would note. Clone-and-alter and formal inheritance are not that much different.
Second, do you think that, when all the hype involved in it is laid to rest, that OOP will still have a useful place in a broader multi-paradigm programming system? Conversely, do you see TOP as a singularly powerful system, or part of a continuum of possible methodologies (along with ProceduralProgramming, FunctionalProgramming, NotationalDesign, LogicProgramming, FiniteAutomata, and so forth, and yes, even ObjectOrientedProgramming) which should be applied as the situation warrants?
I believe that people gravitate toward paradigms which fit the native way that they think. Unless paradigm X is proven objectively better, it makes sense to find the one that best fits the way you personally think.......if the world will allow it. As far as mixing, see MixingParadigms. It is hard to perfect them all unless you are either a rare sponge-head or live 200 years. Thus, we must pick and choose with care.
Finally have you ever explored the conceptual connections between RelationalProgramming?, LogicProgramming and ConstraintModels? It has always seemed to me that there was a fundamental similarity between these three paradigms, but I have rarely seen any literature discussing it. -- JayOsako
I believe that Prolog's been roved equivalent to the RelationalModel, and could really be viewed as the first relational programming language. Not sure on the exact paper. I read about it in TheArtOfProlog? (ISBN 0262193388 ). It's given just a passing mention, but I think there's a bibliographic reference in there. -- JonathanTang
Perhaps, but I doubt Prolog will come close to ever being mainstream. Maybe something in-between or snuck in through relational is a better way to sell it to wider audiences.
PK, another question: what, if anything, is your opinion on ZigZag, and offshoots such as Gzz (and FenFire? (Unfortunately, the current versions all seem to have dropped CLANG, the cell-manipulation language that was developed for Gzz.)
I'll have to get back to you on that. Some of the key links seem broken.
Examples of the kind of crap I have to put up with on this wiki:
Related: FrustrationOverNotGettingOopDiscussion
Mental Blocks that OOP Proponents Generally Seem to Have
One 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.
Some will object that there are such things as public instance variables. My reply is that those are by their nature a violation of the paradigm, an acceptable compromise as a practical matter but not actually part of OO. Such compromises are quite common in real OO languages, and in most ostensibly OO code; the implications of this regarding the validity of pure OO is left as an exercise for the readers.
Of course, one aspect of this is that, strictly speaking, the concept of an 'object-oriented database' is a contradiction in terms. The people who came up with it simply didn't understand OO, period, and those who promote it do not either. The only way to make it work is for the database as a whole to be the sole object (otherwise, too much data has to get passed about and shared and related for it to work as OO), in which case it's just a wrapper around the real DBMS. Furthermore, the Database Object can't be a source of data - which, as I pointed out above, does not exist in OO - but must instead be a generator for other objects. It simply doesn't fit.
As for classes, they aren't really part of OO either; as Holub has pointed out, the class hierarchy is just a programmer convenience, a way of keeping track of what objects can do what and of grouping similar objects together so as to minimize repetition. Focusing on the classes or prototypes is to literally miss the forest for the trees.
(Another interesting aspect of this is that the separation between 'basic data types' and 'true objects' in some languages is nonsensical; the lowly int, whether in Java, C++, C, or Fortran, fits the definition of an object - an uniform and self-enclosed thing which has a set of defined behaviors - better than many user-defined objects I've seen. The fact that they are allocated on the stack instead of the heap, and aren't accessed by a reference and thus can't be used polymorphically, is simply a compromise in the language design; in the case of Java, it is a compromise that was probably unnecessary.)
As for mathematical rigor, I think that the current approaches are misguided; they focus too much on state, and too little on behavior, which is what OO really is all about. To define OO rigorously, there will have to be a calculus not of encapsulation, but of binding disparate methods together into a whole. Good luck with that, right?
You will note that this is simply a description of what OO is, at least from my own understanding; it says nothing about whether this is a sensible way of programming or not. Even though I'm fairly comfortable with OO, I'm not entirely convinced that it is a sensible approach; I certainly don't think it is the only one, or else I'd have dropped Scheme and C in favor of using Smalltalk and Java exclusively by now. But then, after reading the NASA article, I'm beginning to wonder if we aren't all fooling ourselves, and that maybe we should chuck HLLs entirely and concentrate on writing really, really carefully designed and vetted assembly code. Don't worry, I'm sure that the feeling will pass soon enough... - JayOsako
Perhaps this should be moved to DefinitionsForOo. I realize that some think OO is about putting behavioral wrappings on everything, and to a large extent I agree. But I think a more declarative approach is superior to a more imperative approach (behavior-centric) because there are more "maths" for declarations, such as relational algebra. Plus, behavioral wrappings waste about 40 to 80 percent of their interfaces on essentially DatabaseVerbs. This is because OO does not factor similar kinds of actions into a central spot/interface because encapsulation dictates that each "noun" be self-handling. If you are self-handling, then you cannot share your interface commonalities (InterfaceFactoring). If OO did, it would end up reinventing a database. -- top
you may be right about moving it. I was (as usual) being tongue-in-cheek, and much of what I wrote was hyperbole, but the main argument was genuine: that if OO is to be seen as a separate paradigm at all, it has to be from the Method-Interface perspective. Otherwise, 'object' is just another name for an AbstractDataType variable, with the addition of an excessively elaborate system of code reuse (inheritance) and a lot of buzzwords. Of course, that is exactly how most programmers use it, so perhaps the real truth is that ObjectOrientedProgrammingIsaMyth?.
It is not a myth, just inconsistently defined. Hmmmm. I wonder if defining it as maps with potential functions in the cells, and defining it as behavioral wrappers leads to the same thing more or less. Gotta ponder that one. -- top
Of course, one could argue that about any of these 'paradigms' or 'methodologies' or 'processes' - they are, after all, just conceptual abstractions that we create to make the process of coercing the hardware to do what we want it to easier. In the end, it's all just electrons whizzing about some circuitry in a particular pattern, which we choose to interpret as meaningful because it was our goal to give it meaning... so a paradigm is only as valid as the advantage we perceive it giving us in doing this. Arguing over them is no more meaningful than arguing over whether a God has Buddha-nurture fnord. - JayOsako
Well, after many debates, I can whole heartedly agree that in the end it is probably about which UsefulLie is the most UsefulLie, and it is probably all quite subjective because every mind is different. However, there are some on wiki who believe in authoritative evidence as their primary truth-finding tool, and are almost militant about their viewpoints. Those kind of people are a danger to this wiki and to the scientific process.
From JohnReynoldsFableOnTypes:
Top, please use home pages: I accept and respond to personal critiques, reproaches, etc., on my home pages. Do not pollute topic pages with out of band conversation. Unlike on UseNet the purpose here is to create something that looks more like a dissertation than a chit chat dialogue. -- CostinCozianu
Is this your view of what wiki should be or a consensus view?
Yes, it is a long time consensus view. See GoodStyle.
Sorry, I don't see how that supports your view of wiki.
I can't quite put my finger on it, but since last weekend, I have been thinking of moving across the Tasman to NZ. Any ideas? -- PeterLynch
To escape the end of civilizaion, OOP, Terrorists, or Bush?
Top here's the chaff that was previously on SyntaxDefinition. Do with it what you will, just do not restore it there. I understand your desire to have your private opinion and your private definitions of everything, but we'll try to accommodate that with things like TopOnTypes and TopDefinitionForSyntax, etc.
We 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.
Sorry, I don't see cut-and-ry Boolean-test formality in that reference. This "battle" seems to be right back to DataAndCodeAreTheSameThing. I did NOT create that topic, and thus am not the only one to share that viewpoint. I might be a minority, but I am not alone. And please stop calling me a "troll", Costin. It is rude.
"Syntax is a string"? Get lost from here. Nobody shares your viewpoint. DataAndCodeAreTheSameThing has nothing to do with syntax. Everybody knows what syntax is, and it ain't a string. To get to the point I'll be concrete. The syntax of Java is the set of grammar rules that define what is a valid Java language element. So syntax is not a string but a set of rules. You may have sloppily referred to the distinction between source code and AbstractSyntaxTree. Calling "abstract syntax tree" not syntax, well, that's obvious, still abstract syntax tree preserves the syntactic structure of the language. The nodes in the AST are syntactic elements.
Not "are", but "can be viewed as". It is a matter of representation. Just about ANYTHING can be turned into "syntax". For example, in Oracle one can "dump" the schema design as syntax. But it is generally stored as Oracle system tables (with a few unseparated expressions for complex constraints in some cases). It is "can be viewed as", not "is-a".
CREATE TABLE r_users_groups ( user_id INTEGER NOT NULL , group_id INTEGER NOT NULL, CONSTRAINT r_users_groups_pk PRIMARY KEY (user_id, group_id), CONSTRAINT r_users_groups_fk1 FOREIGN KEY (user_id) REFERENCES users ON DELETE CASCADE ON UPDATE CASCADE, CONSTRAINT r_users_groups_fk2 FOREIGN KEY (group_id) REFERENCES groups ON DELETE CASCADE ON UPDATE CASCADE )Tell me, Costin, is that "syntax" or a "structure" or both?
Top, even you should know what is that. It's neither syntax nor structure. It is a statement. It is a "CREATE TABLE" statement. That;s one of the chapter in Oracle documentation: the "CREATE TABLE" statement. When you put it as such, it's just its encoding as a string, the strings stays for a "create table statement". It's not syntax, it cannot be syntax. The syntax of Oracle SQL/PLSQL database language can be found at http://otn.oracle.com. The syntax of other flavors can be found at their respective vendors. And they aren't strings.
So "staements" and "syntax" are mutually-exclusive? Where is the math theory for that one? You don't need math theory for that, you just need to know your English.
Because you've been trolling this definition beyond any point of redemption, you probably were trying to say that JohnReynolds definitions of type systems is bad (in TOP's view) because it's tied to what top sees is concrete "strings". Completely bunk: it's tied to syntactic structure, type systems perform type judgements over the nodes in the AST. Get it now? When will we get rid of this EverybodyHasHisOpinion? attitude?
It will go away when you prove ArgumentFromAuthority is practical and effective.
No, it's not effective to get rid of trolls who want to rewrite every word in ComputingScience. But you've made quite a fool of yourself already.
Gee, all these years I missed out on the fficial Computer Science Standard Body. Do they now all sing for ABBA or something? Will they go back to their day job and help guide us strait? If your rules were as precise as you say they are, then we could simply plug something into an algorithm to tell us whether something is "syntax" or not. Wouldn't need humans to determine it. If humans need to be involved in the determination of what something is, then your determination rules are not ripe yet.
Normal humans who speak normal English, know what it is that a word denotes and do not try to change that. When I say "apple", I don't need to provide a computer algorithm to test for "apple-ness". Normal humans can know in 99.9999% of the cases (bar some possibly mutant apples created in laboratory) that a thing is an apple, never mind your call to human unreliability. But if you want to claim that what I call "whales" are in fact apples (by your definition cause now not only EveryOneHasHisOpinion?, EveryOneHasHisDefinition? as well), then I cannot convince you of the truth of the proposition "apple is a fruit".
We can develop criteria for testing "appleness" if it becomes an issue. Some lawsuits over what is "fair" labeling of juice bottles have actually run into these kinds of problems. What is "50% real fruit juice" when sugar and flavoring is added? Do we count volume or weight of the additives? Sometimes we have to turn to ArgumentByVote? for lack of better alternatives. The jury system is an example. The legal system is full of the problems and issues created by the vagueness of human language. EverythingIsRelative whether you want it to be or not. I wish the system had more logic in it, but it does not, and I am only the messenger.
This not legal system, this is a software engineering forums where contributors are expected to possess a minimum amount of education about basic ComputerScience thingies. Or else, keep some quiet and try to learn something for a change.
"Basic" does not mean it possesses precision. "Basic" could mean just a lot of ArgumentFromAuthority because we don't know how to clarify stuff yet.
To 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.
Syntax:
x = a + (b * c)Structure:
Re: So "statements" and "syntax" are mutually-exclusive? Where is the math theory for that one?
CC is not willing to compromise. He deletes and moves stuf around to fit his world view as if he possesses a God-given right by some revelation in the mountains. He couldn't put his pet definition of "type" in with the others, instead he deletes all the others. That is going too far. He thinks he's the King, and thus too good to wait in line with the rest of the commoners. You might not like my opinions, but at least I generally leave existing stuff as it was. His WikiSins? exceed a threshold of civility. -- top
Hey, TOP, the guy who refers to John Reynolds as "john" should not open his mouth about civility. And speaking of deletion and civility, it was CC himself that finally deleted the attacks and insults over your real name and protected your anonymity. So you benefited directly from what you complain.
Using first names is a bigger WikiSin? than deletion? Hmmmm. Odd sin math here. And, I have to use deletion-accounting to know if the good deletions outweigh the bad deletions? More complex WikiSin? math....
TopMind - I've seen that there are many problems where TOP would lead to the most direct solution. Now, I typically solve these problems with perl hashes, or a DB and T-SQL. But I have always felt that SQL was not nearly as enabling of TOP as it could be. I wonder if a more elegant language like APL or KDB's Q language (successor to KayLanguage) would be a better approach. I feel like using SQL to approach TOP is like using Basic or C++ - not a clean expression of one person's deep understanding of how to express a particular kind of solution. I want the Lisp, or Smalltalk, or even C, of TOP.
I believe SQL has stymied my growth of TOP thinking. What do you recommend for learning and for practice? -- PeteProkopowicz
What is really needed in my opinion is something like TopsQueryLanguage to replace or supplement SQL, and the various suggestions under SimplifyingRdbms. Aren't the APL successors more for arrays rather than tables? I suppose if they have enough features they can emulate tables. Almost any CollectionOrientedProgramming language is interesting, however. -- top
Aren't arrays and tables pretty similar? I would think an array language would be a natural basis for a DB-oriented language such as KayLanguage. From KayLanguage: "Its greatest use seems to be in the area of managing huge transaction-oriented data bases. In this class of problem K's performance is often staggering." It sounds like the embodiment of your CollectionOrientedProgramming paradigm. TopMind, please read the KayLanguage page and download the KDB demo. It would be interesting to hear your reasoned criticism of the KayLanguage after trying it out
I don't think arrays and tables are really that similar.
My Bulldroppings Watchdog Log
Where claims are validated or debunked
Moved to ChallengeSixVersusFpDiscussion.
Top, 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
Is this related to RunTimeEngineSchema and AdvantagesOfExposingRunTimeEngine? I have not really looked at MSIL. I hear .NET emphasizes static typing, and I am a dynamic typing fan.
MSIL carries an encapsulation of types in metadata which is interpreted at run-time. I am hoping that may allow introduction of types which can be used as generic ones. I have not yet looked in depth, but that is what I hope to find. I was hoping you had looked. Oh well - I will have to investigate further. Thanks.
Top, a request: Please be attentive to the existence of topical pages before beginning an old discussion anew on a related page (or worse yet, starting a new page). See for instance my edits to ExplicitColumnDiscussion. Thanks. -- DanM
I am not sure what you are referring to. I don't see anything "fixed" in ExplicitColumnDiscussion. And I usually do a search for something similar before starting a new topic. I don't always find an existing match because synonyms are used that I failed to guess.
Not a big deal. You had added a comment arguing against SELECT DISTINCT, but there are already at least two pages (pro and con) on this topic, which are now referenced by ExplicitColumnDiscussion. Just trying to keep the amount of scattered rehashing down.
I would note that I was replying to a question originated by somebody else. Is the burden of checking on the originator or the replier?
PageAnchor: Patterns
On Design Patterns
Some have asked about my opinion on OO "patterns". Every paradigm has patterns. See RelationalPatterns, for example. I don't see anything special about OO's patterns versus relational patterns. Some say that OO offers more "behavioral" ability with such patterns, but in my opinion they simply are not skilled in "declaratizing" (data-ify) information so that behavior is less of an issue. Or, they have some unexplained preference for a behavioral view over a declarative one. The more one can data-ify something, the more meta transformations are available, because as I like to say, data is more mathable than behavior.
Another reason declarative approaches seem to be rejected is because they readily don't offer polymorphic abilities. But polymorphism is overrated in my opinion. See SetsAndPolymorphism for more on this.
These also contain some of my opinions and comments about patterns:
Re: "Remember that people have been doing object-oriented programming since at least the days of Simula in the late 1960s. But OO didn't become a revolution, and dominant in the mainstream, until the 1990s. Why then? The reason the revolution happened was primarily that our industry was driven by requirements to write larger and larger systems that solved larger and larger problems and exploited the greater and greater CPU and storage resources that were becoming available. OOP's strengths in abstraction and dependency management made it a necessity for achieving large-scale software development that is economical, reliable, and repeatable." from http://www.gotw.ca/publications/concurrency-ddj.htm
Arggg. Evidence please. Relational should get the credit, not OO. Most developers use OO-Lite and only give OO lip-service. -- top
I dunno why you lot go on and on about relational vs OO. Both are in practice not what they claim to be. To many, OO is the object structure used in C++. But object orientation is much broader than one particular structure. And OO always has "procedural" components. To many relational is SQL. But SQL is again only one template for data management, and it is not relational in that it does not fulfil the Codd rules. And SQL is useful only within an environment which contains "procedural" components. I cannot see why each resists the others advances. There must be somewhere within OO that SQL syntax is useful.
And I admire your attempts at decomposing SQL into procedural elements. Now if the Lisp experts were producing usable high-level application functions, maybe you would not need to. -- PeterLynch
If you mean TopsQueryLanguage, it is not "decomposed into procedural elements", but merely more easily representable, or implementable, as procedural elements than SQL. That is one of the reasons it is better in my opinion: one can relate to it on both a procedural (step-wise) fashion and in a declarative fashion. It barrows a lot of characteristics from FunctionalProgramming in that way. -- top
There was (is?) a language called Quel, which was the DB access language used by Relational Technologies who marketed Ingres. Ingres early versions were translated to Quel then executed. It may be worth your while to take a look at it - I have not done the research but I believe Postgres has something to do with it
I'm curious what your take is on the Rails framework for RubyLanguage. It's basically an event driven framework for making web applications, but the really special part of it is its activerecord, which transparently and automatically maps database tables and records directly to classes. It does the CRUD for the programmer, even doing things like pluralizing record class names to find the tables. The conventions you must follow when building your tables are minimal (use _id for has-a/belongs-to relationships, etc...) and the framework is fast and powerful.
It seems to me this would simultaneously be very appealing to you (a totally event driven, database-centric app) and at the same time repugnant (the framework is very OO, but allows the database schema to define the classes). It might be at a "just-right" level for you.
Tell me, what do you think of it?
-- DaveFayram
I have found problems mapping directly from the database schemas to CrudScreens. Sometimes it is not one-to-one. It suffers the 80/20 rule. For example, some DB's have a "dateTime" type, but the client may want the form to have two separate input fields, one for data and one for time. Another example is pull-down lists that use a description (obtained via a Join) instead of the key. Thus, I tend to make the DataDictionary's that drive such be independent of the database. A copy operation to start it would be helpful though.
Further, I think the ideal UI framework would be mostly language-independent. It could be described via attributes in tables or perhaps XML (consolation prize). Only the event snippets themselves would be in any particular language, at least from the app developer's perspective. It would essentially be a "GUI browser".
-- top
Couldn't you have at least bothered to google "Ruby Rails" before responding? Rails is a web-centric application system (although the component libraries can be split apart to make non-web apps). Rails can generate CrudScreens, but that's not what I was talking about. Rather, it generates the code to Create-Read-Update-Destroy the data structures themselves, and can even represent relations!
I'll borrow from a Rails tutorial to show you. Let's say we have a table like so in our database:
CREATE TABLE `todos` ( `id` INT NOT NULL AUTO_INCREMENT , `description` VARCHAR( 100 ) NOT NULL , `done` TINYINT DEFAULT '0' NOT NULL , PRIMARY KEY ( `id` ) );Then to make Ruby aware of it:
class Todo < ActiveRecord::Base endNow we can get and display all these potential table items at will, with almost no code written!
todo_items = Todo.find_all # get's all Todo items in Todos table.
todo_items.inject( 1 ) { |n,todo| puts "#{n}: #{todo.description}" ; n+1 }
Which might display something like:
1: Feed the cat 2: Clean the cat's box 3: Clean the cat's box again. 4: Clean the cat's box yet again. 5: Shoot the cat.Rails 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.
Does this have anything to do with ExpressionApiComplaints?
No. It addresses your concerns about ProtocolCoupling? voiced in your ChallengeSixVsFpDiscussion? link. Specifically, you seemed to dislike code like this:
def test_criteria criteria_reader = MockCriteriaReader?.new report = InvoiceReport?.new(criteria_reader) ..... endAnd 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).
What DependencyInjection does is leverage some CollectionOrientedProgramming and some simple reflection to eliminate such scenarios. Instead, we'd see code like this:
# Modified to make it clearer how DependencyInjection can reduce this kind of coupling. class ReportProducer? < CriteriaUsingParentHoobajube? require_services :reporter, :criteria_collector def make_report( criteria ) # reporter = Reporter.new( criteria ) @report = reporter.process end def collect_criteria cc = CriteriaCollector?.new # The method of criteria collection is decided by # the injection, which is a class name in a table. @criteria = cc.process # this would return the collected criteria (and store it in a local variable) # which could be passed to make_report or otherwise processed. # We can envision a returned array OR hashtable containing # the data, in which case CriteriaCollector? is a function-object. # Otherwise .process would return some specific collection type. end endReporter 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?.
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.]
{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.}
We 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...
It'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.
In 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".
But that'd miss the point. I digress.
As 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!).
That's the point.
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"
This 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.
You still might see a test in this format where you see something like
rg.make_report( TestCriterion?.new.process )But that would be ONLY for explicit testing of that section of the interface.
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
The 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.
In 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:
def the_function_that_makes_the_report_via_sql_database( criterion )
# ... Whatever
query = "SQL that begins the query here"
criterion.inject( query ) { |q,c| q << " #{c.to_sql}" } # Returns the query
query << "finishing SQL here"
# ... Make the query to the product database with query
end
That'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).
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.
Umm, 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).
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.
My 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
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
Moved discussion to TopDefinitionForSyntax because this one is getting too long (I didn't create that topic, I would note).
It appears that somebody half-plagiarized my anti-OO web-site:
http://www.devx.com/opinion/Article/26776
There are too many things that sound similar to be coincident.
Unless (insert overly dramatic murder mystery music here) you are "Richard Mansfield". And you're 217! And... umm... the Phantom!
It is good to see knowledge spawned from this wiki.
Actually probably from: http://www.geocities.com/tablizer/oopbad.htm
To 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.
Because 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.
[from EnumeratingRegularLanguages]
Why is it a "good test"? It could be nothing more than a MentalMasturbation lab toy.
It 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.
The 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.
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
Don't jump your horses top. You can call your very own arguments MentalMasturbation first, if that word gives you a hard on.
If 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.
If it is a "good test" only for certain domains or kinds of problems, then why didn't you say so originally?
Because unless you are irremediably retarded or, alternatively, in obnoxious trolling mode, this qualification is implied in all software-related discussions.
Like 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.
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
Top:
I moved some of the TQL stuff to separate pages, because it seemed like someone else had lumped it into your page.
Did you move the TQL stuff back to this page? If so, please forgive me. I don't mind if you move it back.
I did not move it here. I have a suspect, though, but it is not polite to name until proven guilty.
PageAnchor: Examples_Complaint
Regarding FP Examples and Applicability
Re: "[topmind] makes no apparent effort to extrapolate on his own what can be done with it beyond the (admittedly oversimple) example."
You 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.
Regarding 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?
But 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]
Regularity 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.
It 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.
HOF'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.
I 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.
This 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.
Counterexamples:
Counter Example #1 in Ruby, using ActiveRecord. Purpose: Using a HOF as a lexical convenience to iterate through a collection of database records. 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.
# Sets up a ORM to the Customer table, assume customer has some fields # and a group of addresses. class Customer < ActiveRecord::Base has_many :addresses end # Sets up an ORM to the Addresses table, assume address has a fields: # street, number, zip and city class Address < ActiveRecord::Base belongs_to :customer end # You care from here on, the previous code only told you what the object relationship is. my_cust = Customer.find_all# Finds all customers, this was in error before, WikiAteMyEdits? my_cust.each { |customer| puts customer.name + ": " customer.addresses.each { |address|# Note the nesting of HOFs, this is harder to do puts "t #{address}"# in eval-based systems. } puts # Puts an empty line. }# End example 1
There you go top. A simple example of how HigherOrderFunctions 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.
If 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.
-- DaveFayram
If 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):
// Approach 1
rs = query("select * from customer natural join addresses where " & criteria);
prev = '';
while(row = getNext(rs)) {
if (row.custID <> prev) {// description only if different
println(row.custName & ':');
}
println("t " & row.address);
prev = row.custID;
}
// Approach 2
rs = query("select * from customer where " & criteria);
while(row = getNext(rs)) {
println(row.custName & ':');
adrs = query("select * from addresses where " & criteria);
while (adrow = getNext(adrs)) {
println("t " & adrow.address);
}
}
(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.)
I am not sure what the actual pattern of repetition is, so I don't know what to make "generic" in this example.
Generally 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.
-- top
Top, 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)".
Now, 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.
-- DaveFayram
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
The 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. So 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).
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.
Also, 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.
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.
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.
-- DaveFayram
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].
Hey TopMind, as far as I know, your web site has no content about WebServices and ServiceOrientedArchitecture. What you think about them?
KissWebServices. If it is within an organization, as you probably would have guessed, I would generally recommend going with a RDBMS.
What you don't realize is that you will reinvent OO programming over and over again in your code. Have fun.
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).
It seems to me that C2 is now in its "fourth age"
1. Patterns 2. XP 3. Philosophy and Religion 4. TopMind
It'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
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:
http://www.geocities.com/tablizer/science.htm
By the way, it is NOT me creating "TopOn?" topics. That is part of Costin's EditWar intimidation methodology.
No, 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.
Would you rather prefer to clean up your ThreadMesses by deleting them?
Is that how you treat all the other threadmess?
One 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
Here is my interpretative summary of how the TopOnPreparedStatements debate is going:
Yes, 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.
Further 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.)
-- DanM
Discussion about ResponsibilityDrivenDesign (moved here from OoIsAnthropomorphic)
I 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.
I 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.)
To 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).
You 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.
-- top
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.
A response to IfYouDontLikeItYouDontUnderstandIt:
In 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?
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
Lack of signatures has made it hard to keep track of who shares what opinions.
I 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?
Top, 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
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.
-- top
[Long rant formerly here deleted. No point.] -- ChrisMellon?
ToughMind 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
Yes. It comes and goes. -- top completely blocked?
(Moved from the highly trimmed InternationalUiExample)
I 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.
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".
Apparently 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...
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.)
Top 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:
During 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.
Put simply then, if you take the inheritance out of inheritance it becomes a useful concept.
I 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. -- MaxStrini?
Moved discussion to BundleSubstanceMismatch.
Vandal watch:
http:RecentChanges?page=TopMind?days=3 http:posts?TopMind
TopMind, how can you be contacted? The email on your tablizer site doesn't work. I am interested in your Fox Music Sequencer.
Try:
http://www.geocities.com/tablizer/FOXSEQ_B.zip
It will likely require some retrofitting for your environment.
Thx. 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. Anyway, 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
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.
QUESTION:
okay - 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.
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
nope, 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. ;) ps: 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.
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....
Top, 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.
Please see ArgumentsAgainstOop, and keep up the hope. --top
TopMind: 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'.
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
[Want hosting for your stuff? I'll give you space for free. Email me if you're interested. -- DaveVoorhis]
I'll consider it. Thanks for the offer! -t
In 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.
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
["most of my detractors have not presented any hard evidence against most of my pivotal opinions and statements"]
[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.]
Why 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 HobbyHorses (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
[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.]
Again, 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
[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.]
I 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).
[Your answer falls squarely in the "insufficient published research" category I noted above. See it, above.]
Please clarify with page-anchors or the like.
PageAnchor: science_self_hypocrisy
Re: "I don't recall you presenting any evidence, hard or otherwise, for most of your pivotal opinions and statements."
For 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
Hello TopMind, looking 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).
I believe it is more similar to RelProject than to TqlRoadmap, I does look interesting --LuxSpes
I was thinking the same thing. Anybody recommend an existing topic to list or discuss that tool? --top
Regarding 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
TopMind 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
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
{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.}
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
You mean UNTIL? Don't need it. I explained already, but somebody deleted the explanation without asking permission.
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.
Next 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.
Most 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.
Its 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.
The 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.
[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.]
I have moved my comments about Table based programming and the MAX language/system to MaxOopsRelational. Sorry for using your space.-- DavidClarkd
Hey... 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...
PageAnchor Complaint-004
Hi top!
I 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.
In 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.
You 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!
Now 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!
But 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!
I 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...
--an observer
Thank 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.
Re: "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."
What 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.)
And 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.)
As 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
I 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.
This is a strong pattern with you.
Your 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?
Which 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.
Or 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!
You 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!
It 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.
Sometimes 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.
If 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:
http://c2.com/cgi/wiki?NodeJsAndHofDiscussion
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
[Please keep the "see also" at the bottom]
See also: TqlRoadmap, RelationalLanguage, CategoryRelationalDatabase See EventDrivenProgramming, ProceduralMethodologies, ObjectRelationalPsychologicalMismatch, DataDrivenPrograms, ArgumentsAgainstOop, CodeAvoidance, TopIsNotEvil, BottomMind See TablesAreCollections for what may be considered the 'opposite' approach.
EditText of this page
(last edited December 3, 2014)
or FindPage with title or text search