Theory Vs Empirical Stalemate

(Based on discussion at InsultJustificationDiscussion)

Despite what TopMind believes, practitioners do not have any social license to blurt technical opinions then hide behind a shield of ignorance. Practitioners are welcome. They're also expected, if they come to a forum about PeopleProjectsAndPatterns in SoftwareDevelopment, to willingly educate themselves.

We have a stalemate where both sides won't do homework that the other expects. I expect you to turn your pet theories into demonstration code samples and scenarios (RaceTheDamnedCar), and you expect me to read and figure out your favorite academic books and papers. This stalemate is because I put much less value on theory than you and you place much less value on empirical demonstrations than I do. This is largely because I believe that software productivity is mostly about psychology (PsychologyMatters) and fitting people's personal mental models, while you feel it is more about finding the one true central universal "math" or model. --top

There is a serious problem with what you say, TopMind: you claim to favor demonstrated code examples, yet the 'technical opinions' you blurt tend to not contain such demonstrative code examples of a claim. Sure, sometimes you write up some code (e.g. in GuiMachineLanguage), but rarely does it demonstrate anything relevant to the argument (e.g. that you don't still need scripting, improved support for CrudScreen relative to HTML++, etc.), and it certainly doesn't demonstrate the wide variety of other claims you make (that it meets real-world needs, that fanboyism will destroy any app-lang specific solution, that there's a 'security' benefit). If you wish to use demonstrative code examples to prove your arguments, I can respect that method (in profession, if not attitude, I'm a practitioner too). But your execution of your favored approach to argument leaves much to be desired, and you regularly fill in the gap with distractions (RedHerring), illogical leaps (NonSequitur), and unjustified or unjustifiable assertions (HandWaving), sometimes all at once. Even if you don't believe your that bad, you should at least accept that many other people do believe you're that bad. The fact is, even if you don't put much value on theory, you must still rely upon it to bridge the gap between a code example and a claim that it achieves some useful property. But, because you are inept or uneducated in both theory and logic, you attempt to bridge that gap with sophistry (or fallacy, since you claim to be so 'innocent' and 'ignorant' despite being told off repeatedly).

The GuiMachineLanguage discussion is generally an exception because it requires predicting the future and human behavior with regard to acceptance of technology (AKA "marketing"). Both sides will be on fuzzy ground here. You too have no double-blind peer-reviewed certified study about the progress that HTML++ will make in the future. You also only can make educated guesses. This gets back my complaint that you slide between loose and tight evidence requirements to suit your particular argument instead of applying the standard even-handed. Why should I have to "prove" what will happen in the future while you don't? -t
GuiMachineLanguage is not an exception. You slipped off the road into unjustified claims long before you got to 'marketing' issues, such as your claim that your GML 'four-column' structure is better for CrudScreen from a whole-system perspective. And, since you are apparently illiterate, my argument has never been that HTML++ "will" make it for the indefinite future. I have argued that it "can" make it for a few more decades, for which I provided reason (see LimitsOfHtmlStack).
And your 'complaint' about 'sliding between loose and tight evidence requirements to suit a particular argument' still strikes me as irrational. Whatever it is you are imagining to be 'standard even-handed' is not standard. Standard is arguing from evidence and statistical principles (inductive and abductive logic) where necessary, and arguing from formal principles (deductive logic) where possible, and that is exactly what I do.
Tell me, what "statistical principles" do you use when you claim that HTML++ will likely eventually be CRUD-sufficient in our lifetime?
Define "CRUD-sufficient". If your definition is practical and technical rather than idealist, HTML++ is likely already there, short the tweaks for TopMind's personal favorite keyboard bindings. And, though I won't bother to gain widespread statistics, my observations have been that software components tend to gain features and tweaks over their life-cycle rather than go the other direction.
"Personal favorites"? The down arrow behavior is very common in mature table and grid applications, including the very first microcomputer spreadsheet. If it was merely a personal preference, then it would not likely be so common (Excel, FoxPro, Access, CFgrid, VisiCalc, dBASE, OOO-Calc, and probably others). I'm always guilty until proven innocent with you.
Whether your favorite 'arrow behavior' is common or not isn't a technical issue. You can say that the arrow behavior isn't 'conventional', and even suggest it 'irritating', but I see no valid reason you could call it 'incorrect', unless you define "grid" in terms of a specific set of keyboard bindings.
- If it violates enough conventions, then it's equivalent to "incorrect" either way. The down-arrow allows for column-downward data entry, which is a fairly common need.
As far as the criteria for CRUD-friendly, I'd say to be able to have nearly all the widgets and GUI behaviors described in WebBrowserMissingWidgetWorkArounds in the same screen (if applicable, or else same app) in at least the 3 top web browsers, and still work on the next integer release in 2 out of 3 of the major browsers. -t
"Friendly" implies a much greater degree of support than "sufficient", does it not? And to me, 'CRUD-friendly' would need to be friendly on the development-side and server-side, too. Anyhow, I expect www.extjs.com widgets qualify for your 'sufficiency' spec. They are supported across three major versions of FireFox and three major versions of Internet Explorer and two major versions of Opera. Anyhow, we shouldn't digress much further on this subject.
It's speculative at this point whether extjs will work with all the widgets and form types together. I've had problems mixing other HTML++ widgets. And I agree about digressing. We should put these items in the proper slots eventually. -t

You claim PsychologyMatters on faith. You claim I want to 'find one true central universal "math" or model'. However, unlike you, I do not treat ComputerScience as a religion and I'm only marginally interested in SoftwareEngineering. I make no claims about universe; I simply focus on obtaining sets of properties that I deem useful to use-cases that I believe have a demand, and I make no assertions about what is "universally better" or anything else (indeed, I find your idea of a universal 'better' to be illogical and irrational; InterCal is likely 'better' than C for frustrating readers of code, for example). The useful properties I tend to focus on are: security (secrecy, authority, liveness), composition, scalability, modularity, configurability (policy injection, dependency injection, configuration parameters), process accounting, concurrency, disruption tolerance, persistence, graceful degradation, resilience (self-healing), well-timing properties (real-time, deadlines, temporal windows), operations safety (termination, progress), type-safety, and performance. I always feel insulted when you take a look at a list like this, you only notice the last two items, wave performance away as though it isn't relevant, then start whining about me turning it into a typing debate... don't even start.

I don't know what you are referring to with regard to "waving away performance". If you are going to introduce specific instances of my alleged devious behavior, then either cite them properly or don't reference them at all. Half-ass citations are merely fodder for flame-wars. -t

As far as your list, I agree we should try to optimize most of them also. I just disagree with you on how to go about it. -t

And don't get me wrong, I am not a CowboyCoder against abstractions in general. But what I have found by experience is that big grandiose abstractions tend to fail harder and uglier than small, local abstractions, and that one must plan for exceptions to the rule (deviations from abstraction) such that deviations don't bring down the whole thing (EightyTwentyRule). Design machinery with tolerances for grit and bad replacement parts, because you won't always be around to police the machine. -t

Sure. Big, grandiose abstractions - like the general idea of tables and procedures - fail harder and uglier than small, local abstractions. One must plan (BigDesignUpFront) for the exceptions to the rule (deviations from abstraction) such that deviations don't bring down the whole thing (such as by having security, safety, scalability, composition, modularity, configurability, concurrency, well-timing, etc. issues). Languages should be designed to support modularity such that components can be fixed and replaced individually. I see nothing to disagree with here. I would say that you are the one who favors big, grandiose abstractions with your positions in TableOrientedProgramming, your anti-scripting stance on GuiMachineLanguage, your favoring 'entity' tables above 'narrow' tables, your attempt to generalize TypesAreSideFlags, etc. As noted above, I favor properties. 'Properties' (like scalability and concurrency and performance) are categorically different from 'abstractions' (like pure functions, procedures, actors, sets, lists, records, characters, numbers). I'm a fan of having many primitive abstractions, each with its own relatively narrow role to play. HorsesForCourses, PickTheRightToolForTheJob. If abstractions aren't pulling double and triple-duties, optimizations for performance are easier to automate without sacrificing the various other useful properties, and composition can be made scalable via layered language (e.g. procedures can use functions, but not vice versa).

I will resist the urge to rekindle those subjects in this topics. If you wish to pull something out for specific analysis that illustrates issues in this topic, then please do. -t

The above list IS a set of specific examples for analysis. If you've forgotten, though, the point of those examples is that TopMind - not I - is the one who favors 'big' abstractions, such as 'use tables for everything', 'use callbacks to server for everything', etc. That's a meta-argument position, is it not? Individual arguments are specific points in an argument discussing habits across arguments. There is no rational or logical reason for you to rekindle those subjects. There is no rational or logical reason for me to pull something out for specific analysis, because your 'anti-scripting stance for GML' IS ALREADY something for specific analysis, as is your entire concept of TableOrientedProgramming.

I generally meant big domain abstractions, not big tool abstractions. -t

I program a computer, not a domain. I represent input and output. I represent many 'tool' abstractions for program components (actors, functions, procedures, message channels, sets, maps, lists, records, variants, numbers, subscriptions, mutexes, cancellation points, threads, stacks, queues, etc.). But, with two exceptions, I very rarely represent 'domain' abstractions at all - much less 'big' ones. Those exceptions: planners, and simulators, which must know something of a domain in order to plan for it or predict it. For planning and simulation, I favor LogicProgramming idioms (and I'd favor a LogicProgramming language, too, if it readily fits the rest of my toolset) - SQL supports a few such idioms.

Anyhow, there is reason to believe you favor big 'tool' abstractions. I also like big tool abstractions, albeit specialized to the job.

What would you consider to be a big 'domain' abstraction?

OctoberZeroNine