Gui Machine Language Discussion

Further discussion of GuiMachineLanguage and LimitsOfHtmlStack.

(Continuation of discussion from RudenessFails)

My primary argument on GML has always been the same: your answer to "why?" is unsatisfactory. "Illogical" refers to specific sub-arguments, none of which are especially focused on GML (the word only appears twice in that page). HandWaving refers also to specific arguments - i.e. your attempts to argue 'security' benefits that are unrelated to security, your prophecies that Microsoft will somehow break HTML++ even worse than where GML is starting, your dubious anti-fanboyism marketing tactics, plus some meta-level argument about argument. Every time you start trying to answer "why?", sound and valid 'reasoning' gets left behind. The broad differences between GML and HTML (e.g. the four-column approach) are left unjustified.

(I split your paragraphs up to better associate replies. I apologize if it disrupts context.)

There's a lot of half-baked accusations there. Let's just focus on the Microsoft issue for now. What is an example where my reasoning is clearly poor? You claim that most my arguments are poor, but I am not understanding the thought process in your head that makes you conclude they are poor. You are not communicating that effectively. I only hear summary complaints, not specific fallacies in specific spots. I need the house address, not the zip-code.

Usually you claim that I'm not academically advanced enough to understand your arguments and evidence. I highly suspect it's just a cop-out on your part, a lazy short-cut around true articulation attempts, but let's put that aside for now by focusing on the Microsoft issue, which does not appear to be tied to ivory-tower theories, making it easier to communicate hopefully. Is this plan clear?

Even your one reasonable sub-argument that GML is more CrudScreen-friendly on the basis of having a few extra widgets is unsatisfactory, since that saves me perhaps 20% of the ugliness associated with a typical WebApplication:

That's NOT the full argument. I don't know what went wrong to make you bypass the others and assume that's the full of it, but it concerns me. There has been an ugly communications breakdown somewhere.

It's not just the quantity of widgets, but also them working well, working together, and being less sensitive to DOM engine and browser changes by browser vendors. I've been burned multiple times by browser version changes and defective HTML++ widgets. And I pointed out the arrow-key issue and check-box issue on your reference examples after testing them for only a few minutes. I bet somebody using them for several hours a day would find even more annoyances; let alone browser version issues and getting along with other DOM widgets. I've had problems where a widget would work fine in isolation, but act weird when a different or multiple widgets were placed on the same page.

PageAnchor: scripting_ties

I'll still need scripts to validate inputs;

Are you saying that GML doesn't provide scripting tie-ins? That's not the case. If you mean that scripting may still be needed for validation, that's only partially true. I proposed that basic type checking (number, integer, date), regular expression validation, and perhaps ranges be built in so that sequential code does not have to be downloaded for those common items. Markup representations may resemble:

 <input name="foo" type="integer" rangefrom=0 rangeto=9999>
 ...
 <input name="email_addr" regex="\w+@\w+" 
        regexMessage="invalid email address">

This will not eliminate all script- or server-driven validation, but a good bulk of it. The idea is that the common CRUD idioms are built in so that they can be indicated declaratively and easily.

I'll still have server-side and app-developer ugliness to bind inputs to the correct server side operations; I'll still need to support accessibility (multi-lingual, blindness, text search),

Please clarify.

still need to support hints and auto-complete, still need to support 'undo'

I haven't found much need for these in CRUD apps. "UNDO" is a coding and word-processing convention, not a CRUD convention. It would confuse most users, and is difficult to describe/document clearly in multi-user environments where multiple people may be changing any given record. Plus, HTML++ often doesn't support "UNDO" either. I can see it on a "text area" widget tool-bar, sort of like what one sees on WikiPedia edit boxes, but that's part of the widget.

And auto-completion is sometimes problematic for data-entry. Most CRUD tools lived without it for a long time without noticeable complaint. But because it's a nice feature to have available when needed, I'll give you small points on that one, okay? It could be added to GML if it becomes a deal-breaker anyhow.

still need confirmations and conflict resolutions, still need to support progress bars, alerts, and other forms of real-time updates;

HTML++ tools often don't provide these either. Progress bars can be emulated via custom programming in either case. Thus, that factor is a draw.

still need to support persistence or session recovery and mobility.

Same issue: HTML++ often doesn't supply it either. Thus, neither has an advantage in that category.

I have no reason to believe GML is CrudScreen-friendly in any but the shallowest of senses. I am left wondering why you don't just tweak HTML to add a few widgets and call it a 'new standard' (goodness knows we have enough standards) - that, at least, would have easy implementation since you could easily use MozillaFirefox or GoogleChrome as a starting point for the client, and many existing tools could adapt readily to use the new standard.

Both of those basically extend the e-brochure philosophy. They don't natively deal with CRUD conventions. Besides, I'm comparing GML to HTML++, not other things here. Let's finish HTML++ first. We have enough on our plate right now.

Thin Client Tilt

Note that I'm generally a fan of ThinClient because its hard to fix the clients compared to the server. There's usually one or few servers in one spot and dozens or hundreds of clients perhaps scattered across cities and states. Thus, it's usually easier to repair a bug in the server than a bug in all those scattered clients.

Things like transaction roll-backs and direct database manipulation are perhaps best handled at the server because they would otherwise gum up the client with complex features. This applies to both GML and HTML++ (and your type-heavy god-language gizmo).

After one has had to visit dozens of desktops to fix or update a client, they'll start to appreciate this. It is wasteful busy-work. I've blown entire days driving out to fix or update just one or two clients before. (They weren't my bugs.) Add features to clients sparingly. -t

Microsoft Sabotage Quote

(begin quote)

Microsoft's Web Sabotage Plans?

Many may be surprised to learn that AJAX technologies like iFrames and XHR were developed by Microsoft in 1996 and 1999. But then in 1999 Microsoft stopped all feature updates to its IE browser up to 2006. Also after promising in 1998 to have the most standards compliant browser Redmond has failed to deliver on many CSS, DOM, JavaScript and Web standards. For example, after 8 tries, its IE8 browser is less CSS compliant by a factor of 4 than Google's Chrome browser was able to achieve in its first version. Instead, Redmond maintains a growing set of proprietary extensions to IE8 and JScript while bypassing SVG, XForms, and E4X Web standards among others. In addition, JScript in the latest version of IE8 continues to trail the speed and performance of JavaScript in Google's Chrome and Mozilla's Firefox by nearly an order of magnitude. This is definitely not a good sign for Microsoft's support for AJAX. Some see it as allowing MS's Silverlight and .NET VM's to be Redmond's Windows-centric preferred Web solution while JScript takes second fiddle. Given the neglect and scheming against the Web by MSFT in the past, this concern cannot be lightly dismissed.

(end quote)

Source: http://theopensourcery.com/jsframeworks.htm

I see no evidence of "sabotage" here. What I see is simple good business sense. Microsoft has a sufficient browser market share, especially among its main customer base (corporate users) that it defines de-facto standards, and can shape various technologies as it sees fit. Microsoft can do whatever it likes with its customers, but any of them can choose to stop being Microsoft customers. Then they can use whatever they like. It would only be sabotage if Microsoft could prevent users from choosing or using Firefox, Chrome, and other alternatives. Similarly, any car manufacturer can choose to make a car that uses non-standard wheels, and can later choose to stop supplying them. Indeed, it's happened. Customers are then free not to buy that car or from that manufacturer again. I'm not aware of any case where a car manufacturer prevented the buying public from using other manufacturers' cars or wheels. So, it's not sabotage, it's just business.

Whether it's classified as "sabotage" or not, the outcome is the same. Before we get into LaynesLaw over "sabotage", will the person who made the statement "Microsoft has already made its attempt at sabotaging DOM" at LimitsOfHtmlStack please supply some more details on this. -t

Can Microsoft Sabotage GML?

Existing GUI engines tend to rely on one of two techniques or something in-between. The first is control at the pixel level. They mostly only assume that the OS and/or output device can draw pixels and return mouse coordinates in pixels. The rest is built upon this assumption.

Unless MS sabotages drawing pixels, they couldn't derail such an engine, and drawing pixels is a very root feature of a GUI.

The second approach is to use an OS's native idioms and widgets. This can save the effort of creating each widget from scratch (pixel-level), but also tends to tie the kit to a specific OS.

If a kit does this and GML language is based on it, then MS could sabotage GML by changing the Windows API. However, they'd likely break thousands of applications in the process, for those API's are behind a large volume of software. I'd estimate there's 100 times more applications based on Windows API's than on DOM at this point. Sabotaging Windows API's would be shooting themselves in the foot with a shot-gun, whereas sabotaging their DOM would be like using a BB-gun on their foot.

Note that they might try only tweaking with API's or API features that GML relies on. However, if it's that specific, then there's probably a work-around. It's not likely that GML would depend on a feature that almost no other software uses, and if there was such a thing, there's probably a work-around because its goal is fairly generic CRUD gui's, not 3D or gesture-UI's and the like. It could borrow the same solution that say Delphi uses. If MS breaks Delphi also, then likely they'll break tons other Windows-based software. -t

This same logic protecting GML also protects MozillaFirefox, GoogleChrome, and (therefore) HTML++ applications as a whole.

First, they don't have sufficient CRUD capabilities as they are. If someone adds them, that's fine, they'd then be creating a kind of GML (or XML-CRUD) itself, which is already 2/3 of my suggestion.

How is having CRUD capabilities relevant to the logic protecting GML - that MS cannot derail third-party applications including MozillaFirefox or GoogleChrome?
Please clarify.
You claimed MozillaFirefox and GoogleChrome don't have sufficient CRUD capabilities as a counter-point to "the logic protecting GML also protects MozillaFirefox and GoogleChrome". However, I see no logical relationship: whether or not third-party browsers have 'sufficient CRUD capabilities' seems to be completely unrelated to whether Microsoft can effectively sabotage these third-party browsers. Therefore, it seems that this counter-point was irrelevant. But I was nice and phrased my concerns as a question rather than outright accusing you of a NonSequitur. That question was, and remains, 'How is having CRUD capabilities relevant to the logic [in the above section] protecting GML [from Microsoft sabotage]?'
Most people call that "acting normal", not "being nice". Seems name-calling and insults are your normal mode and anything outside of that requires strain and sweating. Anyhow there appears to be a misunderstanding somewhere. Most businesses require that HTML++ works on IE. What non-IE browsers do doesn't make a whole lot of difference. Business managers may not understand that MS is hindering things with a dash of QwertySyndrome. Viable HTML++ de-facto standards must address IE first.
It seems you still feel irrelevant counter-points contribute to an argument, as you still haven't answered my question. Well, ducks go quack and cows go moo, so there! It also seems you feel that business managers will have a harder time accepting "WebApplication XYZ only works with GoogleChrome" or even "WebApplication XYZ only works with MozillaPrism" as opposed to "WebApplication XYZ only works with TopMind's quite-possibly-fly-by-night immature GML browser". I remain very skeptical on that point.
Again, there appears to be a miscommunication. I swear to Buddha I am NOT intentionally ducking anyhow. I honestly don't know what the hell you are trying to say. Maybe word it as a specific scenario along the lines of "On month-1 MS does foo to widget X in IE 7, making Mozilla display a green happy-face. On month-2 Mozilla counters by doing ...".
Sure. Please explain how breaking a widget in IE could cause Mozilla to display a green happy-face.
It was a very rough example to illustrate what I meant by a scenario, you...you.....delightful person.
Well, I would certainly have been impressed with your argument that Microsoft can sabotage HTML++ if you could convincingly argue that scenario.
See section titled "Sabotage Via Gradual Standards-Compliance" in LimitsOfHtmlStack for an example of how MS can sabotage HTML++.

Second, all the HTML baggage they already carry dilutes knowledge of CRUD capabilities and confuses users. They'll keep trying HTML-browser conventions and behaviors out of habit.

How is the HTML baggage relevant to your above logic about sabotaging pixel drawing or OS-native widgets and the Windows API?

Third, they are somewhat bulkier than what a dedicated CRUD-friendly would be because wouldn't have to carry much of the HTML-browser baggage.

How is being somewhat bulkier relevant to the argument third-party protecting applications like MozillaFirefox and GoogleChrome?

It seems that none of your three points are relevant as arguments against "the same logic protecting GML also protects MozillaFirefox and GoogleChrome", and thus it seems logically inappropriate for you to have asserted them in this context.

Similarly, the same logic arguing that Microsoft can sabotage InternetExplorer also applies to Microsoft creating its own not-quite-standard version of GML and defeating you in your own game, like they did to Netscape.

I already addressed this somewhere. If they clone a CRUD-friendly browser, then at least the basics of crud-oriented behavior would be there. If they fork away later, it will be on bonus features, not core crud. In other words, they'd at least have to step into the CRUD arena. It's like how all web browsers support a minimum set of HTML, thus you know you can get basic e-brochures out of each. The initial CRUD features would be pretty-much locked into the de-facto standard. MS couldn't break away from Netscape's standard cycle until they had about 60% of market share. They had to buy a browser to catch up fast. By the time they could do that, the de-defacto HTML++ features were "good enough" for e-brochures. A 'small amount of vendor-specific IF statements for a few extra's is acceptable.

So, if I understand your logic, you believe Microsoft can significantly sabotage HTML++, but will not be able to significantly sabotage GML++ merely because the widget sets are different. Is this right?
No no no. I'm not sure where you got lost there. I'll have to revisit to see if you are misinterpreting something. Look at it this way, MS cannot sabotage "generic" HTML itself (minus the "++"). Those standards are too established. The "++" standards on the other hand are less established. After all, you cannot break a standard if there is no standard to break. The messy state of ++ gives MS room for almost legitimate excuses to tweak them enough to break threats.

In any case, you have yet to argue for a successful sabotage - one that leaves HTML++ in a bad position (relative to its competitors) as opposed to one that leaves Microsoft in the bad position of having WebApplication developers simply telling their clients to abandon the IE browser.

Like I said elsewhere, it would only have to about a 25% chance of happening. Further, MS would sacrifice IE to save it's desktop. Remember, Internet Explorer is free; it brings in no direct revenue while Windows and their desktop software does. MS keeps IE around mostly as a strategic option. -t

Not all sacrifices are useful... indeed, throughout history, the vast majority of sacrifice amounts to wasting lives and resources then praying. InternetExplorer is Microsoft's sabotage of HTML++, and has been from the very beginning, coining the phrase EmbraceAndExtend (more thoroughly: embrace, extend, and extinguish - http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish). Dropping IE improves HTML++ as a WebApplication platform because Safari, Firefox, Chrome, Opera all rank much higher for standards compatibility - Microsoft's JScript and DOM bindings are the only variants wildly different from EcmaScript ECMA-262 and W3C DocumentObjectModel standards. Sacrificing IE, or even letting it fall into disrepair, will not save the desktop; it will only hurt Microsoft's image, result in a migration away from IE, and make WebApplication programming simpler since a primary cause of special cases can be removed from the code.

I didn't mean dropping, but merely tweaking it enough to screw with an emerging working HTML++ CRUD standard. I agree that MS has to walk a narrow path in weighing what to harm to what degree. Too weak an HTML++ browser gives the other browsers too much market share and too strong of one leaves the door open for an HTML++ standard eating into it's desktop market. Perhaps in the end it's a losing battle, but that does not mean MS won't fight dirty to delay its death, even if inevitable. Dying things are often desperate things. They may decided to slowly kill EI by crippling its HTML++ in order to save their cash cow, the desktop market, if other browsers get powerful enough GUI's and features to eat into MS's desktop market.

IE is given away for free, yet MS keeps supporting it because it knows it's a leveraging tool. (True, it's also used for increasing Bing's share.)

And big corporations will not toss IE overnight because they have too much invested in it. Look at all the brewhah over corporate apps locked to IE 6's functionality. True, these corporations were stupid to do that, but MS repeatedly relies on stupidity to make a buck.