Extracted from GuiMachineLanguage. This discussion ultimately distracts from communicating TopMind's vision of TableOrientedProgramming for GraphicalUserInterface. But I do not feel it should be outright deleted, so I've moved it. I'll try to refactor the salient points back into the original topic.

-----------------------------------

'''Security Issues''' 

When analyzing the security issues, one kind of scenario to consider is "recursive events". For example, form-A may have an "on-open" trigger that opens form-B, and then close itself. Form-B may in turn have a trigger that does the same to form-A. Thus, they run each other back and forth. Other stuff could be put into such triggers as to potentially have an almost infinitely loop that could make it TuringComplete.  -top

''I know you hate me for my adherence to definitions and logic you'd prefer to ignore, but termination properties aren't 'security' issues, and while TuringComplete does imply infinite loops, the converse isn't true (infinite loops do not imply a language is TuringComplete). Ref: http://en.wikipedia.org/wiki/Affirming_the_consequent''

The more "code time" the hacker gets, the more damage they can cause. TC is only secondary to that issue. TC is the golden goal of the hacker, but there are also silver and bronze standards if the hacker gets some command time. If the number of trigger cycles and/or the number of lines of code is limited somehow, the hacker has fewer options and/or time to do something complex. I agree that ideally they'd have none, but *dictating* such decisions is not the job of this language. It just facilitates choices. (Limiting trigger cycles and/or code lines would not be the only security feature.)

''If the amount of damage the hacker can cause is merely a function of time or of doing 'something complex', you have security issues regardless of termination properties. If not, then termination properties aren't security issues. Either way, termination properties are orthogonal to the security issue. I suggest you stop making claims one way or the other about 'security' unless you're willing to spend some time learning the field (consider starting with IwannaLearnComputerSecurity, though WikiWiki is a rather poor site for this subject; www.erights.org is good). I am of the belief that security is '''not''' a separable concern (http://www.erights.org/talks/no-sep/). To say that you're not going to make decisions for security is pretty much to say you're designing an insecure language/protocol/architecture. But it's probably better to not make any decisions unless you know what you're doing.''

''That said, I'd simply suggest you avoid 'on-open' triggers. They're bad mojo. Well, more technically, they cause problems for scalability of the GUI for such goals as ZoomableUserInterface, robust persistence and regeneration, and composition/sharing of documents (i.e. including one document within another). They also hurt high-performance display through PartialEvaluation. If one was to make a big list of all the neat features they'd want their DomainSpecificLanguage for GUIs to support, I'd bet money that 'on-open' triggers would be directly or indirectly harmful to well over half the features on that list.''

You are not being specific. You can't just claim that clicking button X gives puppies cancer; you have to SHOW how it happens. 

''In this particular case, I'm making a suggestion, not a claim. You're free to ignore it at your own peril. You're free to analyze the reasons I offered for my suggestion for merit on your own time. If you're curious, analysis on the robustness and scalability and composability issues surrounding 'on open' events, look up ImmediateModeGui, DocumentDefinitions, and the comparison in the latter between applications and document UIs.''

What kinds of triggers are allowed should also be configurable. The minimal trigger would only allow actions that notify the server, and letting the server change the client UI state as needed. But I'm sure many authors will find this limiting or slow. Having buttons or menu items that un-hide ("on-open" is perhaps the wrong phrase) new and existing forms/windows/widgets is a common and useful need. Waiting for the client to do such makes responses sluggish. 

''I disagree. Strongly. That simply introduces a big-ass semantics conflict between document authors (who are deciding which triggers their documents ''use'') and the browser users/implementors (who are deciding which triggers are ''respected'') without introducing the required negotiation layer between them. A standard with 8 boolean configuration variables is really up to 2^8 = 256 standards. It takes a ''handshake'' to negotiate which of these standards to use. And, since authors are typically not around to make that handshake, it's not going to happen without defining an agent to perform the hand-shake and rewrite the document for them. It's pain, it's complexity, and it's AccidentalDifficulty all introduced by your silly, naive belief that choice is usually a GoodThing.''

* I'm not sure what you mean. The browser builder does not control (choose) what triggers are allowed. The server for a session does. For example, let's say the default is to only allow sending form content when button is pressed. If the app session server wants buttons to also be able to un-hide forms without a round-trip, it then explicitly grants that permission. (Different sessions would use different GUI browser instances.)
* ''Same issues apply. Just replace 'semantics conflict between document authors and browser builders' with 'semantics conflict between document authors and server builders'.''
* Le scenario, Senior?
* ''The scenario: a document author wants to have an (independently developed or configured) document server provide his/her document. If the server doesn't respect how the button-events were written, the document is broken when provided from that server.''
* So you are talking about cross-server sharing and/or links. I generally was targeting "applications", not competing with a web-browser. We already have those, and they are fine for semi-static content. An "app browser" generally wouldn't allow different servers to manage forms within the same "app", which we'll consider an MDI base window for now. If you hyper-link to another app, the hyperlink would create a new app-browser instance, and thus another MDI base window. The MDI window is thus the solid boundary between one "app" and another. It would still be possible for the server to integrate info and "pages" from different sources if desired. Thus, there's a way to meld them in a single MDI without creating client-side security complications.
* ''Ah. So you mean that you don't care about composition of applications, service mirroring and load balancing, and such. Well, aside from the fact you still can't compete with HtmlDomJsCss (which is also going through its own upgrades over time, along with HTTP, to better target 'WebApplication''''''s'), and aside from the common demand for shared access to applications, and aside from the fact that the future seems to be steadily moving towards supporting user composition of disparate services into a single application-style interfaces (e.g. portals or MashupMaker or SmartWiki), you might be able to succeed! Good luck!'' 
* See Page-Anchor: "Server-mixing"

The option to only allow one "on-X" trigger per user-performed event could also limit cascading on-X's.

''Behavior in response to user-input (e.g. due to a button press, due to mouse hover, etc.) is okay (good mojo). That doesn't cause any of the scalability or robustness or composition/sharing problems associated with events based on mere 'display' of the document. It's on-show or on-open that's problematic.''

Possible security settings set by user (client) and/or server for a given session and/or domain:

* Number of trigger cycles per user action (triggers triggering other triggers)
* Number of trigger cycles per server packet
* Max number of statements allowed to execute per user action 
* Max number of statements allowed to execute per server packet
* Limit triggers to only server messages (such as send form content, aka "submit")
* Limit triggers to a given set, or perhaps "level" group
* Limit content changes (such as text and label) to only server commands.
* Limit subroutine call nesting (zero = no subroutines allowed)
* Limit access to branching operation(s)

''Those aren't security settings. Process control and accounting, maybe.''

Regarding "hiding", I'd suggest having these "show-states" (when applicable):
* Hidden (default for forms/windows)
* Minimized (with visible place-holder. Not applicable to basic widgets.)
* Regular (default for widgets)
* Maximized (not applicable to widgets)
* Automatic, for auto-popup or auto-expand widgets

An "onShow" trigger would happen when transitioning from either of the first two to either of the last two. 

''Show-states are fine, but transition triggers are still bad-mojo.''

You mean like "on-change" triggers? Can you provide a few scenarios that demonstrate why they are bad?

''I don't mind state-based display properties (e.g. where the document simultaneously includes information for display at different states), but '''display events''' are very bad things. Scenarios where they are bad:''
* Analysis. (You can't examine just part of a composed application with on-display events. You need the whole damn thing because you can't readily determine which piece of on-display code goes with which component. This also hurts accessibility; to whatever degree you can't analyze a document, you also can't transform it automatically to fit different screens or support blind users and such.)
** ''Where did you get this? Each component has a unique address.''
** Perhaps you can explain how that is relevant to breaking down code of on-display events.
** ''Perhaps I misunderstood your statement. Please restate it or give an example.''
** Perhaps I misunderstood your statement. I already asked for a better explanation.

* Initial composition. (When you're using display-events, you lose the ability to piecewise construct the application, as the events get to be associated with the whole composition rather than with individual pieces. This means the events, if they are used, grow to reference more display artifacts.) [in small words: app becomes BigBallOfMud. Pieces all tied together by side-effects of events.]
** ''I have no idea what you are talking about.''
** I'm going to blame that one on your lack of domain competence.
** ''You mean I'm lousy at deciphering bad writing?''
** No, it's more like you're trying to read trigonometry with an education that never passed basic arithmetic, and you're ''blaming'' the trigonometry.
** ''If that was the case, then you'd be able to bust me left and right with clear, objective proofs.''
** I'm fairly certain that for objective proofs to be "clear" ''to the audience'', there are some prerequisites on knowledge. For example, you can't just bust a child left and right with objective proofs about, say, the properties of RelationalModel - no matter how clear they are to ''you'' as the speaker. Do you believe otherwise? What if the child were not only ignorant, but a fully HostileStudent? Some say that YouCantLearnSomethingUntilYouAlreadyAlmostKnowIt. If you ''"have no idea what [I'm] talking about"'', then I have no places to start... and that's ''if'' I wanted to educate, and you wanted to be a student. 
** ''I've been in cases where somebody will say, "X cannot do Y, you big dummy!". Then I show X doing Y, and they shut up. I don't even have to insult them, the works do it by itself.''
** That implies they had some idea of what you were talking about, does it not?
** ''You are just making up convoluted excuses to be obtuse.''

* Network disruption. (If a network event on-display goes sour, the document or application may be in an undefined state. This is anti-robustness, anti-disruption-tolerance, anti-offline-friendly. Document is no longer data-driven or ImmediateModeGui.)
** ''This is a problem no matter what. If the server croaks, it croaks.''
** Not really. There are plenty of designs that allow useful work to continue in the face of network disruption. Again, lack of domain competence?
** ''Yes we could add such, but I don't think it's worth it to bulk up our language with many of those issues. You seem to want to over-engineer this doo-dad, just like you did with the "sharable" language type-a-tron contraption of yours. I don't want to repeat that kind of debate here again. -t''
** Design for such doesn't require "bulking up our language". It's the other way around: it requires removing stuff from the language. On-display events are one of the big things needing removal.

* Sharing. (If you wish to share the application between multiple users, the semantics of different users representing the application in different states (e.g. minimized vs. maximized) are poorly defined.)
** ''We already discussed this. Not a real issue.''
** Where did we discuss sharing an application between users? I do recall discussion of secondary composition/sharing between servers. I'll note that in GuiEngineGoals, one of those you listed is: ''"Ability to migrate displays/window across systems. An application should be able to run on a server and be displayed on a client and the display should be able to move from client to client. '''Even better if the display can be rendered on multiple clients at once (e.g., to enable screen/window SHARING)'''"''. Are you still going to say it isn't an issue?
** ''How about some sample scenarios. Your writing is not clear.''
** How about you detail scenarios in your GuiEngineGoals page, if you want more than one? I already provided one sample scenario on the opening line for those with a eyes to read and a brain to think: different users (i.e. two or more, call them user A and user B) sharing the GUI (multiple clients at once) represent the document in different display states (e.g. minimized vs. maximized - i.e. user A has the application minimized, and user B has the document maximized). The proper display event for this state is not defined.  
** ''Use off-the-shelf remote screen-mirror software. I don't want to gum it up with low-probability scenarios. Wait until version 6.0 for that kind of crap.''
** Why bother gumming up your design with on-display events? That crap can wait until version 6.0, after you've proven you need it.

* Client-side scalability. (ZoomableUserInterface ideally requires that the resource consumption of the GUI be bound not by the number of display artifacts, but rather by their screen real-estate. Events on 'hide' and 'minimize', especially, mean the otherwise possibly ZoomableUserInterface will be consuming MORE resources as objects are hidden.)
** ''If "minimize" etc. is not applicable to zoomable widgets, so be it. It doesn't need to be applicable all widgets.''
** Applicability to certain widgets is 100% irrelevant to anything I wrote.

* Server-side scalability. (The relationship between application and server is maintained in part by on-display events, which implies that the server will in the general case need to maintain state for each user's view of each application. This is not scalable for servers, and especially resists caching, intermediate distribution (which is an exponential bandwidth saver), and persistence.)
** ''Multiple servers can run the same application. This is not a problem.''
** That's irrelevant to scalability. 

* Secondary composition. (For similar reason to server-side scalability, the 'view' being handled as a relationship between browser and server greatly hinders ability to embed, link, stylize, and extend applications.)
** ''I see very little need for this for *applications*. I'm not proposing dismantling web browsers. -t''
** You still lose the ability, which is still a disadvantage, even if you don't care about this one in particular.
* Undefined states. (What do you do for persistence? What about when recovering from a crash - can that be solved in general by the browser? How about tiny 10x10 pixel state? Partially occluded?)
** ''Same way it's dealt with for web apps. -t''
** Ah... you mean: 'requires SelfDiscipline, foresight, and a really good understanding of the issues'. That'll do, but it ranks your language pretty damn low on the FourLevelsOfFeature.
** ''If that keeps it relatively simple, focused on purpose, and easy-to-try without lots of investment in a convoluted framework with lots of up-front investment and buy-in (TechniqueWithManyPrerequisites), then yes.'' -t
** Are you claiming these hypothetical properties are achieved by your favored design? Or are you just suggesting, hypothetically, that ''if'' they are achieved, then you ''might'' have a point?
** ''It was being compared to HTML-based web-apps. Did they acheive them? As far as simplicity in concept, I beleive they have. Yes, things like recovery if disruption have to be dealt with on the app programming side, but it's a worthy tradeoff to keep the standard simple. It can be gold-plated AFTER acceptance and penetration.''
** The above was intended to question the peculiarities of your favored design. Merely pointing out that on-display triggers exist in a successful standard (HTML-based web-apps) says little about whether they were hurtful vs. helpful, much less whether that element of the design helps achieve relative simplicity, focus, and ease-of-use relative to alternative designs. What makes you believe that these on-display triggers were of significant aide in keeping the standard simple, focused, easy-to-try without lots of investment in a convoluted framework, etc? 
** ''This draft standard does not depend on on-display triggers, and thus I will not discuss that feature any more. Let's pretend it's not here and move on.''

''Depending on perspective, these are problems or lost advantages. On-display events are a very good decision if your goal is to take a wheelbarrow full of GuiEngineGoals that could have been achieved at the ElegantSimplicity level and dump them between the SelfDiscipline and TuringTarpit levels. (See FourLevelsOfFeature.)''

''And, while you might not care for some of the advantages you lose, you need to ask yourself: "but what, really, do I '''gain''' from on-display events?" Really. What? Well, there are a few features that can be achieved by their use... the most important being the ability to trim server-side processing and network usage after minimizing the application or hiding a live-data form. But this can be achieved by other means ''without'' sacrificing ElegantSimplicity for other features. Display-properties in reduced view can simply be made part of the application definition such that only the app-browser, not the server, is aware of which view it is displaying to the user. Use of PublishSubscribeModel would reduce the relationship between app-browser and server to well-defined states (subscribed vs. not subscribed) and would allow the browser to decide to unsubscribe anytime it doesn't need to maintain the view. This has none of the above issues, and provides some other advantages (e.g. well-defined 'synchronization' even for documents that aren't displayed).'' 

''Anyhow, I feel like you're going about this the wrong way. You shouldn't resist removing a feature until someone convinces you that you don't need it. You should resist adding a feature until you or someone proves you need it. You do, after all, wish to avoid LanguageIdiomClutter.''

------

''Without support for abstraction (e.g. sub-routines, loops over variables and collections), I suspect your GuiMachineLanguage will fail. Miserably.''

Complex imperative processing is not its intended job. That would be left to the app language. '''It is not meant to compete with the app language.''' Client-side scripting may also be permitted, but I am mostly just focusing on communicating with the GUI primitives. I am not sure what you are envisioning. 

''When I say "fail. Miserably." I don't mean merely that it can't compete with the app language. I mean it can't compete even with other DomainSpecificLanguage''''''s for GUI.''

(Variables could be emulated using hidden widgets, or invent a dummy widget type to store values.)

''I did think of that, but supporting variables is more than just storing values. It also means accessing and using them.''

''It won't support the necessary forms of compression or reusable partial compilation. It will fail in terms of performance, and it will be no better by any other measure. There would be very little reason for other languages to compile down to it.''

I assumed interpreted. I suppose the base set up could be "compiled", but that's not my focus. HTML doesn't have to be compiled to use-able, I would note.

''Where do I start? I'll make a list:''
* My mention of "compile down to [GuiMachineLanguage]" didn't actually refer to "compiling GuiMachineLanguage". Two different things. If you truly have something like a 'GuiMachineLanguage', I'd expect it to service effectively as a compilation target language for other display languages (like HTML).
** ''Using HTML as a test scenario, it indeed can represent HTML. In fact, it could represent dynamic HTML if each tag has some kind of ordering value (such as a hidden/internal attribute "~tagOrder" or the like). Static HTML doesn't need that because it can use the sequence numbering already described. -t''
** Is "''can represent'' HTML [with enough finagling]" all that "''service effectively as compilation target for'' [HTML]" means to you? 
** ''I guess I am misunderstanding your complaint. How about an example. -t''
** My first bullet had a rather simple complaint: you either skipped or disregarded the modifying preposition  "down to" following "compile", and thus read something different from what I had written. But perhaps you can show me some advantages from 'representing HTML' in this GuiMachineLanguage in order to demonstrate a ''"reason to compile down to it"''. Without such a reason, I do not believe that it will 'service effectively' as a compilation target.  
** ''I don't care what you believe. I won't believe it until you show a realistic scenario(s) of bad things happening. Your "summary" assessments are not very useful. Specifics, details, details, and specifics.''
** Sigh. This isn't a situation of me saying "BadThing''''''s are happening", TopMind, and I have no idea how you're reading that from what I've been writing. I'm saying that unless you (or someone) can show GoodThing''''''s happening, your pet GuiMachineLanguage will fail. Miserably, no less. People aren't going to switch to a product that provides no demonstrated advantages over HTML, especially when HTML is already established. Heck, it would take more than a few advantages to make the switch. HTML is a better GuiMachineLanguage than yours merely by virtue of incumbency - the number of existing compatible browsers makes it 'service effectively' as such, and both GoogleWebKit and MicrosoftSilverlight use it as such. Unless you can provide a ''"reason for other languages to compile down to [your GuiMachineLanguage]"'', as I originally stated, your particular brand of GuiMachineLanguage is already sunk. Kaput. Dead. That 'specific' enough for you?
** ''I assume you mean HtmlDomJsCss. If you like HtmlDomJsCss for creating GUI's for things like business forms and apps, fine by me. But many of us moan at HtmlDomJsCss. (Related: WebGuiWikiPoll)''
** It doesn't matter here whether we 'like' it, only that we use it. What matters here is that GuiMachineLanguage has no demonstrated advantages over the incumbent. Why would we, uh, 'moan' less at your GuiMachineLanguage?
** ''See Page-Anchor: "Why"''

* Your assumption that GuiMachineLanguage was to be interpreted isn't relevant. The language can be and would be compiled... at least, assuming it becomes successful. Likely some JustInTimeCompilation would be involved. Even JavaScript is compiled nowadays.
* While it is true that "HTML doesn't ''have to be'' compiled to be use-able", it commonly is compiled in the sense that compilation is just staged PartialEvaluation and most (maybe even all) browsers compile HTML into an internal graph of document objects and plugin objects. 

''Supporting abstraction doesn't require giving up a termination-guarantee. But it would make your language a lot more complex, since abstraction means supporting variable inputs and outputs.''

Please clarify.

''Hmmm... perhaps you might read it as ''"support for [sub-routines and loops] does not require [making your language TuringComplete], but would make your language more complex."'' It's a weaker statement than I originally made. Does that help clarify, or were you actually looking for an explanation?''

-------

PageAnchor: "Why"

Re: "What matters here is that GuiMachineLanguage has no demonstrated advantages over the incumbent."

''It is a suggested first step in "doing HTTP-friendly GUI's right", and avoiding locking a GUI standard into a particular programming language to avoid paradigm holy wars. Scripters don't want to use Java, and thus Java as a GUI tool mostly failed. And, heavy "typers" don't like DOM's JavaScript ties. Plus, DOM is meant mostly for e-brochures, not desktop-like GUI's.''

How many 'steps' are in this plan of yours? Perhaps you should describe the proposed end-to-end system somewhere, and describe the advantages of the overall system - what you're doing "right" that HtmlDomJsCss is not doing "right". 

As far as your "HTTP-friendly + not tied into a particular language to avoid HolyWar", I'm not convinced. But, then, I consider protocol to be part of language - every bit as much as the HTML or GuiMachineLanguage - and quite worthy of HolyWar. Also, on that last point of yours, we can have it both ways. Heavy 'typers' are free to use GoogleWebKit and literally use HtmlDomJsCss as a Gui Assembly Language. 

''If you like HtmlDomJsCss, then I am probably not going to convince you to even consider such.''

Why do you insist on repeating such things? Shall I repeat myself in return? ''' It doesn't matter here whether we 'like' it, only that we use it. What matters here is that GuiMachineLanguage has no demonstrated advantages over the incumbent.''' I don't like HtmlDomJsCss. But ''why'' would I like this some strange guy's lonesome unsupported idea called GuiMachineLanguage enough to invest in it when I already know that HtmlDomJsCss works, is supported, has neat little projects like Mozilla Prism for even more support, etc.?  Why does it even ''deserve'' investment? What ''advantage'' would it offer? 

'' I'm basically raising the question: should the "GUI" protocol be a kind of "assembly"-like language, or a higher-level language such as JavaScript, Java, Python, Ada, etc? Fans of those various languages will probably root for their language, but I'm hoping some will realize that hard-tying to a particular high-level language will likely doom it, as it has past attempts (Tcl, Java, JS+DOM).''

I'm hoping some will realize that DomainSpecificLanguage without accompanying and effectively integrated support for GeneralPurposeProgrammingLanguage will '''doom it''' to becoming a hacked mongrel of plugins and scripting languages, as has been proven repeatedly, so we might as well design it into the system from the beginning to at least avoid that 80% slow buggy unstandardized version predicted by GreenspunsTenthRuleOfProgramming.

''Red herring. This does ''not'' prevent plugins nor client-side scripting.'' 

You misread me. I did not say your system is incompatible with plugins and scripting. I said that systems with hacked-in support for client-side plugins and scripting should be counted forever among the doomed/damned. Indeed, I fully expect your GuiMachineLanguage would be among these, providing it were ever to become successful. Client-side scripting and plugins - and maybe cookies - would be hacked in after-the-fact and would ultimately defeat every subtle properties that you were aiming to achieve (e.g. your vaunted 'security' settings, being 'not TuringComplete', your goal of keeping complex logic in server, workarounds to your arbitrary 'talk to one server' limits, compatibility across application-browsers, your goal to "avoid hard-tying to a particular high-level language", etc.)... though, in this case, it doesn't seem there is much of value to be lost.

''But I will note that many of the plugins and client-side scripting are because existing standards don't handle '''common and typical''' features of GUI's available since the early 90's. I just want to move web GUI's up to the 90's instead of the 80's. If the GUI browser natively supported things like combo-boxes and field formatting validation, something ubiquitous in 90's GUI's, then we wouldn't need to include 2,000-line JavaScript scripts to do it.''

So you aim to replace HTML rather than lobby to add combo-boxes to it? Well, I like your chutzpah, but I must question your wisdom.

''That's just one example. There are other features that HTML either lacks or does not handle well.'' 

You'll eventually need to compile a list of such when developing GuiMachineLanguage. I doubt you'll find many that won't integrate well with HTML.

''You can only bend something so far out of its original use before it starts to cry uncle. Related: WebBrowserMissingWidgetWorkArounds.''

True. That's why script and plugin systems that weren't designed for it from the beginning are '''doomed'''. Including HtmlDomJsCss. It'll just take a system that can ''provide demonstrable advantages'' to replace it. Which apparently excludes your GuiMachineLanguage.

''I agree that a system to register new "widget types" and manage the integration of them with existing stuff would eventually be needed. If you are saying that you will not consider/ponder the idea of GuiMachineLanguage *until* a working prototype exists, then feel free to leave this topic. Nobody is making you stay.''

Do you believe a working prototype will demonstrate an advantage over HTML? Because what I'm looking for is (rational) reasons for such a belief.

''HTML has no event-handling, other than submit-and-repaint. That's why HtmlDomJsCss was adapted in (mentioned above). Plus, it could perhaps implement HTML. It's comparing different kinds of things.''

Oh? What language will your event-handlers be written in? Preparing to reinvent G''''''mlDomJs? 

Anyhow, when I said 'advantage over HTML' above I should have been more specific and said 'advantages over the HtmlDomJsCss', which happens to be incumbent. The incumbent has enormous advantage. Merely matching the incumbent feature-for-feature would guarantee you fail. Unfair? yes. But it's why WorseIsBetter if it gets there first.

--------
PageAnchor: "Server-mixing"

Well, I believe the "mashup" movement to be mostly a fad, similar to the "push" fad of the late 1990's. 

''"push" technologies are pretty popular now. Re: Twitter, RSS, e-mail. I believe the future will prove TopMind wrong about the 'fad' status of mashups, too.''

Organizations generally want to control their applications and content. The "central server" approach still allows cross-server sharing, as long as the central server permits it and manages it. Thus, it's "controlled mashups".

''Users also want to control their applications and what is presented to them. I wonder who will win? Content providers, or content consumers? As someone who consumes content from more outlets than he provides it to, I think I'd rather invest in the latter.''

As far as DistributedProgramming, a central server (from client's perspective) does ''not'' prevent distributed computation. For example, a Google search may send a thousand servers into parallel content hunts. However, only one server needs to report back the finds to the client. We don't need bunches of servers for that. The user can only digest a few thousand finds at the most anyhow. 

''Uh... I never suggested it 'prevents distributed computation', though it hurts the ability of the client to construct such computations.''

Show me some common needs for such and I'll start caring.

'':Rolls eyes: We don't even 'need' the Internet; humanity survived most of its history without one. Client-constructed distributed applications are useful for data-fusion and command+control work (e.g. controlling vehicles, cameras, etc.). For regular users, it also allows a more interactive web where clients interact with one another. The vast majority of video-games and chat programs and interactive systems on the web today would be more efficiently constructed with standardized support for client-side integration into a distributed network.''

'''The "server" can be on the client/desktop''', and thus talk to gajillion other servers. I never said the server had to be far way. The only requirement is that a single "server" (near or far) manage the GUI. This still leaves a lot of flexibility. I run local "web apps" all the time (however, better packaging standards for such would be nice). If you have speed- or hardware-intensive needs that won't work under this, fine. Nothing is good for everything. 

''Having a "server" on the client/desktop only reduces latency. Unless you're talking about client-side server being a standard part of the architecture, supporting mobile code and such, the architectural issues remain. And while it's true that nothing is good for everything, I feel it necessary to suggest that some technologies and architectures are good for nothing relative to competing technologies. Ultimately GuiMachineLanguage is mobile code. The rather arbitrary limitation you insist on adding (can only talk to one server) is one they're working hard to remove from JavaScript in its next major version. (A lot of ObjectCapabilityModel went into that effort.) There are reasons for that.''

Again, show me some common needs for such and I'll start caring. 

''I don't care whether you care, probably because I also don't care whether you fail due to your ignorance, lack of research, etc. Your pet project. Your responsibility to understand the needs, the reasons behind modern developments to JavaScript that will be competing with your idea, etc. Your job to convince yourself that you shouldn't care. Your choice to 'default' to not caring in the face of ignorance.''

* Languages in use tend to keep adding features as they age to "keep up" with the competition, real or perceived. Parallelism is the current flavor of the day. Often this chase is fad-driven, largely so the feature checkbox matches other language so that one can sell the idea to PointyHairedBosses. 
* ''Languages add features to either keep up with demand or to create it. Competition rises to meet that demand when languages fail to do so, but the incumbent advantage is nearly insurmountable. Parallelism has always in the past been the 'long-term' future for all computing architectures, and is now being realized: processors of 4-8 cores, more processors, more machines, more networking, more tabs in the browser, more multiplexing of operator input, more sensors, more actuators. Do you honestly believe it to be a passing fad?''
* On the app-side, Yes. There are ways to partition processing without having the app developer overly concern themselves with it. And more collection-oriented features or tools will also help out. For example, searching an array using predicates instead of index-and-loop can be parallelized without having to explicitly manage threads. As far as the browser, one processor may manage networking I/O, and another the GUI, for example. Having a different chip manage each tab is silly, and will probably fail to help speed because of the high cross-coupling of related info for such. Common idioms such as progress bars and status tracking for batch reports could also be farmed off to a different process also, not unlike the "download manager" in FireFox.
* ''If you believed app-side parallelism to be a passing-fad, that would suggest you believe applications will be bound to a single processor, that protocols will involve primarily synchronous (wait-for-the-result) protocols for remote calls, etc. - as it has been in the past. But it seems what you actually believe is that app-side will be highly parallel, and that the languages, protocols, and programming environment will progress to the point that much parallelism can be achieved safely and correctly with very little explicit effort on part of the application developer. That's not a 'passing fad' at all.''
** It appears we generally agree then.
** ''I wouldn't go that far...''
* ''RE: ''"Having a different chip manage each tab is silly, and will probably fail to help speed because of the high cross-coupling of related info for such."'' - there actually isn't all that much cross-coupling of related info between tabs in a typical application-browser. Typically, though, you have N chips and M tabs and N << M, so a different chip per tab is just impossible.''
* I think you read it a bit too literally. Obviously if you split up tabs to different processors and there are 8 tabs but only 4 processors, then each processor would get approximately 2 tabs. Perhaps the sub-windows or panels can be split, but that's not something the GUI-CLR language has to worry about. The GUI manager will handle that.

* And please don't insult me as a substitute for your lack of will to provide evidence for your "JS needs it" claim. It is not my job to make your case for you. That is an immature tactic (and over-used).
* ''An intelligent person would seek whatever knowledge is necessary to make good decisions. If your apathy was derived of intelligence, you would be able to offer me convincing reasons for why you don't care, which would demonstrate that you understand the reasons the JS guys care but you have a convincing argument either for why they are wrong to care or why their reasons are not germane to your situation. Instead, you prove to be an ignoramus who sits on a throne of ignorance and demands other people convince him to care. How well has shouting at the world from a vacuum of knowledge and power worked for you so far? It IS your job to make your case for you, and you're failing. Miserably.''
* Projection. You are afraid of the real-world, so you insult instead of bring details to the table.
* ''That's rich, coming from the ignorant one. I'm not going to kowtow to your arrogant request that I educate you in the details while you sit at that pathetic table unwilling to look them up yourself. Perhaps if you pay me and acknowledge yourself to be a student... Until then, you '''deserve''' every insult you receive. Apathy due to willful ignorance is NOT a commendable trait in American society.''
* Again, it's not my job to find and present YOUR evidence. That's the way debates are generally done. If you want to change the rules, then you are going against the tide. 
* ''I agree. If I were asking you to present 'evidence' for a claim I made relevant to a point in a debate, I'd be in error. But I made no such claim. None of my arguments hinge upon the point in question - that the client's ability to construct distributed application is hindered is at most an aside, mentioned after you grievously misread something I said as suggesting that GML ''"prevent distributed computation"''. If you mistook it for a critical point, that is your mistake. But it is not NEARLY so grievous a mistake as you arrogantly reveling in your ignorance of your competition. That dooms you to failure more than anything. And your ignorance makes me feel like the only competent party in this debate. It IS your job, in a debate, to be competent. That's the way debates are generally done. If one party is incompetent, the 'debate' devolves into a teacher/student relationship, which for you means a HostileStudent relationship. You don't want that, do you? I certainly don't.''
** You should spend more time and text clarifying what you mentally meant instead of spending time and text telling me how lousy I allegedly am. I find your writing style indirect and difficult. Even your complaints are obtuse.
** ''You should learn to read more carefully so you don't jump to strange conclusions instead of spending time and text telling me how lousy I allegedly am. You clearly jump to illogical conclusions, such as you (through some sort of HandWaving insanity) coming to the conclusion that "designed" means "designed-by-committee", below.''
** You think your words are clear, but they are not. If you had provided a link to a specific document that "does it right", there'd be much less ambiguity in your communication. I've taken courses in effective communication, and you repeatedly violate most of the lessons.
** ''Did I say "designed right"? No, I didn't. Indeed, I specifically used the words "not ''optimally''" to describe the typical status of a design. Perhaps you should take some courses in effective reading, since you repeatedly violate the most basic percept of literacy: read the words that are on the page ''before'' interpreting them. Anyhow, what do your lessons in effective communication teach you about the best way to make a convincing argument for a new idea that has incumbent competition (e.g. GuiMachineLanguage, with HtmlDomJsCss as competition)? Is your usual strategy - demanding the skeptics prove each point while not proving any of your own points - part of those lessons?''
** If the skeptic claims something, then they are obligated to prove that claim. If you claim X has a security hole, then you need to demonstrate that security hole with at least one scenario. You can't just say, "if you were as smart as me, you'd just know where the hole is".
** ''If the skeptic claims something like "I believe/suspect X has a security hole", then you're going to be forced to accept them at their statement. Statements of belief, suspicion, etc. introduce a veeeery tiny burden of proof, since technically it would require only proving that the belief exists, not that the belief is valid. Skeptics are free to have any number of such beliefs. It is YOUR job to alleviate them of these beliefs, if you wish to convince them. Attacking the skeptics, and demanding they prove their beliefs are valid, is not a logical response... and certainly not HowToSellGoldenHammer''''''s.''  

* And, I also believe that you "deserve insults". However, insulting people rarely changes their behavior, often making them dig their heels in instead, so I try to hold back. I only do it as a personal catharsis. Driving home I may yell in the car, "That arrogant lazy types zealot is a son of a bleepity bleep bleep...".
* ''Asking nicely rarely changes people's behavior, too, and it can leave a false impression that they've been doing something right, thus encouraging them to continue their behavior. Let me know when asking nicely gets someone you're frustrated with to change their behavior. Hey! You can start with me.''
* Some would disagree, but how about something in the middle?
* ''In the middle, between insulting and asking nicely... is asking with a veneer of civility above subtle insults. When I next have a question for you, I'll give it a try!''

A new protocol cannot jam every possible wish-list item into it. The wish-list items given attention versus those ignored in the first releases need to be weighed based on need and target audience. Roughly, I see 3 possible divisions:

* E-brochures and hyper-linked documents - Current web standards are satisfactory for this
* Business-oriented forms and apps
* Hardware/speed-centric "browser" for gaming, video, CAD, etc.

It may be good to separate these rather than gum up the works. 

''I don't see three divisions. I see one continuous range of demands to support all of them in a high-performance manner.''

Yes, that's the ideal, but generally humans must partition things to manage the scope and work-load effectively. Otherwise, communism would produce a better overall economy than capitalism.

''And I see superior support for secure mobile code (not merely DomainSpecificLanguage, but a full integration of such a language and a GeneralPurposeProgrammingLanguage) and PublishSubscribeModel as the solution.  Every DomainSpecificLanguage for GUI that ever became successful was eventually been hacked to support plugins and scripts merely to support more generic mobile code, usually at cost to performance and security. Clearly, secure mobile code, something that can be effectively pre-processed by the browser, is the way to go. Support for PublishSubscribeModel optimizes the other half of the problem: refreshing and polling for updates and trying to keep the user up-to-date in something as close to realtime as feasible.''
----
Could somebody explain to me in a few bullet points what this GuiMachineLanguage is for, where would I use it, and why?

''Happily. GuiMachineLanguage:''
* is a pet language mostly for TopMind's MentalMasturbation
** ''Nothing wrong with that. Many are frustrated with web (so-called) standards and want something better. That requires kicking around different alternatives. I'm simply offering a suggestion to explore further. -top''
** I agree. Nothing wrong with MentalMasturbation. Though kicking around alternatives does involve doing a lot of your own legwork, and it is generally considered wise to study known alternatives and the reasoning behind them so one isn't duplicating efforts or working in a vacuum.
** ''Most web standards came about by luck, voting-via-use, marketing, and politics. You assume a logical, well-documented world that generally does not exist. Maybe God forgot to apply your type-checking purity system before he/she/it compiled humans.''
** Most web-standards in use today were designed logically (not ''optimally'', but with full force of engineering reason behind each decision) and documented. ''Which'' designed and documented web-standard succeeded may have been determined by luck, marketing, and politics, but their strongest competition has always been other logically designed and documented standards. 
** ''Most committee-designed-standards tend to get feature-happy to give every party a say. Because they don't have to actually implement it, they are tempted to put every request in to make everybody feel better. Vendors then pick and choose which features to implement because the standard gets too large or unwieldy. This happened with SQL, COBOL, Ada, and HTML, among others. Also, committees tend to only (attempt to) standardize projects that are popular or growing popular already. They rarely start them and succeed.''
** "Designed" does not imply "committee-designed". 
** ''I'm pointing out that most existing standards are not done in the "clean" way you suggest. And if there is a common language that has been done in such a clean way, please link to the documents to serve as an example of the "proper" way.''
** What do you mean by "clean way?" And where did I suggest such a thing? I can point you to a whole repository of documents that are the result of design, including many of our modern web standards: http://www.ietf.org/rfc.html . There's another one at w3c. How about you point out a single modern common web-standard that initially came about by luck and voting.
** ''HTML '''spread''' because people found it useful to them and because somebody made a browser for it. It did not spread because somebody produced a mathematical proof that it was better than the alternatives.''
** HTML was still designed. TimBernersLee initially designed it, and it has further been developed by WorldWideWebConsortium. Are you denying history and saying it was not designed? Are you declaring it "came about by luck" without design or documentation? It certainly seems to me you're arguing something logically inconsistent with a defense of your above words.
** ''I highlighted "spread" for a reason. And Lee rallied against images in browsers according to some accounts. It's a good thing he was overridden. The Marketplace tends to make the decisions that shape our products, not gobs of thinking (for good or bad).''

* you probably don't want to use it
** ''Hopefully it would be replaced by language-specific API's so that one is not dealing at such a low level most of the time. Think of it as CLR for GUI's. (Hmmm, perhaps I should rename the topic.)''
** I should have extended that statement with '... even as a compilation-target for other GUI languages and GUI APIs', because your lack of reasons applies even to those cases.
** ''Because you say so, it must be true.''
** The 'because' was at the start of the next bullet. But, yes, people will believe me because I say so. Bet you wish you could say the same.
** ''Jeez, you are dreaming again. A legend in your own mind.''
** Keep telling yourself that if it comforts you at night. (A more intelligent reply would have been "how many people?")
** ''I have no way to verify your fantasy work world claims, and thus don't give a shit about your imaginary worshipers.''
** I can verify you're an idiot or a liar. That much is clear from you expending the effort to tell me about your apathy. If you really didn't care, you wouldn't have said a thing.
** ''Fuck you, you delusional self-important idiot!''
** Tell me exactly what I said that you can logically verify to be 'delusional', or face up that you're an irrational bastard who lies first to himself then to everyone else.

* because in all said MentalMasturbation thus far, TopMind has been unable to answer 'why'
** ''I addressed that already. If you don't agree with the reasons POLITELY say that and only that instead of snideness.''
** Where did you address it? I haven't seen you provide anything resembling 'reasons' for 'why use GuiMachineLanguage' yet. At best, you've provided BrochureTalk about 'HTTP-friendly GUIs done right' and 'reasons' for exploring the idea of alternatives to HtmlDomJsCss, but that's an entirely separate category of reasons... e.g. it says that there are problems, but offers no 'reason' to believe that your solution is better than the problem. I'll disagree with your reasons AFTER you provide them. 
** (Reaction to 'HTTP-friendly GUI's done right' moved below to (page anchor: done right), as a non-answer to the cry for a proper answer to 'why use GuiMachineLanguage')

Thanks, I suspected as much.  I'll go back to writing code and pay this no further attention.

---------

''RE (Top's own comment): It is a suggested first step in "doing HTTP-friendly GUI's right"'' (page anchor: done right)

''Most will probably project their personal HobbyHorse into "how to do it right", which is pretty much what you did. No use reinventing all those debates again here. Why did Microsoft create a CLR? I believe it was a good idea, but I'm sure many will disagree. Viva La Bicker. -t''

''Do you have real point here by moving this? -t''

Yes. Unless it was a distraction tactic by starting to talk about stuff of no relevance to 'why use GuiMachineLanguage' - such as a mention of Microsoft's CLR or an accusation of HobbyHorse''''''s being involved in other proposed solutions - it had no real point being above. So I moved it. 

* ''CLR does have a similar goal: '''abstract the "engine" and features away from specific syntax''' and linguistic issues. We've discussed this already.''
* Where did I partake in such a discussion with you? I find your assertion ludicrous. CLR has a specific syntax and linguistic issues (bytecode IS a language). CLR is no more 'analogous' to your GuiMachineLanguage than any other GeneralPurposeProgrammingLanguage. Unless you wish to make this a discussion about GeneralPurposeProgrammingLanguage's in general, you were out of line when you brought up CLR.

As far as your accusation that I 'project my personal HobbyHorse into "how to do it right"', as though I were some OO of FP zealot who couldn't think of any other solution, that's simply untrue. I've spent eight years studying what the right ''goals'' for a GUI are as well as how to achieve them. My answer derives of that study. Even my entry into ComputerScience derives of that study. 

* ''You are claiming, not showing. I already know you *think* you are very smart and know everything. You just don't demonstrate it with anything concrete.''
* Proof (that secure mobile code and PublishSubscribeModel are the way to go) is readily available to people who aren't ignorant of existing systems: 
** every GUI language is based on mobile code, and every successful scripted GUI involves secure code (e.g. JavaScript, LUA) that is sufficiently expressive to be a GeneralPurposeProgrammingLanguage. 
*** ''Just because that's the way they've tried doesn't mean that's the way it should be done in the future. If you want to provide evidence that a GUI language *must* be general purpose, please do. -t''
*** You're such a contradictory fellow, TopMind. Asking for a 'demonstration' of a categorical statement is merely asking for evidence - point data - not proof. Asking for 'concrete evidence' means asking for evidence that exists now. What you can observe 'now' is that every attempt to do it '''your''' way - with a limited GUI language and no accompanying expressive general purpose language - was eventually deemed insufficient. The fact that people have failed repeatedly is, in fact, inductive evidence (not '''proof''', but '''concrete''' evidence, just like you asked for) that you also will be forced to support distribution of an expressive general-purpose language. As Shirley Bassey would say, ''"It's all just little bits of history repeating"''. The general purpose language is used to achieve high performance and greater scalability for client-side verification, describing input handlers, decision trees, etc.. Despite the past, though, you still ''might'' escape with a different configuration than has been used in the past... e.g. distributing the 'general purpose' code in a separate layer from the GUI code. That's what I'm betting on in the design I most favor (document model for UI, described and contrasted against application model in DocumentDefinitions).
*** ''I believe that tying it to an application language is a large reason why we don't have a decent open standard yet. People don't want to be forced into a particular language. As described already, the script fans don't like the strong-typed approaches and visa versa. Plus, languages and paradigms go through fads and die faster now. -t''
*** I consider this belief of yours to be naive. GuiMachineLanguage is a language. CLR is a language. Standards are languages. ApiIsLanguage. It's languages all-the-way-down to the ALU. Your goal to communicate without first establishing a particular language is logically, mathematically, and physically impossible. You '''cannot''' have an open standard without a language. A decent open-standard means producing a decent language. But there are intermediate forms where you can use one language to invoke another... that's essentially what plugins and AbstractFactory are all about. That means even more mobile code, though, since using plugins means you need to distribute the plugins, make sure they're portable and browser and language-friendly and secure and what-have-you, etc.
*** ''Yes it is a language, but it is not meant to be used directly by individual GUI designers. It leaves syntax and API's to others so that it doesn't have to start or commit to a paradigm or syntax convention, which otherwise triggers HolyWar''''''s and bickering. This is why MS created CLR.''
*** You clearly don't know much about VirtualMachine''''''s or CLR or why MS created CLR.
*** ''That's not a real response.  Why do you fuck accepted debating rules in the ass so hard? A proper response would be like: "MS did it to be able to render green icons according to this source....". Do you see the difference?''
*** That would be a proper response if I were your teacher, not as a peer involved in a debate. When you start HandWaving speculation on domains in which you are ignorant, I can only suggest you review your facts.
*** ''Projection. Almost nothing you write is specific enough to evaluate. It's all evasive HandWaving. It's as if specific scenarios give you migraines and hemorrhoids (which may be the same thing for you). I think I'm done with this debate. The usual bicker patterns are returning and I have no patience for you anymore. I want a divorce! -t''
*** The usual bicker patterns always follows the same path: TopMind says XYZ that has no basis in anything but his own head - the very definition of HandWaving (e.g. can TopMind point to any source that says 'MS created CLR to avoid HolyWar''''''s and bickering over paradigms?'), TopMind gets upset when he's called on his HandWaving (and calling it is the only proper response to it), TopMind demands ShiftingTheBurdenOfProof (you show me how I'm wrong! or correct me!  - but beware he'll bite your head off for treating him like a student if you actually honor that request), then TopMind blames the other party. Funny how consistent it is. He repeats or at least begins this pattern, oh, just about every time he says something in a debate... probably 15-20 times per page. 
*** ''And you'll question EVERYTHING that way out of habit,''
*** Yes. It's a good thing. I question my own beliefs and designs this way, too. Those that fail to survive didn't deserve to survive.
*** ''gumming up the discussion, NOT because you want to explore an idea.''
*** To the contrary. I consider attacking the fundamental premises for any idea to be a vital part of exploring it. I don't accept ideas on faith. I fully support brainstorming, too. But if your goal was a brainstorming session instead of gathering opinions on your GuiMachineLanguage, then you shouldn't have presented GuiMachineLanguage as something that you've come up with, cut from whole cloth. Start by making a list if many ideas. 
*** ''You don't appear interested in technology, but interested in bashing me somehow. MS's CLR motivation is only a minor part of my argument anyhow. If you disagree with my MS assessment, simply state so OnceAndOnlyOnce and move the hell on. You dwell on such nitty shit. -t''
*** I'm interested in technology. But I can't deal with your irrational defenses. I feel you aren't interested in properly exploring an idea. I feel you are unwilling to rationally accept the possibility that there may be a flaw in your ideas, at least if you aren't the one who discovered it. You resist the burden of demonstrating the worthiness of your ideas to skeptics and devils advocates, and instead demand others prove your ideas to be unworthy. It's perfectly reasonable for skeptics to ask: how is your product better than Foo? A response like "make me care" is like pissing on your potential customers. I suspect you don't put your ideas on WikiWiki because you're interested in 'exploring' them honestly, rigorously. No... my impression is that you're posting your GuiMachineLanguage either because you want praise, or you want help, or both. But to get helpers or praise, I suggest you'll need to start by convincing people that the idea is worthy, that it actually has a ''chance'' of defeating the incumbent, and that effort is better spent on your idea than on competing ones.
*** ''You have not shown any practical and important flaws. You get anally stuck on nitty little crap based on your GoldPlating mental toys.''
*** I still await to hear of any "important advantages" of this GuiMachineLanguage. So far I've heard some bullshit about security, some idealogue MentalMasturbation on 'GUI done right', and some dubious but unjustified assertions that GuiMachineLanguage will be the one to break the long, historical pattern by which external DSL's grow invariably and organically into TuringComplete messes. I'm left with the impression that, even if my other concerns were unfounded and there were no other weaknesses, GuiMachineLanguage would fail to any incumbent under its sheer mediocrity. That said, my other concerns and doubts - expressed in an earlier section - largely remain. 
*** ''Like I already said, I believe a standard that does not look like an application language is more likely to gain acceptance because it's less likely to trigger app language HolyWar''''''s. This is more akin to a "marketing assessment" than a technology assessment.'' 
*** I know you said it. That'd be the 'idealogue MentalMasturbation' I mentioned.
*** ''Further, app-lang-centric GUI kits have '''already been tried''' multiple times, but have failed to catch on. A rational approach is that if you keep doing A and it fails, then try plan B. You want A-prime: a fancier version of an app-lang-turned-GUI. Your approach to EVERYTHING is a GodAppLanguage: one big size fits all. -t''
*** With regards to the app-lang style GUIs, I see HTML 4's DocumentObjectModel as being GUI-turned-app-lang with massive success, I see HTML 5 going further in that direction, I see EnterpriseJavaBeans, I see OpenGl/SDL, and I see you - holding your eyes tightly closed, absolutely ''desparate'' to maintain your unfounded belief that these GUI's aren't successful or haven't invariably and organically evolved into app-langs in the few cases they didn't start atop one already. As to what ''I'' want: you're wrong. I'm against the application model for UI. I'm ''for'' NoApplication. I recognize that mobile code is necessary, but I'd like to keep the mobilized code ''separate'' from the GUI description language - something that won't be accomplished if the application-style support grows into the system organically. I'd like to promote the document model for UI, which can leverage advantages for concurrent sharing, mashups, distribution, scalability, and disruption tolerance.  But I'm realistic enough to recognize that I'd fight an existing market where 'GoodEnough' and 'LazinessImpatienceHubris' each ''strongly'' favor the incumbent, and that I'd need both feature-set and marketing/release strategy to garner even a slim chance of victory. 
*** ''EnterpriseJavaBeans is closely tied with apps built primarily with Java, and thus fails the criteria. Its VB for non-MS shops. I don't see the others making much of a dent so far, except in narrow niches. And I don't think client GUI scalability and mass cross-client sharing is important enough to be the main design focus, as already described. You are getting off-task, '''trying to turn the GUI into an OS'''. HTML-based web-apps have done just fine without crap like disruption-tolerance built into the client.''
*** When you say ''"I don't see"'', are you going to claim and justify that DocumentObjectModel hasn't ''"made a dent dent so far"'', or are you merely claiming sheltered ignorance as to whether such a dent exists? The success of VisualBasic is another example against you and your 'criteria', just like EJB. As far as 'GUI scalability' being unimportant, it's worth noting that almost all successful websites have had to overcome scaling problems, sometimes costing millions of dollars in downtime and lost revenues (as with ebay). You think the efforts to provide end-to-end GUI transactions for purchases and such are merely MentalMasturbation SafetyGoldPlating only ''because you're ignorant'' of how they matter to others. These things don't matter to ''you'', so they don't matter to ''anyone'', right?
*** You say HTML-based web-apps are doing "just fine" without disruption tolerance? Despite the usual use of 'fine' to avoid meaningful conversations about health, my favorite online dictionary tells me that "fine" means "of superior or best quality". "Session expired" is not "of superior or best quality". Hitting the "back" button but not returning to a usable prior state is not "of superior or best quality". Editing a C2 page locally then saving and getting an "offline" message is not "of superior or best quality". The long wait time when firing up a laptop and browser and getting back to the previous activity is not "of superior or best quality". Session management is hacked in nowadays because people want features like disruption tolerance. Usable 'back' buttons for web-apps has been achieved with some complex trickery involving '#' anchors in the URI that are painful to code on a per-web-app basis. Development of "fine" of web-apps could someday be "just fine", but they seem far from "of superior or best quality" today. I'd say it's still struggling to achieve GoodEnough, thus the great many frameworks aimed at making this sort of development easier.
*** ''And despite all those not-quite-God-quality annoyances, it has managed to become the most used GUI system on the entire planet and has about 4 different vendors producing browsers/engines for it. I attribute a good portion of it to KISS and focusing just on key task instead of getting side-tracked. The perfectionist TedNelson's of the world be damned! --top''
*** HTML became successful by growing organically into a GUI-turned-app-language, TopMind, which serves as evidence for my points about both incumbent advantage and the success of app-languages in GUIs. Also, while you could reasonably say that HTML by itself is 'simple', it is the collective not-quite-so-simple mess better described as HtmlDomJsCss + Cookies + U''''''serAgentStrings&AdaptiveJS + AjAx + Browser''''''PluginArchitecture + PHP/Perl/ASP/CGI + Database that has succeeded. Attributing success to KISS strikes me as stupidly naive on your part.  
*** ''HTML-based techniques have expanded beyond original purpose. This exactly is why we need a new standard to give us fuller GUI's. As far as "KISS", I meant as far as the standard, not necessarily the resulting total systems. "Large" standards are more likely to stall.''
*** HTML-based techniques grew into the organic mess of DOM, Scripting, Plugins, AJAX, Cookies, and CGI that exists today because '''HTML was insufficient to meet user requirements without additions and compromises'''. I agree with one thing you said: we do need new standards. But the reason for new standards is to clean up the existing mess, simplify interoperability, and obtain features that have been difficult to achieve with the existing design (including reduced dependency on plugins, video, audio,  greater support for service transactions & partial undo, offline interaction with web apps, better latency for live updates to pages, better support for cross-site operations (including cross-site drag&drop, online file-systems, identity management), high levels of security and privacy for both client and server, etc.). The goal should be to avoid the explicit hackery that happens at every stage in the current cesspool of standards - hacks for browser compatibility, hacks to support back buttons, hacks for offline interaction with Internet applications, hacks for communications contexts, and so on. "Fuller GUI" 'sounds' nice, too, though I have no clue what "fuller" means (some sort of BuzzWord?). GuiMachineLanguage doesn't achieve ''any'' of this - except maybe "fuller" GUIs under a HumptyDumpty definition. GuiMachineLanguage is ''not'' the new standard we need. It seems that, to you, simplicity means ''denial of EssentialComplexity'' rather than ''resolution of AccidentalComplexity''. Until you're talking about cleaning up a real mess rather than sweeping it under a rug, you aren't talking about true simplicity.
*** ''We're taking different approaches. My viewpoint is to create a standard that better fits the task: CrudScreen-friendly. HTML was initially for e-brochures, not CRUD, and this is the main reason for the current mess. Your approach is to build a more complex swiss army knife. While in theory it may make for a nice standard, observing the industry patterns suggests that simpler standards that fit the task well are more likely to be adopted.'' 
*** TopMind, how are you measuring "more likely to get adopted"? If you're saying that "standards adopted are often simple", I'd agree. If you're saying that "percentage-wise, any given simple standard has a better chance of being adopted" then I think you lack necessary statistics to make a judgement. For every simple standard that gets adopted, how many simple standards are rejected? Anyhow, I think that if you observe industry patterns, you'll also learn that people would rather find complex ways to use established standard than switch to an unfamiliar new one. A CrudScreen-friendly GUI standard might be nice, but I see you setting yourself up for doing a '''lot''' of rework to ultimately end up living in the same organic mess we do today. You should measure your standard by how many technical problems it resolves, not by how CRUDdy it tastes.
*** ''I don't see how those are really different.'' 
*** You need a refresher course in statistics. "Percentage wise" - percent of proposed standards that get adopted given they are simple is P(Adopted|Simple), and percent of proposed standards that get adopted given they are not simple is P(Adopted|~Simple). The "standards adopted are often simple" refers to the probability a standard is simple given it is adopted - P(Simple|Adopted). These are very different measurements. Imagine that P(Adopted|Simple)=1/10, and P(Adopted|~Simple) was 2/10, but 10x more simple standards get proposed: then P(Simple|Adopted)=5/6 even though any given complex standard has a higher probability of adoption. Until you grok everything I just said, I suggest you avoid using wors "more likely".
*** ''Since we don't know the complexity rating of the initial pool of candidates, we can only infer based on the results (adaption). Based on this, it's a better bet that acceptance is improved by simplicity than reduced by it. Sure, we don't know for sure, but I am not speaking with the certaintude that you are as if one knows everything. "I suspect a lower rate" is different than "you are wrong and stupid because I know all".  -t''
*** When I speak with certaintude, I'm ''not'' saying "you are wrong and stupid because I know all". I'm saying "you are wrong and stupid because you believe and base decisions on beliefs that I know that you don't know to be true". The above would be an example: your words ''"we can only infer based on the results (adoption), based on this it's a better bet that acceptance is improved by simplicity"''. That's wrong. We '''can't''' infer probability of acceptance based on the set of adopted standards - I even provided you a hard mathematical example proving you can't do so just one paragraph ago. A wise person knows the limits of his knowledge. A wise person either ''accepts'' the limits of his knowledge or takes necessary action to properly expand those limits. A wise person ''does not'' use HandWaving and fallacy in some vain, WishfulThinking attempt to infer beyond the limits of his knowledge. The fact that you attempt to infer what was recently proven you can't infer without more data - is ''not'' wise. 
*** ''You slip into and out of "pure" mode as it suits your argument. Thus, you cherry-pick the setting on the anal-level dial of the argument.''
*** I agree to the former: I use deductive logic where it suits the argument, and inductive logic where it suits the argument. If you were a rational being, you'd do the same. But you are not a rational being, as evidenced by your HandWaving accusations of utter nonsense such as "cherry-pick the setting on the anal-level dial of the argument".
*** ''We can make an educated guess, indirect induction, about the percent of complex submissions and about human nature with regard to what kind of standards they prefer to both create and accept. Thus, we are not 100% in the dark.''
*** Sure, you can make an educated guess, or use abduction, or even use induction. But you do none of those things. You instead try to justify illogical inference. You thumb your nose at education, and you've certainly made no attempt to educate yourself about how many adopted standards qualify for what you'd call 'simple', and you've made an equally unimpressive attempt to gain a sample of submissions.  You made no attempt to factor an 'educated guess' about 'percent of submissions that are complex' into your estimations. Arguing you '''can''' do better than HandWaving in the dark does not mean you '''are''' doing better than HandWaving in the dark.
*** ''I've poked around SourceForge and the like to see what's there. If you have counter experience/observations, then simply present them without some high-and-mighty pseudo-intellectual crap. I'm not "anti-education", rather I'm anti-bullshit-masquerading-as-education. Your criticism is hypocritical double-standard HandWaving, if that fucking word "HandWaving" even has any real meaning. -t''
*** I've poked around SourceForge to see what's there, too, but I have no clue how you imagine to garner knowledge about proposed standards from those observations, much less obtain usable statistics by 'poking around'. Might as well go fishing for the moon. And I '''do not''' need to counter the imaginings you claim to be 'observations' in order to recognize a fallacious argument - you are the one peddling "pseudo-intellectual crap". Sure, I can respect that sometimes you call other people on their bullshit, but that does not excuse your own. It seems you're blinded by your own bullshit, too - your claims about language neutrality and security, for example, have no basis outside your own imagination.
*** ''That kind of thing is where most new open-source "standards" come from. As far as your complaining, it's all projection. You are a two-faced hypocrit when it comes to evidence.''
*** Oh? Name three 'open-source standards' that came from SourceForge. And I do provide evidence for my claims; are you incapable of distinguishing a claim of fallacious argument from a claim of incorrect conclusion?
*** ''I didn't claim that most actual standards come from it, only that it's a rough approximate representation meaning that we do know something about the standards candidates before they "make it big-time", which contradicts your little formula line of reasoning. -t''
*** Your words were "where most new open-source 'standards' come from". If you weren't talking about SourceForge in particular, what were you talking about? Are you again claiming that, on the basis that you '''can, theoretically''' gather knowledge from SourceForge that you have actually done so and factored this knowledge into your estimations? If so, what were your estimates for percentage of standards that are complex vs. simple, and how did you gather these estimates by merely 'poking around SourceForge'? You say there is a contradiction with my line of reasoning, but it remains unclear what this contradiction is; I ask that you clarify it. (Notice that I didn't use the word HandWaving this whole paragraph... oops. Well, I'm trying.)
*** ''I said "that kind of thing", and thus did not single out SF. And my survey and analysis was informal, not a double-blind published peer-reviewed certified stamped, fingerprinted, and x-rayed study. Anyhow, let's drop this issue, I don't find it worth the bicker-text. I thus formally withdraw my "simple standards are more likely to be adopted" claim, without comment. -t''

*** ''If a new standard directly supports desktop-GUI/CRUD idioms, that alone is "resolving technical problems". There is a big need for such standards in the business world, and I'm betting that when people see something like it in action, they'll be happy to abandon the HTML++ stack. Web-based business companies would love something like that. Their current options are problematic in different ways.''
*** Gamble away. But I don't see people changing everything from browsers to servers to cache and filter support for a ''dubious'' additional benefit to CRUD, especially in the absence of other benefits. Incumbent advantage is not trivial: you're going to need to show how GuiMachineLanguage figuratively blows HtmlDomJsCss away for CRUD if you're going to win by virtue of that alone. I do not believe you can do so. 

*** ''Remember, the people who end up making decisions about *using* standard may not think like you. Further, Those who abuse HtmlDomJsCss would probably abuse your contraption also.  Languages can't spank.''
*** Sure, that's okay. Those who are pushing HTML++ to its technical limits today should get a nice reset so they have entirely new limits to push. Once we know the new limits, the problems being encountered at those limits, we can upgrade again. That's called '''progress'''. 
*** ''Many developers abuse existing standards out of stupidy, job-security, and ranking aesthetics over function (sometimes from outside pressure). No language can change this. If you remove beauty from it, then they'll use a different standard that does offer flowers and rainbows, even if it crashes and has worm-holes. (Flash gaining over Java applets is perhaps an example of this.) You are focusing too much on technology and ignore how humans relate to technology. In a Soviet Software Shop perhaps they can be "straitened out" under a good manager and a whip. But that's not what we have. If you offer a standard with too many attempt-to-spank mechanisms, it will be ignored. -t''
*** I am '''not''' ignoring how humans relate to technology. Humans follow a PathOfLeastResistance, principles such as LazinessImpatienceHubris, favor ExploratoryProgramming, that some are 'lone wolves' and others are social animals. However, I have no reason to suspect, nor any solid theory predicting, that says these things are ''hurt'' by new end-to-end standards. To the contrary, the limited evidence and testimonials I possess suggests the exact opposite. As far as "attempt-to-spank mechanisms", I disfavor BondageAndDiscipline and really have no idea what you're imagining.
*** As far as your comments about ''me'' '''trying to turn the GUI into an OS''' - that ain't true at all. The various forms of GUI - browsers, shells, etc. - have had the full range of OperatingSystem features ''years'' before I ever said my piece.  

** for PublishSubscribeModel, you can observe that dataflow in order to achieve low-latency updates is common in graphics programming languages (ICE, Shake, Houdini, Cineon, Khoros and Nuke for example, Maya under the hood, Max as of version 5). PublishSubscribeModel is simply a supporting feature for high-performance dataflow from arbitrary systems.  
** Applications are fundamentally driven by events and dataflow... e.g. progress bars, user events, etc. The primary mechanism for hooking applications together under-the-hood is signals and slots - events and callbacks - which is ultimately just a less general form of PublishSubscribeModel. 
** ''Perhaps, and perhaps PublishSubscribeModel can be used under the hood to implement the GUI engine and GUI-CLR interpreter.''

* That aside, you have also failed to demonstrate anything concrete, and yet you've made claims about the various 'security' benefits of your GuiMachineLanguage. Your hypocrisy is noted.
** ''Ask something specific. Propose a scenario that you think would "break" security, and I'll describe some approaches.''
** You've made security claims. Not shown them. Blah, blah, blah, hypocrisy, blah, blah, blah, You just don't demonstrate it with anything concrete. I'll ask a specific question: exactly which attack does your 'security' advantage of being 'not TuringComplete' actually prevent? And how do you demonstrate this? 

You, on the other hand, don't even know what your goals are. How can you do a 'GUI right' of any sort if you don't know how to define 'right'?

''How about we put such in another topic: GuiEngineGoals. However, I suspect we'll end up weighing those different. For example, the strong-typing affectionados will rank strong typing and type checking as "very important" to prevent kittens from getting cancer and all kinds of other calamities like they always do. It will be the same kinds of arguments all over again.''

[You'd do well to avoid embedded insult, as it does nothing to serve your cause or your reputation.  Couldn't you have written, "for example, the strong-typing affectionados will rank strong [static?] typing and type checking as "very important" but the dynamic-typing fans will rank it lower"?  A more insightful pre-recognition of the variance in priorities between you and your opponents might turn some of these more-heat-than-light debates into fruitful discussions.  Maybe. DeleteWhenCooked]

I wouldn't even consider 'strong typing' a 'goal', TopMind. While I am an afficionado of strong static duck typing, I consider it a means to an end, a strategy by which a goal - a certain form of robustness - may in large part be achieved.

------------------

Since the page has devolved into bickering, I'll leave this page and my final thoughts. TopMind proposes what he believes to be a new idea - a common GUI language based on procedural statements, reminiscent of DisplayPostscript and XwindowProtocol. He shows a remarkable lack of awareness about similar solutions that come before, and even less awareness of competing products already in development.

*''Apparently you do also, otherwise you'd borrow from their grandness to show EXPLICIT scenarios that bust my proposal. SHOW that I am stupid 100 times instead of claim I am stupid 100 times. It's not my job to go hunt for YOUR evidence. That's the way debates have always been. If you don't like that norm, tuff cookies.''
* TopMind, here, proves he believes in ShiftingTheBurdenOfProof to the skeptics, and attacking them, rather than showing EXPLICIT scenarios where his product is allegedly competitive. TopMind seems to be under the impression that it is the job of the skeptics to convince ''him'', rather than his job to convince ''them''. TopMind has double-standards in 'debate': when he is skeptical, it's the other guy's job to provide evidence that they're smart. When other guys are skeptical, it's the other guy's job to provide evidence that TopMind is stupid. TopMind should probably accept reality: skeptics have no reason to convince him of anything. Skeptics are free to go on using HtmlDomJsCss and ignoring TopMind until TopMind gives ''them'' a reason to not be skeptical.
* ''If you claim it has "bad security", then simply create a scenario that shows it crashing and burning. "If the user presses the green button on form-A while holding the Shift key, then form-B dumps the contents of the server's hardrive. Here's the code...." '''What's so bleeping hard about that?''' Instead you just imply "trust me, I know top's contraption is dumb because I read a lot of stuff.". That's how it comes across. -t''
* You think crashing when pressing buttons is a ''security'' issue... that's ''ignorant''. You aren't willing to educate yourself in computer security before proposing solutions... that's ''dumb''. Anyhow, your approach is no more insecure than HTML; I never said it has 'bad' security relative to the other mostly-insecure solutions. You are the person who suggested that being 'not TuringComplete' was somehow a security solution, then failed to demonstrate even one vulnerability it nullifies or one threat it eliminates. How about you provide your hypothetical scenario, with all the proper details (actors, messages, threat, vulnerability, etc.), with the vulnerability existing before and solved after making the language 'not TuringComplete', then I show why it fails?
* ''You were being too literal. But, I changed the scenario anyhow. What do you mean by "existing before"?''
* By "existing before" I mean you need to show that there is a problem that exists '''before''' the solution, and that no longer exists '''after''' the solution. That is what it means to "solve a problem".
* ''RE: Too literal:'' "The sky is green." "No, it's blue." "You're being too literal!" - Is there some definition of correct that doesn't also require literal correctness?
* ''I didn't claim that a competitor had a security problem.''
* Neither did I. It seems unfortunate that your literacy is such that you believe I have. You are not ''nearly'' literal enough.

TopMind attempts to liken his solution to Microsoft's CommonLanguageRuntime despite its inability to carry general-purpose code or abstract subroutines. 

*''You have not shown that subroutines are necessary. I'll happily add them if you show a realistic need. Adding them is relatively easy. It would make more sense to complain about things that cannot easily be fixed by adding features down the road.''
* And until you add them, you should probably resist analogy to CommonLanguageRuntime.
* ''It is not meant to compete with CLR, and thus doesn't need the same features. There's a difference between being an analogy and being a competitor.''

He makes claims about 'security' with his normal amount of HandWaving. TopMind further proves that he has little interest in the feature requirements of people who write applications, repeatedly insists they should convince him why he should care. Due to his lack of concerns for the feature demands among others for real applications, TopMind seems to be aiming GuiMachineLanguage at a niche market. If he could explain reasons to believe in some real advantages over HtmlDomJsCss in even just this this niche market, he might be on to something, but his best efforts so far seem to consist of repeatedly mentioning 'combo boxes' as though they alone should be sufficient reason to switch from an established and well documented language that many people know, learn a new language, and write browsers to support this new language. 

* ''That is blatantly false. I've referenced WebBrowserMissingWidgetWorkArounds above, and it has about a dozen items.''
* You honestly believe even a dozen items is sufficient reason to switch from an established and well-documented language that many people know, learn a new language, and write browsers to support this new language? Please explain why people should do all that? Why not just add missing widgets to HTML 6.0 and continue using HtmlDomJsCss? Tell me: how long would it take for GuiMachineLanguage to become popular? How many revisions of HTML and advances to JavaScript libraries and DOM will likely come out during that time?
* ''See: discussion in HtmlDomJsCss''

It is terribly unconvincing. Despite all the discussion so far, the skeptic is left with '''no''' reason to believe that GuiMachineLanguage won't simply turn into another HtmlDomJsCss with a bunch of hacked-on client-side scripting and plugins, nor left with reason to believe GuiMachineLanguage is better for applications. The reason: TopMind spends all his time attacking the skeptics and bad-mouthing HtmlDomJsCss rather than defending or promoting GuiMachineLanguage. He'll probably spend time picking this skeptic's opinion to little pieces just so it can't be read all in one place ['''Edit: He has now done so'''], and still fail to defend even one point on GuiMachineLanguage ['''Still true.''']

The idea is simply ~20 years too late to gain traction, at least without a couple significant advantages in a niche (performance, ''real'' security, disruption tolerance and recovery, more eye-candy, better animations and transitions, better 'liveness' properties, accessibility to blind and deaf, better support for automatic transition to tiny touch-screen mobile-phones, etc.). We desire something better than HtmlDomJsCss, but there is no reason (unless you want to take TopMind's word for it) to believe GuiMachineLanguage offers an advantage in any of these.

A style similar to TopMind's 'GuiMachineLanguage' is commonly emulated simply by creating a body-script in HTML (sequence of JavaScript commands executed in body or i-frame). The basics behind it is the same: each command manipulates the DOM just a bit. This approach even has significant advantages over GuiMachineLanguage in that one can abstract update commands from the server with client-side procedures, thus saving on bandwidth, and can pre-process some inputs from the user, thus saving even more bandwidth and making the program more disruption-tolerant. Perhaps TopMind should try to understand why that style of WebApplication composition isn't more popular - considering not just the client-side, but also the server side processing needed to make it as interactive like applications are expected to be. 

-- BlackHat

''The main motivation beyond a lower-level GUI language is simple: don't hard-wire the GUI engine to a particular high-level language so that it can be adapted to many different languages without triggering LanguagePissingMatch''''''es.''

TopMind says this, but fails to demonstrate how a "lower-level GUI language" is not still "a particular high-level language", fails to demonstrate how it avoids "triggering LanguagePissingMatch''''''s", and how it is somehow "more adaptable" than other GUI languages. Without these arguments, provided with good reasons, most would consider TopMind's statement about this motivation to be HandWaving. BlackHat certainly does. -- BlackHat

''BlackHat just likes to be a monkey-wrench for the sake of being a monkey-wrench.''
* Indeed. BlackHat loves being the one to crush dreams with monkey-wrenches, saws, sand in the radiator, etc. But he thinks it's a practical exercise: if GuiMachineLanguage can't survive the same abuse as its competition, BlackHat is happy to kill it. 

''DOM was originally made for e-brochures, not desktop-like GUI's, and so far the retrofitting and shoehorning is not going very smooth. There are too many features it lacks (WebBrowserMissingWidgetWorkArounds) and Microsoft will not likely add them because doing so would make it easier to cut into their Windows near-monopoly.  Thus, the logical thing to do is to create a "GUI browser" (or browser plug-in) that better mirrors desktop GUI idioms and use an underlying language that does not have to be TuringComplete and does not heavily favor any given app language style or paradigm (scripting, compiled, OOP, FP, etc.) -t''

Perhaps TopMind can explain how that is a "logical thing"? In particular, how is "use an underlying language that does not have to be TuringComplete and does not heavily favor any given app language style or paradigm" ''logically implied''? This skeptic is curious, and skeptical. -- BlackHat

''Let me put it this way for now. I will assume the reader agrees that app-language neutrality is a worthy goal and that HtmlDomJsCss isn't likely to cut it. If you don't agree with these premises, then you are free to ignore this page (and take them up in another topic, such as HtmlDomJsCss, if you wish to debate them).''

TopMind says this, but fails to demonstrate how his approach actually achieves 'app-language neutrality', nor does he define it well enough to make an objective judgement of 'app-language neutrality' such that readers can make a reasonable judgement about whether it is a worthy goal. TopMind's premises are questionable, and his assumption that GuiMachineLanguage achieves his premises (and that HtmlDomJsCss does not) is indefensible. If TopMind doesn't like this skepticism, perhaps he should take his ideas to his blog so that he doesn't need to hear naysayers. He is free to leave WikiWiki.

''App-neutrality is achieved because it's not an app language.'' 

So any 'not an app language' is app-neutral? What's an app language? Isn't GuiMachineLanguage specifically for applications?

* Being "for" applications is not the same as being an application language, anymore than CLR is by itself an "application language".

''As far as existing standards, again, see HtmlDomJsCss for discussions about that. I don't mind naysayers, it is repetitiously insultive naysayers who don't follow proper debate conventions that are the problem.''

I don't mind dreamers and self-promoters. The problem is the self-promoters who somehow believe that ShiftingTheBurdenOfProof to the skeptics is proper convention for promoting their dreams and winning followers. BlackHat is happy to throw monkey wrenches at those fools and the donkey they road in on. BlackHat feels no need to prove to fool that donkey is not a high horse. 

''Well, I disagree with your assessment of where the burden lies. If you have clear algorithm of ground rules, let's see it. Otherwise, curb your repetitive, text-wasting, Aspergers-style rudeness.''

I'll make you a deal: curb your sophistry and fallacy, and I'll curb my rudeness. People only need to prove what they mean to claim, and only if they consider it relevant to the debate. They are otherwise free to dismiss it as irrelevant to their argument (in which case the proper procedure, if you wish to pursue it, is to table the 'aside' for another debate), and free to recant and adjust their words to better clarify their meaning.

''Sorry, but I am not doing anything wrong. Beat me up with truth and facts, not insults. Amateurs use insults; gifted debaters let truth and facts ALONE serve as any "punishment" and don't need to resort to insults. I've seen others do it well and it's wonder to watch in action.''

Debaters are judged by an independent third party. You may think you are doing nothing wrong. I do not agree. You may believe you're the sort of rational person who processes facts and truth. It seems to me you are immune to facts and truths that point out what you're doing wrong. I suspect you are incapable, or at least not in the habit, of examining your own behavior from an outsider's perspective. I would suggest you ask yourself: would you trust ''anyone'' who said "I am not doing anything wrong"? Surely, if anyone else said that, they'd be delusional. Now apply that opinion to yourself.

''Let me be more specific. My objective error count to your insult count ratio has been very small so far.'' 

So you believe. I try to limit my insults to when you use sophistry, fallacy, or state facts that you cannot defend. Perhaps you simply don't count those as errors unless someone can convince ''you'' they are errors? But you're not an independent party, are you?

''And you can disagree without being rude.'' 

Indeed. I commonly offer that courtesy to people who don't use sophistry or HandWaving in their arguments. 

* ''YOU are the hand-waver. You imply that my stuff is bad, but almost never show a clear scenario of it being bad. You are the problem. Either that, you have a twisted sense of morals that deviates so far from the norm that people cannot figure you out, kind of like your writing style. And you shift back and forth between anal formality and loosey-goosey in your style and accusations to game the debate your way. You tighten the knob when you feel like it, but then loosen it back up when you are getting caught in a corner. And you scatter the same complaints all over. When losing a debate in one spot, you change the subject back to another subject that you feel you've done better in. This totally confounds coherency. There are just so many rotten things about your style and "logic", and you are blind to it all. You deserve to be punished, but name-calling doesn't work. I wish I had an effective and legal method to punish you, but right now I don't. ''{'''Somehow, I'm just not feeling the love here.'''}'' I hope Karma gives you fat lip because you are such an ahole.'' {'''Oop, there it is.'''}
* ''RE: "You imply that my stuff is bad"'' - I'm a much more literal person than you. When you're inferring what I'm implying, it may help you to keep that in mind. I've said your stuff will ''fail''. That's different from calling or implying it "bad" or "broken". It only means there is no 'success' in the future of your GuiMachineLanguage. Indeed, if all else was equal, or even if your stuff was just ''slightly'' better than the incumbent, then inertia and WorseIsBetter will beat the crap out of your incremental improvements. As is, though, I remain skeptical that your stuff is even ''slightly'' better than the incumbent. When asked for reasons to believe GuiMachineLanguage is such a solution, you have respond by attacking HtmlDomJsCss (as though doing so gives reason to believe GuiMachineLanguage will do better) or by making dubious claims about the 'security' features of GuiMachineLanguage (for which you have demonstrated neither the threat nor the vulnerability nor the fix). One good point you had was WebBrowserMissingWidgetWorkArounds, but when pursued on that point (why not add it to the incumbent, HTML?) you responded by making HandWaving attacks on Microsoft (cf. HtmlDomJsCss) and implying that they couldn't be added to HTML or wouldn't naturally fit (as though saying so offers ''any'' reason to believe it would be more natural to include the gamut of missing widgets and HTML widgets in GuiMachineLanguage). You believe things wrong with my "logic". And perhaps I've made a few errors, but I doubt you've found them. The logic you are using to judge mine seems the wildly incoherent one.
* ''You said all that already. I see no reason to repeat it. If you disagree, just say something like, "I don't think your evidence is strong enough so far" instead of "you are a stupid hand-waver!".''
* I don't think most of what you've presented reasonably qualifies as evidence.
* ''I know you don't. But I disagree. A lot of it is political and behavioral analysis and assessment (consumer patterns) such that ANY analysis is going to involve judgment calls. This wiki allows people to express opinions and is not meant to ONLY permit million-dollar studies. Any evidence that is not a million dollar study will be called HandWaving by you almost as certain as the sun sets. If you feel that I deserve to be called names because I don't present million-dollar studies, well, shoot away. But, it just makes you look like an ass and gums up the discussion with repetitive bickering. '''Disagree and move on!''' Don't spend 3 pages on how stupid I alleged am or keep bringing up the same complaints in multiple different spots. Criticize smartly and concisely.''
* Let me ask a question: do '''you''', with all your "political and behavioral analysis" and opinions-as-substitutes-for-evidence and alleged 'security features/settings', believe your GuiMachineLanguage has a real chance? i.e. against HtmlDomJsCss and QwertySyndrome? If not, I ''politely'' suggest you develop something you can justify with stronger evidence.
* ''Part of this topic is a hypothetical question: how would you do GUI engines if starting from scratch? Asking such questions sometimes helps people to design better even with different or established tools. It's almost like learning Lisp or ProLog: you likely won't use them in practice, but they give you viewpoints you may not have had otherwise. It's optional MentalMasturbation that may or may not make one think. Ignore it if you wish. Maybe some bored geek snowed-in will produce a new GUI browser that catches on.''
* That's fair, I suppose, but I'll suggest that - if you really want an exploration of ideas - the opening should have be more about eliciting contributions than about describing TopMind's contribution. You might even be able to get someone like me (who habitually wears a BlackHat) to don the GreenHat or YellowHat for a while.
* ''I find it better to communicate when comparing something somewhat concrete, like a specific language. Without that, the "result" is merely a re-packaged version of each person's HobbyHorse.  -t''
* Ah. And to achieve this, you simply packaged your own HobbyHorse and called it 'GuiMachineLanguage'. And you did not ask anywhere near the opening: "how would you do GUI languages if starting from scratch?" How has that worked for you so far?
* ''It was already tried in other topics. I decided to put forth something more specific here instead of just bicker over general philosophy.''

''Aside from fitting the embarassing aspberger stereotype, it wastes time and text. Disagree politely and move on.''

Is Asperger's embarrassing to those that have it? Who is embarrassed by it? You?

''If you don't mind the stereotype of a rude, nasally, pedantic know-it-all; then keep doing what you are doing.''

I don't mind at all. I'd reply: "if you don't mind the stereotype of a hypocritical, HandWaving crank, then keep doing what you are doing", but it is clear from your behavior here and at comp.object that you don't mind either. We're going to be at each other's throats for a few more years, at least. Happy fun times, yes?

''Hmmm. Which comp.object ahole are you?''

None of them; I only lurk that forum. But I can readily identify which comp.object ahole you are.

-----
I'm not clear where this GuiMachineLanguage is intended to exist.  Will it be implemented in a browser plugin similar to Flash and MicrosoftSilverlight?  Or will GuiMachineLanguage be compiled (somewhere) to HtmlDomJsCss?  Or something else?

''Top has said that it might be implemented in a plug-in, but that wouldn't be his first choice.  I suspect he wants a dedicated browser that just runs his stuff.''

[Java may be the best way to quickly build a "GUI Browser", for reasons described in BuildJavaGuiBrowser.] -top

Hasn't that already been done in GoogleWebKit?

[Java is the primary language a front-end developer would use for GWK, not GuiMachineLanguage or XML]

Java could be the "GUIMachineLanguage".  You could compile from your own language <x> to Java, take advantage of Java's relatively high-level constructs, and let GoogleWebKit handle the heavy client-side lifting.  Wouldn't this be preferable to compiling from language <x> to GuiMachineLanguage and having to implement the GuiMachineLanguage VirtualMachine from scratch?

''Many don't want to work with native Java as the primary GUI design language. And, this goes against the goals of app-language neutrality and making the most common idioms & actions declarative in nature.''

That's why I wrote that you could compile from your own language <x> to Java.  From the language <x> point of view, whether the object code is Java or your GuiMachineLanguage hardly matters -- the developer won't see it.  Since it seems that the GoogleWebKit has already done the hard work for you, and effectively achieves all the apparent goals for GuiMachineLanguage, it makes sense to use it.  I will.

''Then it's a desktop app, not a web-based app.''

{Please explain. Are you claiming GoogleWebKit (which compiles Java to HtmlDomJsCss) makes a desktop app, not a WebApplication?}

Indeed, please explain.  The development chain is language <x> compiler --> Java --> GoogleWebKit --> JavaScript.  What makes that a desktop app?
-------
'''On-display Events''' (continued)

''There seems to be multiple complaints against "on-display" events. Could you please provide a few common scenarios that illustrate why they are allegedly bad? Thanks.''

I'll create OnDisplayEventsConsideredHarmful to explain in detail, along with describing alternatives that provide the same features without creating challenges. In the meantime, perhaps you can provide a few common scenarios that illustrate why they are allegedly useful, that you believe couldn't easily be done with something much weaker. I'll use them to illustrate the alternatives.

''Scenario 1: when a form/window/panel opens, say via a menu option or "see reference list" button, you want to update a list it contains with the latest info from the server. Thus, it sends a notification to the server upon opening, and the server responds by sending (populating) a new list.''

That one's too easy. Either move the update event into the same menu option that opens the page, or provide a declarative data dependency (e.g. data as a function of a side-effect-free query) such that the browser can decide between pulling the 'latest info' from the cache vs. going all the way to the server vs. subscribing to keep the view continuously up-to-date. (But I appreciate the scenario. Need harder ones. Keep them coming.)

''Suppose that reference screen is called from several places and they all want to refresh it upon open. [...] Factoring would dictate that an "on open" event do the retrieve/refresh instead of '''duplicating''' the call for every "show screen" button or menu. I suppose repeating the refresh call is not a show-stopper, but first I'd like to see the down-sides of on-display events before sacrificing the better factoring.''

Factoring dictates no such thing: another perfectly reasonable factoring is to write a "show_screen_and_update()" function, then call that from several places. Did you not consider this possibility?

''How non-OOP of you :-) Constructors are evil? Anyhow, I've still yet to see a good reason to toss on-display events. Almost every GUI tool-kit has some form of them, so people are used to them and will want a good reason to stop using them.''

I've yet to see a good reason to ''include'' on-display events. The default should be to toss them, lest you introduce LanguageIdiomClutter. You're free to play DevilsAdvocate on this issue, though. I do it often enough just to stymie you. 

And constructors are totally evil (see NewConsideredHarmful). I'm an OO guru; that means I'm an expert, not that I like it. You've got to know OO pretty damn well to really know the problems and limitations. You also need to know it in many languages, so you can distinguish language issues from those inherent to the design. (Same is true for any paradigm, I suspect. I imagine that much paradigm zealotry comes from those least experienced. The rest comes from people like you, who knows the value of a paradigm and sad to see it trampled beneath the feet of the ignorant. Unfortunately, you don't know the other paradigms well enough to make a proper argument about their limits.)

* Response moved to ConstructorsAreEvil.

I favor OO only in some very heavily modified forms, such as ActorsModel with TransparentDistribution (like ErlangLanguage and EeLanguage), SendReceiveReplyEventually, a good language for configuration of object graphs such as DataflowProgramming (though a good DependencyInjection framework will do), ... and I wouldn't mind TransactionalActorModel.

-------

''In fact, suppose it's not populated until it's opened to avoid querying the values until it's actually needed. [snipped from above]''

There are many ways to do that without putting the logic for doing so into an 'on-display' event associated with the screen. Trivially, 'show_screen' could be synchronous, then one shows a screen then queries. Less trivially, one could use asynchronous callbacks or continuations: 'show_screen(screenID,callback)'. But this is a reasonably complicated one (thanks!). I'll be sure to detail this one in the other page.
-------
''Does this proposal overlap with HTML5 ?''

No.

[This dubious proposal strikes me as being completely invalidated by HTML5, and by the frameworks that will inevitably spring up to support it.  In light of that, this page serves so little purpose and is so much heat rather than light, that I suggest it be deleted.]

HTML5 doesn't much overlap TopMind's proposed GuiMachineLanguage. Indeed, for the most part HTML5 goes the opposite direction. (I consider this a GoodThing, because TopMind's proposed GuiMachineLanguage ''sucks at '''everything''' (including CrudScreen''''''s)'' IMO). I'm looking forward to HtmlFive. I'm sniping GuiMachineLanguage as though TopMind's mouth is a clay-pigeon shooting machine... it's fun! join in. 

(Discussion suggesting that supporters of ExBase are not competent enough to design a GuiMachineLanguage has been moved to ExBaseRant.)

-------

''I invite you to produce realistic scenarios that demonstrate suckage (outside of your GUI-as-OS pie-in-sky scenarios.) I believe we just have different features that we want to optimize for and that I value relatively simple protocols more than you. Also, MS will not likely allow decent GUI standards to proliferate via it's browser because it would eat into its desktop monopoly, making any advantage of HTML5 as moot as XUL. HTML5 is also too open-ended in its widget descriptions. -t''

GUI-as-OS is hardly "pie-in-sky", TopMind, despite your head-in-sand attempts to hide your eyes and pretend otherwise. Any GUI will have all significant elements of an OS: device input, device output, communications between elements, communications context management, scheduling, priority, scaling and performance concerns, persistence, distribution, security, and composition. HTML grew out of control because by itself it was insufficient to handle these concerns. Even GuiMachineLanguage has all these elements - it just sucks at them. If GuiMachineLanguage wasn't destined to die an anonymous death at the hands of worldwide apathy, it would also grow out of control.

You ''claim'' to value 'simple protocols', but that's a lie. You '''ignore''' the impact that end-point languages have on protocol. You even admitted that much. Your [TopMind's] words were: ''"As far as "KISS", I meant as far as the standard, not necessarily the resulting total systems."'' Stop lying to yourself. Stop lying to your audience. Stop ''pretending'' to care about protocol while your behavior and statements prove the opposite.

Anyhow, I invite you to demonstrate how your GuiMachineLanguage is better at CrudScreen''''''s without using HandWaving claims about the market for 'programming language neutrality' or your utter bullshit about 'security'. HtmlDomJsCss has its flaws, I agree, but your finger-pointing at those flaws isn't fooling anyone other than you. Demonstrate how GuiMachineLanguage is better.

* ''Because things like tabs, MDI windows, menus, tool-bars, nav-bars, editable grid widgets, combo boxes, input format templates, etc. are already built in as root idioms instead of creating 50,000k LOC emulators in JavaScript that have to be downloaded each time and crashes when the next browser version is released and differ for each browser despite thousands of "IF(version=x)" lines running with clunky CSS that causes weird overlapping and scrolling problems. -t''
* I have no guarantees that GuiMachineLanguage won't vary or have quirks among its own display clients. You're also not promising me any performance advantages or stability advantages with GuiMachineLanguage and across language and client versions. Besides, loading ~50kLOC JavaScript per page (which I believe to be highly pessimistic) still amounts to less code (and likely less total processing) than is needed to load a typical large JPEG, even ignoring caching. And why would I want to use GuiMachineLanguage to interact with these built-ins? How is the server advantaged by GuiMachineLanguage? Sure, DocumentObjectModel has its flaws, but why is GuiMachineLanguage 'better'? I remain unimpressed.
* ''JavaScript was never meant to be a systems programming language (base tool builder), and the DocumentObjectModel is inconsistent between vendors, awkward, and buggy.'' 
* Are you claiming those are disadvantages relative to GuiMachineLanguage? I know about the flaws of HtmlDomJsCss. Pointing out those flaws '''does not''' convince me GuiMachineLanguage will be any better.
* ''Further, Microsoft will find a way via IE to sabotage anything that overly resembles a desktop.''
* Oooh! HandWaving prophecy straight from Top's mind! I do not believe you. The widget sets named in HtmlDomJsCss work well in IE. But, even if I did believe you, I'd ''still'' not see this as a relative strength of GuiMachineLanguage. If Microsoft attempts a sabotage, I'd tell my clients to use FireFox or another client. Compare this to GuiMachineLanguage, where I'd need to tell them to use some specific client to start.
* ''HtmlDomJsCss widgets are usually awkward, clunky, and browser-version-specific. There's no open-source decent ones. One might as well go with Flash-based GUI's if you go the commercial route because Adobe is more likely to stay around than some fly-by-nite mom-and-pop widget maker in Taiwan.'' 
* GuiMachineLanguage also looks pretty awkward, specific to a browser client that doesn't even exist yet, and seems to be missing a decent open-source implementation. In that sense, it certainly is in a worse position than the HTML widgets you rail against by every metric you just provided. Besides, even for the widget-sets you pay for, you often get the source-code along with the limited distribution license; that gives a lot of flexibility in the event of a fly-by-night.
** ''The more complex widgets require like 5k-20k lines-of-code that micromanage individual pixels and coordinates. That's rather time-consuming nitty-gritty debugging on behavior that may not even exist in the next version of a browser that should be devoted to app development instead. This is not 1985 anymore.''
** That's 5k-20k of JavaScript compared to how much in the browser? As to your comment that "this is not 1985 anymore", I suggest you should take that to heart with regards to creating a new GUI language. This is not 1985 anymore. Your GuiMachineLanguage can't survive if it ignores networking, sharing, cross-site operations, and similar issues.
** ''I don't know why you keep talking about those. Only you seem to care. Most just want an HTTP-friendly app-lang-neutral desktop-like ("rich") GUI. Gold-plate it at 2.0. -t''
** I don't know why you keep saying 'app-lang-neutral'. Only you seem to care. Those of us who would actually need to "compile" a display into GuiMachineLanguage would be just as happy to use what you vaguely call 'app-lang' as a target compilation language, so long as it is portable, distributable, high-performance, etc. Anyhow, we also want desktop-like features, such as Drag & Drop. And we want to have multiple 'applications' on our desktop, and the ability to drag and drop between applications. We want rich interaction. We '''want''' gold-plate levels of "rich" as opposed to your ''crud''dy clay pottery.
** ''So if you are a Python shop you are going to use Java as your GUI engine? This is rather uncommon, and probably awkward, and site-specific. If you can roll a general-purpose Java-based interface kit for other languages, be my guest to present it. As far as drag-and-drop, where did GML forbid it?''
** GML doesn't 'forbid' cross-app drag and drop. It simply ignores and provides no support for that sort of feature, which will then require much scripting and hackery and third-party systems to achieve. There is a truly massive gap between 'supports' and 'doesn't forbid' and I believe that asking "Where did GML forbid X?" is a misleading and dishonest defense on your part. Where does HtmlDomJsCss 'forbid' editable grids and MDI? (Oh wait! It doesn't! Then why are you complaining?) GML lacks the architecture to support cross-app drag+drop of anything but raw text or images, and even then supporting text and images would require some explicit features be added to GML (e.g. some sort of 'on_dragdrop' event like you recently added above). 
** If I was a Python shop I'd not be a human and I'd have no volition of my own. But assuming I was a Python fan, and wanted to write my code in Python, then I'd also write a neat conversion utility (sometimes called a 'compiler') that will convert my Python labors into something usable on the client. But, before writing a neat conversion utility, I'd look at the mind-bogglingly vast repository of Python utilities to see if someone else already did it. And if I looked, I'd find neat tools like Pyjamas (http://wiki.python.org/moin/Pyjamas) and Skulpt (http://www.skulpt.org/) that convert or support Python for HtmlDomJsCss. I could also use Jython to produce Java bytecode from a Python program. Other alternatives: embed a Python interpreter via plugin, or write one up in the target language. For more information: http://wiki.python.org/moin/WebBrowserProgramming
** ''I meant mostly server-centric app code, not creating a client. But still that's a lot of Python-specific fiddling. If there was a standard GML, then a programmer with GML experience can leverage their existing skills regardless of language of the day, sort of like SQL and RegExp knowledge.''
** I understood what you meant. My answer was about server-centric app code. Pyjamas and Skulpt are designed for exactly that purpose. And there are many standard GMLs. One is the gooey collective known as HtmlDomJsCss+AjAx+Cookies+CGI. Another is called Flash. Yet another is called 'Java Applet'. One problem with standards is that there are so darn many of them. If you want to introduce '''yet another''' standard GML, then you really should ensure it's more than merely competitive: it needs to be 'better' than the incumbents by many relevant qualities and metrics. As is, I can leverage my existing skills (limited as they be) with HtmlDomJsCss+AjAx+Cookies+CGI independently of the language I use to write the server. And if I don't want to work with HtmlDomJsCss+++ directly, then I can use a tool to do the transformations for me because HTML+++ is 'standard' enough that people have written tools like Pyjamas and Skulpt.
** ''They score poorly in one or more of the "goals" listed above.''

* ''A single open-sourced CRUD/GUI browser programmed with C and established cross-platform GUI kits will be more consistent because there's only one code-base. I guarantee that if you look at the code of non-trivial JavaScript widgets, you will see tons of IF-version and IF-vendor statements all over the place. It's a time-bomb. ''
* Are you claiming GuiMachineLanguage, if successful, would only have one implementation that never forks? On what basis do you make that claim? Sure, JavaScript contains hacks for browser compatibility that I agree that would be better avoided. But it seems you assume GuiMachineLanguage will avoid these hacks on the dubious basis of never having more than one implementation... 
* ''No. I'm merely saying it's time to start over. We've squeezed HtmlDomJsCss to it's practical limit and can't trust Microsoft when it comes to desktop interfaces. ''
* We haven't pushed HtmlDomJsCss to anywhere near its practical limits. GoogleWebToolkit and Flapjax (http://www.flapjax-lang.org/) essentially use HtmlDomJsCss as a GUI assembly, and that's just the start of a new trend. Built-in support for SVG and Canvases in HTML5 offer powerful new mechanisms for GUIs that can be readily leveraged by JavaScript in DOM. DOM itself is being enhanced in HTML5 to further standardize and enhance certain problematic manipulations of HTML4. The only '''technical''' benefit you've proposed for GuiMachineLanguage so far consists essentially of a few new UI primitives, yet it's even unclear how making these primitives constitutes a significant 'benefit' given they're available via JS wizardry. I do agree we could do better than the HtmlDomJsCss+AjAx+HTTP/HTTPS+Cookies+CGI stack, but GuiMachineLanguage doesn't seem to qualify. Wisdom requires that an attempt to 'start over' or 'RewriteCodeFromScratch' take into account knowledge gained about the limitations of the architecture being replaced. Your attempt at a 'start over' is naive and foolish - you ''ignore'' the limitations of HTML that forced HTML to grow into HtmlDomJsCss+AjAx+Cookies+CGI, and instead you pretend that simply replacing the 'brochure-friendly' HTML component with a few 'CRUD-friendly' primitives will somehow solve the real problems.
** ''Couldn't you simply disagree rather than call people names ("foolish")? Everybody on the web is a fucking know-it-all self-elected genius. The ego-to-specifics ratio is gonna burst into space. Grow some people skills. Show I'm foolish with specifics rather than unbacked summary claims. Claims are cheap as dust. Since you didn't give specifics, there's not much to reply to. I will note that GuiMachineLanguage and HTML+++ stack is '''not necessarily mutually-exclusive'''. If HTML+++ can "execute" GML, then more power to it. I haven't seen any good demos of non-proprietary HTML+++ stack toolkits. I currently recommend Java applets for CRUD-oriented GUI's over HTML+++. It's the least evil, and I otherwise hate Java.''
** [No one is calling you foolish.  I quote the above: "Your '''attempt''' at a 'start over' is ... foolish."  It's your attempt that's foolish, not you.] 
** ''For most normal people, the difference between the two is too minor to bother pointing out. It is name-calling.''
** A modicum of logical thought would have told you that '''ignoring''' known concerns is a sort of foolishness evidenced by an '''absence''' of efforts to account for known concerns. Your attempt to 'start over' evidences a remarkable lack of effort to account for the issues that forced HTML to evolve into HTML+++. And your flustered sputtering about 'name-calling' rather than confronting the explanations for the accusation is ''not'' impressive; if you don't want people judging your behavior, then the answer is simple: don't post.
** ''Back to the topic, where's the grand demo of an open-source rich-GUI kit with editable data grids, combo boxes, MDI, etc? -t''
** [GoogleWebKit has already been mentioned.  Is it unsuitable?  I suspect the combination of it plus some work to extend it to cover whatever else you need should get you exactly where you want to be.  It's unreasonable to expect, as a programmer, that someone else has already written ''exactly'' what you want and is giving it away freely.  It does happen, of course, but it's unreasonable to expect it.  You're a programmer -- write some code if you need to.  I just looked at the latest version, and it's '''hot'''.  If you're not using it, you're just punishing yourself.]
*** PageAnchor "MDI_2"
*** I looked at about 10 demos a few months ago. I saw no MDI, no modal pop-up dialogs (outside of JS's built-in ones), and no usable editable data-grids, for a start. -t
*** [As I wrote, you may have to extend it to cover whatever else you need.  It's open source; that's what's good about having the source - you can do that.  If you're waiting for someone to write exactly what you want, you'll probably wait forever.  Write it yourself.]
*** So one has to write their own MDI manager and edit-able data grid and modal dialog manager. Thanks. If I'm going to do that, I might as well build a GuiMachineLanguage and tell Google to shove it. There's already plenty of options for the low-hanging GUI fruit. -t
*** [Creating a MDI in a browser is...  Weird.  But hey!  No one's forcing you to use GoogleWebKit or anything else.  You go build GuiMachineLanguage.  Call us when you're done.]
*** Why is it "weird"? There seems to be a conceptual disconnect here. Where else ''should'' it be?  I've seen OracleForm-generated Java applets that come close. -t
*** [Why do you need an MDI interface in one browser session?  What about separate browser windows, one per document?  Or tabbed panes?  Note that Access 2007 deprecates the MDI interface and defaults to tabbed panes.  If you're trying to recreate the look-and-feel of a desktop app, why not just create a desktop app that's downloaded from a Web page and communicates with the server via ODBC, JDBC, WebServices, etc.?  With Java applets, you can create full desktop-like apps.  Indeed, my usual approach with Applets is to simply take a desktop app I've written and make an Applet that launches it.  However, they're an entirely distinct technology.  Applets are a way of launching Java applications from within a browser.  They do not otherwise use the browser.]
*** The Access 2007 interface sucks in my opinion. As a choice, fine, but not forced. Anyhow, separate browser windows can make an app confusing because the "secondary" window completely covers the primary one because newer browsers take away window sizing control. You lose that "on top of" visual. Second, one cannot create '''modal''' dialog boxes. The dialog box in a web browser may get accidentally placed behind the primary window via one wrong mouse-stroke, leaving the user in a confused state. I've observed how people work with GUI's over the years, and notice patterns that web browsers cause problems with. There are repeating desktop GUI patterns in different desktop GUI tools because they '''solve real UI problems'''. They are not just random or me-too (although there's some of that also). -t
*** As far as Java applets, the real problem with them is that they pretty much require Java as your app language. GuiMachineLanguage could be used by Java, Perl, Lisp, COBOL, etc. One of the primary reasons for GML is to '''divorce GUI idioms from app language idioms'''. This makes it more portable and reduces language fan-boy wars.
*** (EditHint, move some of the above discussion to MdiScreensInWebBrowsers)

** TopMind, how is your question about an open-source rich-GUI kit at all relevant to the 'topic' of making a positive relative impression for GuiMachineLanguage? I haven't seen a non-proprietary GuiMachineLanguage toolkit. Have you?
** ''Not sure what your point is here. That since bad non-proprietary tools already exist, we should stop looking for something better?''
** It's okay to say tools could be richer and have more 'open' implementation, TopMind. But it's also off-topic, unless you are claiming that GuiMachineLanguage is richer and has a more 'open' implementation. If you are claiming that GuiMachineLanguage has a more open implementation, you're a liar. If you aren't, then you're off-topic. Giving you the benefit of the doubt, I ask "how is your question relevant" to 'point' out that it is off-topic. 

* As far as "can't trust Microsoft", I believe the trend towards WebApplication''''''s continues regardless of Microsoft's desires; they simply aren't any longer in a position where they can effectively sabotage that effort without being obvious about it. They recognize this, too. Their own new designs (WindowsPresentationFoundation) aim instead to '''compete''' with WebApplication''''''s.
* ''They want to be "in the game" to maintain some control, but I truly doubt they will make it easy to abandon native desktop apps by making web-based GUI's sufficiently desktop-like. That would be '''suicide''' under their current revenue system. If I was an MS bean-counter, I'd do the same thing they are doing: embrace, extend, then sabotage open-standards. What '''rational reason''' does MS have to make it easier replace desktop apps with web-based-rich-GUI's? MS still controls the number-one web browser, and that gives them good leverage over web GUI standards.''
* Again, their desires aren't particularly relevant to continuing progress towards WebApplication''''''s. They are not the only player "in the game". They cannot undo projects like MozillaPrism (http://en.wikipedia.org/wiki/Mozilla_Prism), and more will follow with or without Microsoft's blessing. The control they have on IE browser is more precarious than you imagine - down to 65% in 2009, and only maintained through competing feature-wise with alternatives (e.g. they took a huge hit to tabbed browsing). Chrome is up to 3% and is less than a year old and pushes WebApplication''''''s (and even WebOS) heavily. Even if Microsoft makes no effort to "make it easy to abandon native desktop apps", it will continue to become easier to abandon native desktop apps. Even if Microsoft makes explicit effort to sabotage WebApplication''''''s, it will continue to become easier to abandon native desktop apps. Microsoft aims to lock people into an alternatives, like WindowsPresentationFoundation, that compete with WebApplication''''''s via more advanced networking, persistence, integration, etc. and a similar flexibility profile - a reasonable tactic to avoid a complete loss. Your whole 'end of WebApplication''''''s is nigh and Microsoft is a horseman' gloom and doom pessimism is not warranted.
* ''Current efforts and tools are simply not good enough so far to overcome MS's gravity.''
* HandWaving that uses the word 'gravity' is only slightly more convincing than HandWaving that doesn't.
* ''Like where's your double-blind certified published study on MS and market-forces? Bloody hypocrite! And rude to boot. Communicating with AspergersSyndrome egos can be so damned sufferable.''
* Hypocrisy? Hardly. It's abundantly clear to anyone with two eyes, two fingers, and the Internet that many previously desktop apps are now WebApplication''''''s - calendars, e-mail, tax software, document editors, notes management, spreadsheets. You are the doomsayer who keeps spouting irrational beliefs despite all evidence being stacked against him. Communicating with irrational fanatics can be so damned sufferable. (And since you seem to be trying your hand at diagnostic psychology, I suggest you don't give up your day job just yet.)
* ''So you think I'm the minority with my belief that OSS HTML+++ cannot scale/bend toward CRUD-friendly GUI kits without a meltdown or Tower of Babble? -t''
* I'd say that HtmlDomJsCss+AjAx+Cookies+CGI is ''already'' a TowerOfBabel. That ''does not'' justify your doomsaying claims that Microsoft will somehow topple it. And it would be a glaring fallacy to assume GuiMachineLanguage would do better. 
* As to whether HTML+++ can continue to 'scale'? Yes, I believe you in the minority if you claim it cannot scale to support the desktop applications of yesteryear. GoogleWebToolkit, TiddlyWiki, activewidgets, and the vast supply of existing WebApplication''''''s would convince all but the most stubborn and unreasonable of people, leaving behind only TopMind and a small handful of other people who possess an agenda to maintain their own ignorance. That said, modern applications are networked, hooking into external data sources, needing up-to-date data in near real-time, and involve more than one simultaneous user interacting and issuing updates. Many apps still holding to the desktop are graphics-intensive or require specialized input devices. Modern services cross organizations - reservation of a plane ticket, hotel, and car from three different organization, for example - and people want the ability to abort halfway through, back up, guarantee they pay for a service only once rather than once-per-click, and maintain security and privacy all the while. Can HTML+++ 'scale' to support these desktop applications and services of today and tomorrow without resorting to plugins? I doubt it.
* ''The existing OSS stuff is crap. It's about at Apple Lisa GUI level in maturity (unless doing eBrochures, where it does shine). '''I invite you to link to a web gui demo''' with the features I often mention (not something one has to install).'' 
* That really isn't relevant - even if "the existing OSS stuff is crap", it at least exists - which is better than your so-called competition. But, answering your invitation, check out http://www.extjs.com/products/extjs/ .
* ''These cost money, and are therefore proprietary. And the grid widget does not accept typical arrow key navigation. It's thus costly and unpolished.''
* The http://www.extjs.com widgets are OpenSource. You may choose to pay for a commercial license if you'd rather not accept the terms compatible with GPLv3 (http://www.extjs.com/products/license.php). Also, the grid widget's 'arrow key navigation' works fine, though you need to choose the editable grid (http://www.extjs.com/deploy/dev/examples/grid/edit-grid.html) to reference individual cells. Clearly, you offered not more than a cursory glance while looking for excuses to ignore the reference. If you demonstrate such negligent ignorance on this subject again, it's going into ObjectiveEvidenceAgainstTopDiscussion.
* ''The arrow keys are not working properly for me, even at the editable link. I tried both IE and FireFox. If I'm wrong about open-source, I apologize. I saw a price page at: http://www.extjs.com/store/extjs/ ''
* I've used both IE and FireFox and the arrow-keys work fine in both. But if the cursor is blinking, then 'down' is within the text. Tap 'ESC' to switch back to navigating the grid.
* ''Okay, ESC worked, but that's not intuitive and against common spreadsheet convention. The down-arrow should take it out of edit mode rather than do nothing. I've been using that convention for at least a decade. Even dBASE grids do it right. Even the first spreadsheet, VisiCalc, got it right (http://www.bricklin.com/history/vclicense.htm ). Further, the Enter key should toggle the check-box, per common convention. At least 0 and 1 or Y and N should work. It's as if they either didn't test these in production, or doing it "right" is too hard. These kinds of things are important to those of us who like tables and/or do a lot of data-entry.''
* Whether that is "right" is a matter of opinion and historical convention, and depends on what sort of data gets stored in the cell ('down' for the drop-box in edit mode, for example, should navigate the box). Chances are 'down' navigates multi-line text (which you can't enter in this case). The distinction seems to be that the 'forms' used for the grid are not grid-aware - they're the same, generic forms that could be added anywhere else on the page. Most of the Tutorials for editable grids focus on hooking them up to Databases. But you're free to explore the API if the small details are bothering you. I certainly agree on the check-box, but I suspect they have already heard that complaint and have it on a backburner. Ultimately, you're quibbling. The ''relevant'' question is ''"can HTML++ do this with less effort than creating a new standard, deploying it, and convincing '''enough''' clients to use the new standard that skill in it becomes marketable?"'', and the answer is 'yes'. OpenSource is icing on the cake at best - it isn't as though you have a serious OpenSource competitor lined up. Perhaps you should give me an estimate on how long it would take you to have an editable grid in GuiMachineLanguage that has all the 'little details' filled in, including correct behavior for each cell based on 'type', support for date types with a date-picker, support for enumerative drop-box, etc. and that can load data from an XML file as with the example in question.
* ''Hopefully it would use an existing GUI engine that already has road-tested widget behavior. And again, if HTML++ get's it right, then GML could use it as its base.''
* If I was already using HTML++ as a GUI assembly, why would I want to add yet another layer of fragile dependencies upon an even less standard GML?
* ''So now HTML++ is "frafile?" It's great for one of your arguments and then crappy for another. This looks like inconsistency.''
* I have never said HTML++ is 'great' - not in any absolute sense. What I've been saying is that GML isn't any better. GML will become GML+++ and will suck as much as HTML++, except the process of replacing HTML++ is expensive and adds a whole new level of suckage... because rework, in general, sucks.
* ''No, because it's kind of a DomainSpecificLanguage that has CRUD in mind as the primary target instead of eBrochures trying to masquerade as CRUD-able. And it's not just about arrow keys. Even if one widget is fixed, I'm skeptical they'd all work together well when used in a desk-top-like way. Almost every new integer release of a browser will break something pivotal.''
* I match you with the same skepticisms directed towards GuiMachineLanguage. You claim GML has CRUD "in mind", but I'm not convinced it is actually better for CRUD from the perspective of application and server developers. You claim HTML++ will 'break something pivotal' with every HTML++ browser release, but I don't believe you can offer me good reason to believe differently about GML-browsers. You argue that GML will avoid becoming GML+++ because it is aimed at CRUD, but to me that sounds no different than claiming HTML won't become HTML+++ because it's aimed at brochures and simple forms. It seems to me that you're merely putting your faith in the browser-developers and withholding it from the widget-library developers, whereas I have faith in neither.
* ''Please clarify. The difference is that HTML++ "fixers" are stuck with using multi-vendor DOM and JS, while a CRUD-browser builder can start from scratch with languages, conventions, and tools '''fit for the task/domain'''. They have big constraints that the latter don't have. Sure, it may fork someday, but at least the basics of the domain are there BEFORE the fork. If you do it after, then you have big baggage. -t''
* A CRUD-browser builder can 'start from scratch', sure. But merely starting from scratch is insufficient to claim that the end product will be 'better'. What makes you think your GML - ''by which I refer to the four-column design and anti-scripting and alleged 'security' rules, as opposed to a much more general concept of restarting'' - would be 'better' for CRUD-screen developers? If your ''point'' is that it's time to look for something better, I certainly agree. I've done much thinking about how to do better - and the approach I've come up with is full of what you consider to be 'gold plating' fulfilling feature-requirements of today and tomorrow rather than of yesteryear. If your ''point'' is that GML long-term will be better than HTML++, I remain extremely skeptical. Which is your point, or am I missing it entirely?
* ''It's not clear to me what the two choice paths are in your paragraph. My suggestion will be better because turning a car into a boat has proven so ugly such that any problems arising from just making a boat from near-scratch are likely to be fewer. At the very least, providing multiple different approaches to be tested in the market-place like natural-selection mutations may be easier than BigDesignUpFront. Your approach is likely to fail because it solves problems that people don't currently give much thought to. '''You are scratching the wrong itch'''. Thus, it's a hard-sell, which means people will just ignore it. Further, I don't believe in your sells skills to make it clear to most practitioners why they need that stuff and how your contraption actually works in the field. Dr. Codd got more listen when he showed it reducing the size of queries compared to CODYSAL (sp?) rather than just rant about theory, elegance, and purity. -t''
* Your claim that "people don't currently give much thought to" the problems being solved seems contradicted by leading software development blogs I read, but I'll admit that I tend to be biased towards reading software-architecture and language-design blogs. To which people do ''you'' refer, and what are ''your'' biases? And I agree on my salesmanship skills - they suck; I'm not the one to sell my ideas to others. But I also don't believe you'll be able to 'sell' your idea, either - not when it requires a bunch of changes to browsers and servers to take real advantage. Inertia is a bitch, and HTML++ is her alpha male. You want to know what sells? GoogleWebToolkit, and http://www.extjs.com widgets, and other approaches that leverage modern architectures such as Flapjax and Caja and HTML5 and MicrosoftSilverlight. That's what sells.
* ''I come from the perspective of custom biz app developers who miss the simplicity and richness of VB6, Delphi, PowerBuilder, ClarionLanguage, FoxPro 3+, etc. for the GUI side of things. A lot of people are frustrated with HTML++ and are growing impatient waiting for it to catch up with desktops from the mid-90's. I don't know what you mean by "change to servers". It would merely require language-specific adaptors and/or an XML service. As far as inertia of HTML++, maybe, but IT history is full of meteors that came out of nowhere to smack a dinosour square in the nuts. Sometimes the hype was merely hype for hype's sake, but still managed to change the scene. It's not always rational. If they somehow do perfect HTML++, then maybe a cross-language standard will emerge that looks kind of like GML, or the XML equivalent. -t''
* I believe your assertion about 'merely requiring language-specific adaptors and/or an XML service' lacks adequate justification, and I warn that JustIsaDangerousWord. You focus on display characteristics, and you (I suspect) neglect the issues of communications context (such as session management, multi-page operations) and the implications of GML's current definition upon such management.
* ''Session management can barrow idioms and techniuqes from web languages and kits, and perhaps piggy-back on them. What is an example of a "multi-page operation" that would make a decent UseCase?''

* ''As far as features like automatic session recovery, etc., even '''existing''' web kits and web-apps usually lack there. Moving the goalposts are we? They are a just personal HobbyHorse''''''s of yours; that's why you obsess on them and mention them over and over and over and over and over. -t''
* No, those are features people want. Those '''are''' the goal-posts for any 'change' from the incumbent HtmlDomJsCss. They aren't mere HobbyHorse''''''s; they are things I see people wanting in blogs, on wishlists, etc. Moving goal-posts are a sign of progress. GuiMachineLanguage is attempting to meet the goals of 1985. It ain't my fault you're stuck in the past with ExBase and Music on MTV.
* ''My observation differs from yours. Let's AgreeToDisagree on the feature popularity thing. Yes, people want magic session recovery, but they also want a decent GUI at least as much.''
* Sure, people want a decent GUI. That has never been a point of contention. But your belief seems to be that providing primitive support for a few extra widgets is sufficient to achieve a decent GUI and allows you to ignore and dismiss both a long history of lessons learned that lead HTML to add cookies, scripting, DOM, AjAx, iframes, etc. Additionally, you ignore and dismiss (as 'gold-plate') long wishlists of features that HTML++ has yet to meet, which means you aren't meeting the goals of ''today'' whether you agree they are important or not. (Who are you to say what's important to other people?)
* ''That "long history" has also made HTML++ into a convoluted mess that carries a lot of interface and convention baggage.''
* That doesn't make it wise to dismiss it, TopMind. Those who don't learn from history are doomed to repeat it. When your GML can account for the problems solved by scripting, DOM, CascadingStyleSheets, AjAx, cookies, iframes, etc. you might have a decent replacement for HTML++ as GUI assembly.
* ''I did learn from history: make it fit the task (CrudScreen) so that we don't have to bend other standards (e-brochures) in an ugly way.''
* How does that account for the problems solved by scripting, DOM, CascadingStyleSheets, AjAx, cookies, iframes, etc? Am I to simply assume it does? You really do believe that a few different UI primitives would make the "convoluted mess" go away, don't you? Well, you give that a try. I don't know many people that will take that on faith; the only reason ''you'' take it on faith is because it's your idea.
* ''Are we to just accept HTML++ because it gets us 70% of the way there by saying "since we are already 70% there we should stay there"? The open issue is if HTML++ can get us nearly all the way without bending so far backward that it sniffs its own butt and snaps.''
* Are we to "just accept HTML++"? No, not at all. But we are to look at any potential alternative to HTML++ and say: "is it worth the nigh-Herculean effort to replace HTML++ with this alternative?" It would not be worth the cost to replace HTML++ with a solution that gets us to only 75% of the way. It would be a step backwards to replace HTML++ with a solution that gets us to 65% of the way. Therefore, we do not need to "just accept HTML++", but we ought to be skeptical of promises and claims about alternatives.
* ''I don't beleive any of our forcasting skills is accurate within 10%. With a big margin of uncertainty, it's a good idea to have a viable alternative; especially since Microsoft sees rich GUI's as a big threat to it's living. MS couldn't sabatog a seperate browser/pluggin that doesn't directly use Windows GUI libraries. -t''
* The numbers were merely didactic: they don't account for different 'subsets' of useful features (e.g. your 65/100 and my 70/100 might only overlap for 50/100) or moving goal-posts (natural to progress). It wasn't an attempt to be precise. 
* Anyhow, I still doubt the value of your 'sabotage' argument as an argument against HTML++ for many reasons: (1) I don't believe Microsoft is as capable as you suggest. (2) Even if MS sabotages its own browser, that ''still'' leaves HTML++ in a better position of development and deployment than most new alternatives. (3) With an equal degree of paranoia and speculation, I should respond: Who is to say that MS or some other organization won't sabotage <pick alternative to HTML> the moment it starts becoming popular? (EmbraceAndExtend is Microsoft's friend.)
* ''Re: 1, MS has done plenty of sneaky things in the past and I've seen no evidence that they've stopped. Re: 2, Why do you say it leaves it in a better position? Re: 3, How could MS sabotage a dedicated GML browser? Most OSS GUI kits don't use the deeper MS Windows libraries, but draw most stuff from scratch, pixel-by-pixel, if I'm not mistaken. This is how they keep it cross-platform. Plus, if they damage native desktop libraries, then too many established desktop vendors will become pissed, which would hurt their main cash cow. Sabotaging an HTTP-based protocol is more likely to drive companies away from HTTP-based apps, which wouldn't hurt MS, perhaps even help by driving some back to desktop.''
* RE Re 1: I repeat: I don't believe MS is as '''capable''' as you suggest. Even if they don't stop doing sneaky things, I don't believe they're going to 'sneak' some critical element of HTML++ out from underneath it.  RE Re 2: It's in a better position because you'd still have Firefox, Chrome, etc. already widely deployed, implemented, debugged, maintained by other people. RE Re 3: MS has no need to sabotage a dedicated GML browser; they'd simply re-implement and beat the crap out of you in the popularity race, would they not? That'd simply put them back into the same position as IE is today, where they could 'sabotage' your paranoid self.
* ''As far as MS's abilities for sabotage, I'll leave that discussion in LimitsOfHtmlStack. Non-MS browser share is too small in corporate environments, where most CRUD features are used. Companies will not easily abandon IE. This is partly why XUL failed. I'm not sure where #2 fits in. Please elaborate the relationship. Number 3 would be fine because there'd be multiple browsers that support at least a "regular" set of CRUD features the same way all current browsers support basic e-brochure features.''
* Logic on #2:
** The "development and deployment of most new alternatives" is in a position with zero clients developed, zero clients deployed. (This is because they are 'new' alternatives.)
** If Microsoft sabotages Internet Explorer, I would need to tell my clients to switch to MozillaFirefox, GoogleChrome, or some other browser.
*** ''Or they say, "Make it work in IE or you lose our business/sale". Corporate bosses only know that IE is their current corporate standard and your product doesn't work in the latest IE. Only if MS busted a bunch of products all at once would people blame in on MS. Instead MS would likely gradually F-up IE such that it's blamed on web-app vendors: the BoiledFrogs concept.''
** MozillaFirefox and GoogleChrome already hold over 30% of the market. Thus, on average I'd need to tell fewer than 70% of my clients to install something. By comparison, a browser client for a 'new alternative' (like GML) requires that I tell 100% of my clients to install something. 
** Even if share of non-IE browsers is smaller in corporate environments, it's well above 0%. Besides, if Microsoft ''does'' sabotage WebApplication''''''s to the point that extjs and Google Calendar and such stop working, I am willing to gamble heavily that the corporate share for IE will drop like an anchor, and I won't even need to tell 70% of my clients to install something new. Additionally, if I were a paranoid crank like TopMind who was absolutely convinced of Microsoft sabotage, I'd just tell all of my clients to use MozillaFirefox or GoogleChrome from the start, and ''even then'' I'd be in a better deployment situation.
*** ''No. Google would change their JS to work in IE because it has market share, even if they use an "IF-vendor-equals-X and version=Y" statement.''
*** ''Further, if the gui browser became as popular as Chrome, then it would be one of the choices to consider.''
** Further, a new browser client for a 'new alternative' (like GML), isn't fully developed yet, nor will be the standard. Therefore, I cannot trust its stability, and its maturity is relatively limited compared to HTML++. For example, even many years ''after'' a GML browser exists, it is unlikely that I'll have neat tools to help me develop GML applications. HTML++ is more mature, more developed, in every sense.
** Therefore, sticking with HTML++ leaves me in a better position of deployment and development than new alternatives even in the event of Microsoft sabotage. QED.
* As far as your "Number 3 would be fine", what happened to your paranoia? Microsoft was going to ''sabotage'' HTML++ because they are super-anti-web-apps" by your moderately paranoid assessment, right? So they're not going to find sneaky, under-handed ways to sabotage a slightly more CrudScreen friendly design? Hmm. Well, Number 3 was an appeal to what I considered your paranoid faith that Microsoft will find ''some, unnamed, sneaky way'' to undermine HTML++. I can't really count on consistent irrationality (since that's an oxymoron).

Also, since you claim that ''"HtmlFive is also too open-ended in its widget descriptions"'', I'm calling you on that, too. Please justify that statement in HtmlFiveFlaws.

''Not this month. It's not a debate topic that interests me and is not pivotal to this topic.''
----
Top, if you think this is a good idea, go build it.  In the time you've spent defending it, you probably could have written it by now.

''I've found that I've been doing "custom dynamic applications" for so long that my skills with SystemsSoftware languages and techniques are rusty. At best I could make a clunky demo. Further, I'm currently working on a database-ish tool that is sort of "Toad Meets Access Meets SMEQL". One at a time. -t''

{Use ExBase, TopMind. Surely you'll be... what was it? ... ''"3 times more productive" (ExBaseRant)'' building a demo in that language as in a SystemsSoftware language?}

If the existing interpretative implementations with GUI's were not proprietary, I'd indeed try it. -top