Gui Machine Language Security Discussion

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.

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:

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

Regarding "hiding", I'd suggest having these "show-states" (when applicable):

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:

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 DomainSpecificLanguages 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:

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 GmlDomJs?

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.

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:

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:

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 HobbyHorses being involved in other proposed solutions - it had no real point being above. So I moved it.

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, 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.

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

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.

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 LanguagePissingMatches.

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 LanguagePissingMatchs", 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.

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?

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.

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.)

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 CrudScreens) 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 CrudScreens 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.

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

EditText of this page (last edited November 29, 2013) or FindPage with title or text search