Continued from HofPattern.

''Note that CGB stands for Commodity (or Common) Gui Behavior.''
-------

This example uses a hypothetical HTML-like markup language to demonstrate a grid of multiple panels that refresh independently at their own refresh rate. The example name gets its nickname from the 70's Brady Bunch show's opening sequence showing active shots of the heads of each Brady family member. Each "box" is generally independent. This demonstrates what could be a more compact version of a "frameset" or "iframe" approach that would use the "refresh" header. (A "revised" version in the links has horizontal bar charts stacked on top of each other.)

This particular example shows five 200x200 pixel boxes across for each row. Interval unit is "seconds" unless specified otherwise (default unit). A "frame div" is sort of a hybrid between an HTML "div" and a "frame" or "iframe". Each frame-div "panel" runs a php script, although it could be Javascript, etc. The point is that each panel is an independent browser "window" like HTML frames and iframes.

 <!-- Define repeating attributes to avoid repeating. -->
 <!-- In some ways it's like a style-sheet, but using markup. -->
 <attribset name=atr>
   <attrib name=autorefresh value=yes/>
   <attrib name=width  value=200/>
   <attrib name=height value=200/>
   <attrib name=float  value=left/>
   <attrib name=autoscroll value=yes/>
   <attrib name=border value=1>
 </attribset>

 <div>  <!-- row 1 -->
   <framediv attribs=atr interval=2.5 src="panel.php?x=1&y=1"/>
   <framediv attribs=atr interval=1.0 src="panel.php?x=2&y=1"/>
   <framediv attribs=atr interval=2.0 src="panel.php?x=3&y=1"/>
   <framediv attribs=atr interval=8.5 src="panel.php?x=4&y=1"/>
   <framediv attribs=atr interval=4.0 src="panel.php?x=5&y=1"/>
 </div>
 <div>  <!-- row 2 -->
   <framediv attribs=atr interval=9.5 src="panel.php?x=1&y=2"/>
   <framediv attribs=atr interval=1.0 src="panel.php?x=2&y=2"/>
   <framediv attribs=atr interval=2.0 src="panel.php?x=3&y=2"/>
   <framediv attribs=atr interval=8.5 src="panel.php?x=4&y=2"/>
   <framediv attribs=atr interval=6.0 src="panel.php?x=5&y=2"/>
 </div>
 <div>  <!-- row 3 -->
   <framediv attribs=atr interval=6.1 src="panel.php?x=1&y=3"/>
   <framediv attribs=atr interval=2.0 src="panel.php?x=2&y=3"/>
   <framediv attribs=atr interval=2.0 src="panel.php?x=3&y=3"/>
   <framediv attribs=atr interval=4.5 src="panel.php?x=4&y=3"/>
   <framediv attribs=atr interval=3.0 src="panel.php?x=5&y=3"/>
 </div>
 <!-- Etc... -->

(It could be made even shorter using the "template" approach shown in GuiMarkupProposal.)

A better UI approach would allow the user to re-size the grid row and column dimensions, similar to how one would in a spreadsheet. HTML "framesets" sort of allow this, but only one dimension propagates the resizing.

It's my opinion that markup-based GUI's are generally easier to learn and remember for typical custom business developers, as most developers will be using a variety of different languages, and some will be doing mostly server-side UI control and some client-side. Markup allows them to develop sufficient server-side-controlled interfaces without mastering the nitty gritty of a client language, such as JavaScript + DOM. (Server-side UI control is also less likely to "break" due to client upgrades or vendor differences. Internal apps especially tend to rely on the server-centric UI control.)

--top

[The first problem I see here is that if the number of divisions change, or the syntax for accessing panel.php changes, or really ''anything'' changes, you're going to need to change multiple lines of markup to cope with that (you'll need at least one more <framediv> line for any extra division added, and you'll need to change ''every'' line if panel.php changes). Under the original example, changing each of those things only requires one to change a single line of JavaScript. -DavidMcLean]

Regenerate the HTML with a button or hyperlink if it needs to change. Web pages have been doing this for almost 2 decades. A trivial fix. And of course one can change the DOM or equivalent on the client side.

[Obviously you ''can'' change that stuff. That's what I was talking about: If you need to change the number of divisions, or the access to panel.php, or anything, you need to change the stuff in the DOM. It's still more stuff being changed than under the original approach. -DavidMcLean]

That depends on how the GUI "structure" is specified.

[Given the structure you've shown above, there are more change points than under the original approach. If you have a different structure in mind to the one you've already shown us, show that one. -DavidMcLean]

How are you calculating that? Pick a scenario.

[Under any scenario. There's more "code" in this markup approach, therefore any change or maintenance will potentially touch a larger volume of code. For example, if you need to add more divisions, you need to add a whole markup line like the above for each new division. With the JavaScript method, you change the numberOfDivisions variable, which is exactly one line no matter how many divisions you add---heck, it's one ''token'' no matter how many you add. -DavidMcLean]

Either it's going to write to the DOM/equiv or write markup. Either way it's going to loop for each row. Yes the main "generator" function may accept a single integer for number of rows, but ''something'' is still going to loop for each row.

[Ah, so the unspoken assumption with your above example is that the developer ''won't'' write out the markup shown, but will instead use a loop to generate it? Fair enough; that does address that particular concern.]

[However, <framediv> as shown will only address exactly one use of AJAX, that of blindly updating a page section with a given interval; AJAX happens to do other stuff too. I know the original example doesn't have them, but what about, for example, notifications? Suppose there are some cases where you'd want a "popup" notification shown at the top of the page, perhaps making sure the user can't miss a particularly important bit of monitoring information. How does your design address these? -DavidMcLean ]

Using the MDI GUI model. Div's and Framediv's would be part of the same "window", and a different new (or "activated") window would pop up on top. That's how GUI's used to work, but the browsers bastardized that model for unknown reasons. A variation on "target=_blank" tends to be used with browsers, although the JS/Dom "window.open()" tends to give one more control.

[So, to confirm, you're suggesting opening a small popup window to display notifications? I see two issues with this. Firstly, how do you propose to trigger and open this notification popup? I don't see how your proposed methods for communicating with the server will enable this, although it's possible with AJAX. Second, is it really a good idea to open a full new browser window, with all the browser chrome (sometimes you can stop that, but at least with a title bar), for a transient notification? -DavidMcLean]

No, we don't need a "full" browser window, but the existing HtmlStack gives us stupid alternatives. That's not my fault. And how are we defining "browser window"? When is a rectangle panel "on top" a window and not a window? The kind of features/behavior we want on a "window" can run the gamut. I'm not quite sure what kind of notifications you are envisioning. Please be more specific. There are a lot of ways to notify and I cannot read your mind.

[Popup notifications of the sort lots of major sites use, including Facebook. Here's one implementation, for jQuery, which has some examples you can play with to get the idea: http://needim.github.com/noty/ How do you propose handling these? -DavidMcLean]

Well, that's one "type" of window. What's your point? By the way, those draw in clunky fashion, like Commodore 64 graphics. That's because people try to use JavaScript as SystemsSoftware, which is not its forte.

[With your AJAX-free model of the Web, how does the Web server deliver notification messages to the client, such that they may be displayed like in that example? Also, if you don't like how those look, there are plenty of other libs around: http://boedesign.com/demos/gritter/ and http://codeseven.github.com/toastr/ for example, both of which mostly resemble Growl for Mac OS X. -DavidMcLean]

When a given "cell" panel with a "condition" refreshes, it can contain the code to draw the pop-up window, somewhat similar to how one may put a JS "alert()" box in a web page. Ideally the characteristics of the pop-up window would be controlled by the markup specification: resizable, closable, transparency, etc.

[Under the standard model of what frames mean, the contents of a frame can't really affect what's going on in other frames; you're free to change what frames mean, though, so that's not a good counterpoint. Aside from that, under this method the notifications must be delivered with and are therefore tied to a specific existing panel. What if there's a notification ''not'' related to an individual panel, something about the state of the system as a whole? How would that be handled? -DavidMcLean]

I'm not sure what you mean by "tied to" here.

[First, I'll clarify that I do indeed understand what you're suggesting. Are you saying that notifications would be handled by modifying the HTML generated and sent by panel.php to a specific panel, such that it includes something like a <script> tag with code for spawning the notification? -DavidMcLean]

* Ideally we wouldn't need to write JS, we'd just send markup to draw a new window. The "file per window" model should be killed. A given markup stream should be able to draw multiple "windows". It would default to the current window, like HTML does, but the same "stream" should be able to include something like a "<document>" or "<window>" tag set.
* [Again, to clarify: Are you suggesting that notifications would be handled by modifying the HTML (well, the non-HTML markup) generated and sent by panel.php to a specific panel, such that it includes a <window> or <document> tag for spawning the notification? -DavidMcLean]
* That's one option. Whether we use markup or write to the DOM equivalent depends. Sometimes the window designer is a graphics designer and not a programmer for external "salesy" apps, in which case it would be easier for them to create a window through markup (possibly through a graphics design tool). That's another advantage of markup I forgot to mention: DivideAndConquer skills between a graphics-oriented person and a programmer.
* [Okay, so you are indeed saying that notifications would be added to the markup delivered through panel.php, either simply as markup or as code for manipulating your equivalent to the DOM. Given that, how do you propose to deliver a system-wide notification? You could just stuff the appropriate markup into one of the panels at random, but that's mixing up unrelated concerns and is a mess. What's your plan? -DavidMcLean]
* I don't know off hand. Having a hidden "system-listening" window that checks every second or so is one approach (polling). There's no rule that a hidden window can't talk to the servers. Some JS clients seem to keep the HTTP connection open "forever" but this results in goofy browser behavior, and is generally considered a hack. HTTP lacks a formal "push" protocol from server to client; it's generally designed for ask/answer type of communication and for security purposes, browsers and/or routers don't allow just any server to talk to a client directly. Perhaps this should be fixed as far as standards go, but we would kind of be reinventing Email. How would your magic HOF solve missing communications protocols?
* [Actually, there's a protocol available. It's called WebSockets and is part of HTML5. For an actual application, I'd tend toward using Socket.IO for that purpose, since it degrades to work in non-HTML5 browsers: http://socket.io/ There's also another HTML5 feature called Server-Sent Events, which is lighter-weight and pretty much perfect for stuff like delivering notifications. How would your markup-oriented method provide this functionality? -DavidMcLean]
* That's kind of wandering off topic, but we could have "listener" events something like this:

  <listener protocol=websocket>
     <window...>DANGER, WILL ROBINSON! DANGER!...</window>
  </listener>
  ..or..
  <listener protocol=websocket name=foo>  <!-- listens for "foo" only -->
     <window...>...</window>
  </listener>
  ..or..
  <listener protocol=websocket name=foo passthru=no>
     <!-- passthru=no means it doesn't allow other listener
          events to act on it. This "absorbs" it. -->
     <window...>...</window>
  </listener>

* [Not really off-topic; you asked how my "magic HOF" solves missing communication protocols, and I responded with the missing communication protocols. <listener> events would probably work okay for dealing with server-sent events; they're almost entirely equivalent to the way server-sent events already work, modulo trivial syntax differences:]

	var es = new EventSource("/sse"); // connect to SSE source
	es.addEventListener("foo", function(data) { // listens for "foo" events only
		doSomethingWith(data);
	});

* [I'm not really sure from your example how one accesses the actual data sent in the SSE (say, the text of the notification), however. Despite this, such markup is inadequate for WebSockets, because it affords no obvious way for the client to send data over the socket back to the server (WebSockets being a bidirectional protocol). -DavidMcLean]

* I'm not sure what you mean by "data sent". The "window" containing the notification message is sent. I included a sample message above to clarify that part. Essentially, when the conditions that satisfy the event (listener) are met, the markup inside the event "runs". If it creates a new window, the new window shows on top (unless "visible=false" perhaps).

* [I mean data sent ''from the server''. You have a string on the server. You want to show this string in a notification on the client. How do you do this with your <listener>s? (I'm assuming the server-side is just sending the string via an SSE, the way it normally would, so you don't need to show server-side code, just client-side.) -DavidMcLean]

* You mean dynamic messages? HTML parameters, similar to what current web servers use.

    <listener...>
      <window...>WARNING: <paramGet name="my_message"/></window>
    </listener>

* Note that we may need different "scope" options in practice. But this gives you the idea.

* [Okay, so it actually does work ''exactly'' like the existing EventSource object, modulo syntax. Cool. So that leaves us with the question… why is your way better, given it works precisely like the existing technique and the existing technique is already implemented? It takes effort to implement new stuff. -DavidMcLean]

* Markup is usually easier to remember and learn (if done well). It's one of the reasons why HTML has been successful in terms of usage and writers. And second, JavaScript often has the habit of breaking. For one, there's no name-space management such that different versions of the same library can interfere with other if you load up on widgets.

* [Why would it be easier to learn a slew of markup elements providing a broad range of functionality than a regular function API of about the same size, given the only real difference is syntax? As for JavaScript's fragility, that has historically been a problem; libraries such as jQuery significantly reduce JS breakage through client differences, however, and the namespace situation has in fact been addressed by CommonJS modules. -DavidMcLean]

* part of it is what I already said above, "easier to learn and remember", and part is back to the ol' '''standardization-versus-flexibility''' debate. I won't repeat it here.

* [How so? I've mentioned neither topic.]

* You asked why not JS instead of markup. The JS version is not intuitive. Somebody may accidentally write:

        es.addEventListener("foo", data, doSomethingWith(data));  // example "foul-up-38"

* And it may give a cryptic message or blank results. Markup is usually better "hand holding".

* [One always needs to learn the syntax of a language. You seem to be championing XML's general ''lack'' of syntax in making it more intuitive; if you're going to go down that road, just skip to the logical conclusion and use EssExpressions for everything ever. I recall you'd decided that LispLacksVisualCues and related issues, however, which will also affect your HTML replacement/extension. Also, it's hardly impossible to write incorrect XML by accident. Remember that XML has self-closing elements too; suppose someone made this error?]

	<listener name="message"
		<window>URGENT: <paramGet name="my_message" /></window>
	/>

* [This is pretty much equivalent to the erroneous JavaScript you've shown above. Using XML-based syntax doesn't magically make it impossible to make an error like the above. -DavidMcLean]

* If it doesn't work, it's pretty easy to spot why. (And XML editors will generally indicate a flaw via color coding. Your markup has a syntax error, while the original has a conceptual error.) In general, markup is more declarative and attribute-driven, and thus more intuitive and easy to use for developers who jump around between a lot of languages and tools such that they cannot stop to master any one. It's closer to '''paint-by-numbers''': just fill in the attributes with the values you want. Your approach requires more understanding of HOW it works, especially if something goes wrong. I agree some flexibility is lost in the process (although potentially still there behind the DOM or equiv.).

** [Your JavaScript snippet doesn't have a "conceptual error". It has a syntax error, just like the XML snippet, because it's syntactically invalid to write function(data) without giving a function body with {} in JavaScript. Hence, I consider my syntactically-invalid example of XML comparable to your syntactically-invalid example of JavaScript. A decent editor will indicate a syntax error with highlighting for ''any'' language, not just XML. -DavidMcLean]

** I changed the "foul-up-38" example.

** [The new version gives a ReferenceError for the undefined 'data' variable, which also may be indicated automatically by a competent editor. Both versions are, however, still actually ''syntax errors'' on the part of the programmer, even if the compiler doesn't recognise them that way; a programmer does (obviously) need to learn a language's basic syntax before coding in it, and this is true for any language. -DavidMcLean]

** I'd consider a "missing reference error" a more indirect error than a syntax error. HTML/XML simply doesn't let you nest statements (brackets), with the possible exception of comments. But I agree it's a relatively minor difference in terms of mistakes.

** [Actually, XML ''requires'' you to nest "statements". Every XML element takes a block (with the exception of self-closing elements), which contains other, nested XML elements. -DavidMcLean]

** Not the kind of "nesting" I was talking about.

** [I know. You were referring to nesting statements ''in brackets''. However, XML, as a serialised tree, would represent nested bracketed expressions using nested XML elements. Therefore, nesting XML elements actually ''is'' the same kind of nesting you were talking about. -DavidMcLean]

* As far as markup versus ess-expressions, that's another debate. Markup is the de-facto standard right now for semi-declarative coding.

* [There's no actual semantic difference between XML and EssExpressions, so there's no point in starting a debate over them. I brought up EssExpressions because using XML to design languages suffers from the same problems using EssExpressions to design languages does (since the two are semantically equal), including that of LispLacksVisualCues, which I know is an issue you've raised previously. (I think you've also tied LimitsOfHierarchies into the topic?) -DavidMcLean]

* It's not just about syntax, markup languages tend to be '''attribute-driven''' while in practice Lisp is a combo of attribute-driven and behavior-driven. Attribute-driven is easier to learn and remember for the average developer in my opinion because considering the impact of attributes is generally '''quicker to grok''' than behavioral composition for a given task. It's essentially a WetWare argument. E.E. interfaces could be more attribute-driven, but currently they are not and markup is the de-facto standard. If the de-facto standard and attribute nature changes to E.E., then I'll reconsider. Markup also makes it easier to track the end of a block (X, End-X matching style, or "x" and "/x"). If you misplace a parenthesis in E.E., it can be a bear to find the repair spot. X/End-X has some insurance against this via redundancy.

* [XML and EssExpressions are both mechanisms for serialising trees, for which the only actual difference is syntax. Both are thus equally capable of representing "attribute-driven" interfaces; EssExpressions have been seen to produce more "behaviour-driven" interfaces because Lisp is an actual programming language, while XML usually isn't. There's nothing fundamentally stopping EssExpressions from being interpreted as, say, an attribute-controlled document tree (as in HTML) rather than as an imperative language's syntax tree, though. I find the suggestion that developers have trouble understanding behavioural composition rather odd, because developers must work with actual programming languages most of the time and the vast majority of those are still mostly imperative and hence behaviourally-based. -DavidMcLean]

* [And an XML-based language is ''still'' going to suffer from problems such as LispLacksVisualCues. The reason LispLacksVisualCues is because none of its syntax is tied to semantics, since practically every operation is handled through (f x) function application. XML, being a similarly generic way to serialise trees, doesn't afford any domain-specific syntax to alleviate this issue. XML's attributes do provide a ''slight'' delineation to the language, but they only really exist as a way to curtail XML's verbosity, as a stand-in for adding more child elements, and still don't offer any real semantics. -DavidMcLean]

* But one is NOT doing things in many different ways in XML. No loops, no recursion, and no explicit branching. Thus, there are less possibilities one has to consider when reading the code. If you know every machine coming into your pawn & repair shop is a calculator, then you don't have to analyze it to see if it's a typewriter, or a toaster, or a phone, or a money cleaner, or postage device, etc. The reader sees it's XML and knows it's by and large attribute-driven. Markup/XML is not perfect, but it has a better shot of taming the GUI world than the alternatives.

* Also, repeating "function" and the "double nesting" of "})" is kind of awkward and a '''syntax smell'''. If we are going to rely on "roll your own block statements" heavily for our GUI event management, then I'd hope we'd come up with something more natural to that purpose. It should be somehow simplified to something more like:

        myCustomblock (p1, p2, etc.) {....}

* so that we could type something like the following just like an IF or WHILE block in C-style languages:

	es.addEventListener("foo") {
		doSomethingWith(data);
	}

* A sufficient DomainSpecificLanguage should ideally pretty much hide the fact that HOF's are being used (under the hood). Let's WorkBackwardFromPseudoCode if we are going to search out the ideal GUI language/notation and not be mentally limited in our vision by our familiar languages/syntax. You should try not to be boxed in by JavaScript and I should try not to be boxed in by markup, and maybe we can meet somewhere in the middle with a better abstraction/notation than either provides.

* [I'll freely admit I'm not a fan of JavaScript's function syntax either. I am however a ''huge'' fan of CoffeeScript's ( http://coffeescript.org ) function syntax. I haven't previously mentioned it since you'd be more familiar with regular JavaScript, but I think it addresses those syntactic inconveniences wonderfully. -DavidMcLean]

	es.addEventListener "foo", (data) ->
		doSomethingWith data

* [It's hard to get a simpler syntax than that without doing silly things to the argument evaluation rules; given LispMacros or runtime controlled argument evaluation (as in IoLanguage), you can hack in a way for functions such as addEventListener to magic non-function arguments into being functions. However, you've then hidden away details of evaluation inside the function called, and calling that function no longer works like calling any other function in the language. When the function syntax is so short, hiding it away isn't worth the inconsistency that results. -DavidMcLean]

* [Note that the syntax above, and CoffeeScript in general, is indentation-sensitive like Python. I like that. Not everyone does. If you prefer braces, you may be interested to know that Ruby's function syntax looks almost exactly like your example of custom block structures:]

	es.addEventListener("foo") {|data|
		doSomethingWith(data)
	}

* [It does require that you specify a variable name, shown in the example as |data|, but this is better than not specifying one, since it's possible for a generic variable name like "data" to collide with existing variables and the user should be given flexibility in specifying names. (Note that Ruby blocks are often written using the keywords do and end, instead of with braces. The two syntaxes are equivalent.) -DavidMcLean]

----
''"No loops, no recursion, and no explicit branching. Thus, there are less possibilities one has to consider when reading the code."''

Unless you're talking about something like Prolog, what you describe -- no loops, no recursion, and no explicit branching -- is epically useless.  Innumerable attempts to take the programming out of programming or create programming for non-programmers either results in (a) a new programming language that soon gets used only by programmers for programming -- a good example is COBOL, originally intended for non-programmers to write programs; or (b) crap.

''I believe the WWW has been highly successful from a usage/popularity perspective largely because the declarative nature of HTML made "getting started and useable" relatively easy. But like any highly popular product, it starts to be used beyond its original design intent, and becomes a tweak-filled mess. We need a GUI-friendly markup to replace it. Most GUI activity is known and "package-able" into a mostly declarative attribute-driven fashion, such as markup so that GUI's are not esoteric or a pain-in-the-tush to create and change for custom and budget-conscience shops with fungible staff. The evolution of DSL over time goes toward declarative and attribute-driven, be it markup and/or RuleBuilderInterface screens.''

For getting started on Web development, we have HTML.  For interface programming, we have Javascript.  What role is your markup intended to serve?  For non-programmers, your markup appears to add complexity to what we already have.  ColdFusion tried that, and you can see how popular it is now compared to the alternatives, despite being TuringComplete.  You appear to want something that isn't even TuringComplete, resulting in a markup that's more difficult to learn than HTML for non-programmers, and less powerful than Javascript for programmers.  In short, it appears to be the worst of both worlds.  Simple declarative DSLs for rule definitions, configuration files and the like are an order of magnitude simpler than the general-purpose display functionality, and can get away with being non-TuringComplete.  TuringComplete interface scripting (e.g., Javascript) is necessary for even trivial dynamic Web applications.

* ColdFusion failed to spread because it's not "free" like Php and Dot.Net. Price is primarily what smacked it. My current organization made that determination also. (It can actually be cheaper than Dot.Net in practice for reasons I won't go into here, but it's not obvious to bean-counters.) Right now in the existing HtmlStack, markup controls the basic layout, and JS controls the middle and high-end interaction. If a decent GUI markup language existed, then it would cover both the low and middle-end; AKA, '''"commodity GUI behavior"''' (CGB). Scripting may still be needed for the more "special" stuff, and those who want cutting edge or fancy-dancy would still hire scripting/DOM experts. Commodity GUI/CRUD behavior can and should be declarativized and attributized. Especially internal apps that don't care much about fancy-dancy and cutting-edge would enjoy coverage of CGB.

* Also note that ColdFusion doesn't cover "commodity GUI behavior" very well. It failed to expand much in that direction, possibly because it would start competing with other Adobe products, such as Flash.

* ''ColdFusion was not only over-priced, it was crap.  I've rarely seen a tool that caused so much developer cursing.  In '''your opinion''' "GUI/CRUD behavior can and should be declarativied and attributized."  Fortunately, at least for the majority of it, no one agrees with you.  If they did, it would exist already.  There's been plenty of time for developers to scratch that itch -- if it existed.''

* CF invited a lot of newbies, which largely gave it a bad reputation. If you have a sample "bad app", let's see the sucker's code. And it's largely because it failed to package CGB such that everybody still had to reinvent CGB from scratch. As far as why somebody hasn't tried something with better CGB, it's largely because it's not competitive until it's largely complete, which would be a big project. OSS projects "prefer" to be organically grown from smaller useful tools. But a half-ass GUI engine/language is not competitive enough with the alternatives such as TK/Tcl, Java, Flash, VB, and HtmlStack.

* ''If you believe it so, I suggest you create it.  Perhaps it's an opportunity.''

* I'd probably have to use C/C++, which I really don't find pleasant. Some day I may try a mock-up in Tk/Tcl to at least demonstrate what "could be". I tried something kind of like that with Java Swing once, but ended up pulling my hair out. It didn't like the idea of a dynamic data structure holding references to a wide variety of widgets "types".

* See "Java Side Discussion" below.


''COBOL is not a good example because it was created around 1959 when the idea of DSL's was very new. We now have real-world test cases such as databases and HTML and email RuleBuilderInterface(s), etc. And COBOL has stood the test of time even though it uses dated language conventions. One can hardly call it a "failure".''

COBOL was (and is) a success as a programming language for professional programmers.  It was a failure as a language intended for non-programmers to do professional programming.

''True. I don't dispute that. But it doesn't change the nature of my case for mostly markup.''

There is no "case for mostly markup".  As above:  Your markup is more difficult to learn than HTML for non-programmers, and less powerful than Javascript for programmers.  In short, it appears to be the worst of both worlds.  Another ColdFusion the world does not need.

''Strawman arguments. Non-programmers are not the target audience. And CF is not "it" for reasons already given. CF added IF's, loops, etc. to HTML, but did very little to address lack of CGB. That's not what I have in mind. '''CF added TuringComplete, not CGB, which is "fixing" the wrong thing.''' ''

[If non-programmers aren't the target audience, why would you expect actual programmers to use this markup language, when they'll almost always prefer to use the more expressive and powerful JavaScript? -DavidMcLean]

How do you conclude that? For one, it's not just programmers who decide what's used. The organization also has a say. And again, the flexibility camp lost in the GreatLispWar. Semi-domain-specific languages seem to be what the industry wants. We've been over this already. Also, for smaller or decentralized shops, the IT person may do multiple tasks and programming may not be their strongest skill such that advanced techniques may confuse them.

* [There never really ''was'' a GreatLispWar. Lisp's past lack of use in the mainstream is very much tied to the AiWinter, and more recent developments such as ClojureLanguage are quite popular even in business. You claim on that page that ideas from Lisp when introduced to other languages fail to "stick"; this is demonstrably false, given the widespread use of DynamicTyping, automatic memory management (garbage collection), and yes, even higher-order functions. -DavidMcLean]

* I disagree. Lisp and similar languages have had plenty of chances to penetrate the general development space for at least two decades. (The original Lisp was invented around 1960, so technically it's had 50+ years to catch on.) Is Clojure significantly different than past Lisp dialects to allow it to do with Lisp hasn't?  (I don't know what dynamicness has to do with it.)

* ["(I don't know what dynamicness has to do with it.)" I assume you refer to my mention of DynamicTyping. It's relevant because Lisp was the first language to feature dynamic typing, and that idea has ''absolutely'' stuck to other languages. Clojure has a bunch of powerful tools for stuff like concurrency built-in, but I think the main reason it works so well in business is that it runs on the JVM and therefore can easily interop with Java libraries; there're rather a lot of Java libraries for business stuff, you know. -DavidMcLean]

* I'd credit the original BASIC for spreading dynamicness at least as much as Lisp. Interactive teletype machines generally pushed the idea, and they started becoming common around the mid/late 1960's. Actually, machine language is the original dynamic language: everything in RAM was addressable and changeable at first. Compilers simply reflected the hardware and UI technology of the day, which wasn't ready for interaction.

* [Then you'd be miscrediting. The original Dartmouth BASIC had only numeric variables, and later dialects that added strings required variable types to be declared. (String variables needed a $ suffix.) -DavidMcLean]

* If I am not mistaken, strings were added shortly after the introduction. And being a dynamic language is not necessarily the same as having dynamic types. "Dynamic declaration" is perhaps the key. Changing a variable's type after it's declared is a less important characteristic of dynamicness.

* [Okay, but I didn't actually claim Lisp invented "dynamicness". I said it invented DynamicTyping, which it did. -DavidMcLean]

* No, machine language did, per above.

* [No. Machine language isn't DynamicallyTyped. It's either using fixed operators, like an ADD operator that'll only work on integers in a specific format, or it directly addresses raw memory and therefore is ''un''typed. -DavidMcLean]

* Untyped and dynamically typed are very similar. It's right back to the "side tag" discussion, eh? :-)

* [In what universe is untyped machine language ''anything like'' a dynamically-typed language?]

* Tag-free languages generally treat variables as a string of bytes, more or less. There is no type "tag". This is fairly similar to assembler: how you interpret the bytes is up to your code. The modern versions simply keep better track of the end position of the byte sequence "list" (and "parse as needed" rather than assume raw number types).

* [There is no language with any type system that treats all values as a string of bytes. There are languages that allow ''some'' values to be treated as a string, even when they aren't, such as PerlLanguage; this effectively works by having operators coerce values to appropriate types, however, and Perl still has regular dynamic types on values. Assembly and machine language ''don't have'' a type system, so comparing them to a dynamic type system isn't reasonable. -DavidMcLean]

* I'm not sure what you mean by "coerce". "Interpret as", yes, which is basically what I said. Related: ColdFusionLanguageTypeSystem. And please keep separate the idea of language implementation (interpreter) versus language "design" or "definition".

* [Yes, of course one must keep language implementation details separate from language design. I've not intermingled the two concepts, though, as far as I know; the way Perl coerces values to different types is part of the language specification. Perl isn't exactly the best example of a dynamically-typed language anyway, though, mostly because of sigils. Python and Ruby (and JavaScript) are much more representative of dynamic typing. This whole thread of conversation is a digression, anyway: Machine language is untyped and has no type system, while a dynamically-typed language has a type system (a dynamic one), so they're not comparable. -DavidMcLean]

* I disagree with your characterization of "type system", but yes we are digressing. "Types" have been quite the LaynesLaw magnet around here. (Note that most programmers don't really notice the diff between a type-free typing system and a tag-based dynamic one. The differences tend to be somewhat subtle such as to go mostly unnoticed as a distinguishing characteristic. But it would be interesting to know which was the first dynamic-type-tag language.)

* [It's Lisp. Like I said, beginning this conversation, Lisp is the first language with DynamicTyping. -DavidMcLean]

* Arrrg.

''How do you conclude that "what the industry wants" is a less-powerful, less expressive, more XML alternative to Javascript?''

Observation. HTML was "catchy", especially in terms of "part time programmers". My brother, a non-programming graphics designer even picked up HTML. JS/DOM just turns most people grey except those who dive in and make it their specialty. You have a right to disagree, and I know you will.

[You said above that your language isn't targeted at non-programmers. Now you're saying it's desirable because it'll appeal to non-programmers. This is flawed in that your language is significantly more complex than HTML and therefore isn't going to appeal nearly as much to non-programmers; it's also flawed in that, if your language ''isn't'' targeted at non-programmers, it offers no advantage to actual programmers over JavaScript. JS is already ''tremendously'' popular for programmers, being a powerful, expressive, generally competent programming language. -DavidMcLean]

JS is "popular" because there are no realistic alternatives for the client side of the browser. It's forced up our ass via the cruel twists of history. It's popular like QWERTY is "popular". And yes, it is more complex than HTML. However, it would be more appealing than the JS/DOM. Your comparisons are off. The important comparison is GUI-centric markup versus the HtmlStack with JS, and ''not'' HTML versus GUI markup. Most programmers I know don't have any special love for JS other than it pays the bills (and turns them grey). Granted, if the DOM/browser model was better, JS wouldn't suck as much for UI usage. But, if we had a decent GUI markup, we wouldn't need scripting very often because CGB could be handled largely via the markup (and/or server-side). Why hand-program shit that should be in attributes? It makes assembly look pleasant in comparison. If you disagree, so be it. I call it as I see it.

[I'm only comparing it with HTML because you are, equating your language with HTML in terms of its "catchy" nature. Because your language is, as you've said, more complex than HTML, it's not good for non-programmers. ''Why'' would your markup language be more appealing than JavaScript, for actual programmers, considering that it's significantly less powerful? (If you think JS is only popular because it's the only real option for client-side code, how would you explain server-side JavaScript solutions, like NodeJs?) -DavidMcLean]

Nobody I know uses NodeJs, and it's mostly used for static pages, not dynamic ones. And "non-programmer" is not the main issue. Markup (done reasonably well) is generally easier to learn, use, and remember, at least for the short to medium term. And "more flexible" is not the primary goal for reasons I've given many times. You are a confederate state in the GreatLispWar. Give it up.

[The GreatLispWar doesn't exist. NodeJs is almost solely used for dynamic pages, and it doesn't matter whether anyone you know uses it. The very fact that not only it but several server-side JavaScript platforms exist is indicative of JavaScript being popular for reasons other than client lock-in. -DavidMcLean]

* We'll LetTheReaderDecide if JS-based servers are The In Thing. And if we had a markup that handled CGB we wouldn't need to micromanage so many events in code, only a small subset.

* [It's irrelevant whether they're the In Thing. The fact that they ''exist at all'' implies that JS is popular for reasons that aren't simply client lock-in; if JS were only popular for client lock-in reasons, no one would put effort into developing server platforms based on it. -DavidMcLean]

** JS is reasonably competitive with the likes of Python and PHP. If you have to know it on the client side, then it makes sense to leverage that familiarity on the server side as well. The issue is how to best specify the GUI's and CGB, not which language to use on the server.

** [Sure, but I'm not arguing about what language you'd want to use on the server. I'm just arguing that JavaScript is ''actually popular'' on its own merits, not just "popular" because it's the only viable choice on the client. -DavidMcLean]

** I have to disagree. I don't see a lot of love of JavaScript (in browsers) floating around. Most, including me, would prefer a strong-typed/compiled language for "base" GUI libraries. Scripting languages are fine for app-level gluing or handling certain app events/tasks, but not SystemsSoftware. I'm a big fan of scripting, but there are places where it doesn't belong.

** [… okay, but I didn't claim JavaScript should be used for building SystemsSoftware, nor that there's obvious love for it in browsers. I said it's popular on its own merits, and this is demonstrated through how popular NodeJs is for server-side: The server's an environment where you're not forced to use JavaScript, yet it's liked enough that it's chosen as a server-side language anyway. Writing server-side application code isn't the same thing or even related to writing SystemsSoftware; JS isn't going to be that great at the latter, being dynamically and weakly typed and also interpreted, but it's splendid at the former. -DavidMcLean]

** If one has to survive mastering client-side JS because the situation forces it upon you, then many figure they might as well leverage that knowledge on the server side. After giving birth to an elephant, you figure you might as well raise it now that it's out.


* [Also, you don't ''need'' to micromanage events for implementing common GUI features in JS. Use an interface library such as jQuery UI http://jqueryui.com/ , which provides a slew of widgets and common interactions out of the box. You'd only need as many events as you'd need to implement the same interface with any other framework. -DavidMcLean]

** Such libraries are ugly and unintuitive to most compared to what a GUI markup could be.

** [jQuery UI has a reasonably appealing default theme and is totally themable for each site, so it's hardly "ugly". You're entitled to find it unintuitive, though. -DavidMcLean]

** It's probably a subjective thing. In my estimate and experience, XML is better suited to the "typical" WetWare of the IT population for something fairly heterogeneous and that can largely be specified in a declarative, attribute-driven way and is to be intermixed or used with a verity of app languages. JS and cousins don't do that so well. With the JS style, some blocks or units have curly braces, some square braces, some parenthesis, some start with lamda's, some don't, and the rhyme and reason is '''mostly related to the internal implementation''', not a description of what was wanted. And it doesn't do the UniversalStatement syntactically well, or has too many representative possibilities. '''There are too many ways to specify the same thing, usually dictated by implementation, NOT semantics.''' Good XML interfaces are designed around semantics and not implementation. One should not even think about the implementation when designing an interface. (The practical reality is that implementation cannot always be ignored, but should not be the primary or original driver.)

** [Which functions' APIs in JavaScript, in your opinion, are "dictated by implementation, not semantics"? Moreover, if you believe the API designs are dictated more by implementation than semantic, what prevents simply writing a library which wraps those APIs in a more semantically-driven one? -DavidMcLean]

** I'll provide examples later. If you can demonstrate a library that wraps it nicely, I'd be glad to take a look. However, I doubt JS's syntax is up to the task, largely because it lacks native named parameters.

** [A library that wraps ''what'' nicely? I'm going to need examples of what you're talking about before I can provide any libraries to solve it. As for named parameters, it's true JavaScript doesn't have ''actual'' named parameters, but it does have object literals, which are used broadly as a way to emulate named parameters. (In CoffeeScript, the combination of named-params-as-objects and its own implicit object feature leave the language with extremely effective "named parameters".) For that matter, how would the absence of named parameters lead interfaces to be dictated by implementation, rather than semantics? The order of positional parameters isn't an implementation detail; it's solely a property of the interface and may be chosen arbitrarily during development, preferably as the order that best suits the interface's semantics. -DavidMcLean]


[As for markup… why would it be easier to learn, use, and remember a reasonably complete set of XML elements for specifying GUI behaviour than a set of functions of the same size? -DavidMcLean]

I don't know exactly why, it just is. I'll have to ponder the WetWare reasons to explain better. Part if is '''named parameters, which JS lacks'''. Part of it is simpler syntax. JS provides too many different ways to specify/emulate attributes, for example. It has square brackets, curly brackets, parenthesis, and so forth and one has to remember where to use which. (It can learn a lesson or two from EssExpressions perhaps). Markup enforces more consistency for that. Developers/designers could have used only JS to talk to the DOM or a wrapper around DOM to make pages all these years. However, they have been using mostly HTML as one can see by doing a View Source. What's your explanation of that?

[The explanation is that, as the name implies, HTML is a markup language. Its purpose is to mark up documents with semantics, and it's not ''too'' terrible at doing that, so it hasn't needed to be phased out or anything. JavaScript's a programming language. It's not designed to mark up documents, because it's a programming language. Use the right tool for the job, right? HTML is the right tool for marking up a Web document, and JavaScript is the right tool for interface scripting.]

* The right tool for the CGB and setup job is a markup language.

* [Why?]

* See above near "There are too many ways to specify the same thing, usually dictated by implementation".

[Your proposal is that HTML should be extended such that it handles loads of stuff JavaScript already does, but HTML is designed to mark up documents, and things like "receiving events from the server and flashing up a notification bubble accordingly" are not document-markup issues (so you'd be mixing unrelated concerns, I'm afraid). Nonetheless, you do seem to have a point in claiming that devs have mostly been using HTML to make pages rather than manipulating the DOM with JS.]

* "XML-like" if you don't like the word "markup". This seems to be a wording issue, not a tool design issue.

* [The M in XML also stands for "markup". ;) -DavidMcLean]

* Well, we don't have to limit it to static documents. GuiMarkupProposal proposes a way to dynamically update an XML "tree".

[''However'', people actually haven't necessarily been using mostly HTML to build Web pages, regardless of what you see in View Source. Consider the fact that http://daringfireball.net/projects/markdown/ http://docutils.sourceforge.net/rst.html http://haml.info/ and http://jade-lang.com/ exist, among many other markup and templating languages (some more popular than others). All of these generate output as standard HTML; none of them require the developer to use actual HTML directly. -DavidMcLean]

* It's often the starting point and the app-language-to-GUI interface mechanism. It's often the case that a mockup is created in HMTL, and then that is used as the template, reference, and/or framework to hook the dynamic parts into. In many cases non-programming web designers create the mockup using a combo of Dreamweaver and hand-editing of the HTML. CGB could also be specified this way, and then refined for production by the programmer, replacing filler widgets and actions with variables and loop wrappers (repeaters) that give it dynamicy. I see no reason why a non-programming web designer can't create more full-featured mockups with CGB also, not just layout because it's CGB that most know fairly well. This would free the developer to focus more on technology and less on GUI interaction design. And gives the customer a better mockup for earlier feedback. If somebody wants to create a short-hand for a GUI markup language like wiki code or the gizmos you list, so be it. Everybody has their own favorite way. But we need a shared standard to serve as the '''Lingua Franca of GUI's and CGB''' similar to how HTML is for for the layout and linking side, and JS is not the best fit.

* [Would something like AngularJS http://angularjs.org be, to you, a better fit? Or does its being tied to JavaScript automatically make it not work for this? -DavidMcLean]

* It's like half markup and half something odd. I'd suggest not mixing. CSS made the mistake of not using a markup style, inventing yet another goofy syntax. Let's not make that mistake again.

* [AngularJS uses as close to regular HTML markup as is practical for the sort of language you're suggesting.]

* Why does it need to deviate at all? Why make it 70% markup and 30% some foreign syntax?

* [I assume the "non-markup" bit you refer to is the use of {{ }} for binding variables. This is necessary because it's impossible to use regular XML to bind variables in all the places you might need to bind variables: If you use a <paramGet /> element, as you suggested above, then you can only bind variables inside elements' blocks and not in attributes. You'd need to extend XML with ''some'' sort of globally-accessible syntax for variables in any such language. You don't necessarily need to use {{ }} as the syntax, but that's already well-recognised from its use in templating languages and so is a pretty good choice. -DavidMcLean]

* The "solution" is usage specific. We don't really need variables in the traditional sense in most cases, largely because most markup or the DOM settings are generated as needed, and then given attribute changed as needed. "paramGet" was intended as a way to embed text (output) with a URL parameter, not as an attribute modifier. Even though it's not a common need, we could have something similar to the "update" blocks in GuiMarkupProposal to translate URL parameters into markup attribute changes:

   <!-- change alignment of div "div123" based on URL or POST parameter -->
   <task name="ziig">
      <setAttrib namespace="foo" targname="div123" attrib="align" trim="yes">
           <paramGet name="new_align">
      </setAttrib>
   </task>

[Why would the method of binding variables within this markup language be "usage specific"? Don't we want consistency? How do URL parameters relate to this subject, incidentally? I first brought up the question of variable-referencing in terms of data sent ''from server to client'', and URL parameters only actually apply for a request ''from client to server'' (because the server doesn't make GET requests (or ''any'' requests) to the client). -DavidMcLean]

* We don't necessarily want to follow other languages' "bind" traditions. We are not going to need as many variables if CGB is handled declaratively, or at least behind the scenes inside the engine instead of micromanaging stuff with explicitly scripting. I'm not quite following you here. What specific scenario do you have in mind? Before we focus on how to "bind" variables, let's explore why we would want to "bind" them.

* [Here's a snippet of AngularJS, from its homepage:]

	<td><a href="{{project.site}}" target="_blank">{{project.name}}</a></td>

* [Note that it's necessary to access variables (in this case, a site URL and that site's name) both in attribute and element contexts. This is hardly a complex scenario, so the markup to handle it shouldn't be much more complex than that given above. How does your markup language handle a simple setup like the above? -DavidMcLean]

* Most of the time the entire link ("td", "a" tag, etc.) is dynamically generated at the server when the page is requested. However, if we need to change them for some reason after the page is generated or displayed, then the "delta" approach can be used (described below). It would be best to name a SPAN for text replacement part.

* [So you're required to give names to all regions you might want to update? What if, as in the above example, they're dynamically-generated table rows? There could be dozens or hundreds. Do we really want to have to name them? -DavidMcLean]

* No. But, certain activities are easier when you do. Note that every object would be given a unique temp object ID by the client. This can also be used to reference items.


[Also, your markup language is intended to be declarative, right? How can it be when it has imperative change-state constructs like <setAttrib>? In AngularJS, a {{ }} binding will update automatically, without needing any imperative construct, whenever the thing it's bound to changes; this seems much more declarative a design, at least to me. -DavidMcLean]

* I'm okay with some imperativeness. If we click a button that does 3 typical GUI behaviors, such as open (activate) a window/dialog, change the value in a given input box, and send a message to the server, then we can list and code for those 3 behaviors all in the markup.

 <input type="button" value="Do 3 things" onclick="event01">
 ...
 <task name="event01">
   <window name="w07" visible="true">  <!-- activate existing window -->
   <input name="mybox" value="New value is 83672">  <!-- change box value -->
   <sendContent document="my_doc_2" form="my_form_A">
 </task>

 <!-- Alternative for middle one -->
 <!-- Here is appending to "mybox" instead of replacing -->
 <setAttrib targname="mybox" attrib="value" trim="true">
   <getAttrib targname="mybox" attrib="value"/> Appended text 83762 here
 </setAttrib>

* Now, some scripting (server and/or client-side) may still be needed, but we want the markup to handle the common/typical GUI activity to reduce the need to app-code GUI activity. The 3 activities above are "commodity" behaviors of GUI's such that it's silly to have to app-codify them. App code should be doing computations, not shuffling GUI shit around.

* [You haven't escaped from shuffling GUI stuff in app code, because your markup is still effectively app code, represented in XML. Given a decent library such as jQuery, the JavaScript to do exactly the same stuff will quite possibly be ''shorter''. (The jQuery version of your <setAttrib> snippet is definitely much shorter!) How is your method better? -DavidMcLean]

* There's more to measure than just short-ness. For one, positional parameters generally result in "shorter" code. But it's often not easier to read (although depends on the situation). Brevity is but one of many factors to consider. And, in practice "setAttrib" would not be used very often.

* [I chose to specify that the above code would be shorter in jQuery because it's an objective metric. I'd have loved to say it'd be ''clearer'' code, too, but since that's subjective I know you won't accept it.]

** But do you agree that "clearer" and "easy to learn" and "easy to remember" are important factors even if they perhaps differ per person?

** [Of course. I just don't believe a bunch of XML elements are going to be any clearer, easier to learn, or easier to remember than a bunch of functions. -DavidMcLean]

** My assessment differs.

* [Setting attributes is an extremely common aspect of interacting with a document tree in scripting; why would <setAttrib> be used so rarely? -DavidMcLean]

* Most of the time the delta approach would be used to change a given DOM, as described in GuiMarkupProposal. (A given api set or custom app-specific wrappers may be created to simplify programming for a specific task or style.) I expect most of the change requests would come from the server.

* [Ah. The main issue I have with that is one of separation of concerns: In a given "markup stream", you'll have "active" XML elements with imperative behaviour, mingled together with regular document-structure-specifying XML elements. It's non-obvious from inspection which of these have behaviour, since they all share identical syntax and, as far as I can tell from your proposal, can appear adjacently. How will you delineate the two? -DavidMcLean]

* I'm not understanding the question.

	<listener name="new_message">
		<li><paramGet name="messagecontent" /></li>
	</listener>
	<section name="content">
		<li>message content</li>
	</section>

* [Under your markup language, <listener> and <section> have very different semantics: One creates an event listener and accepts imperative markup to run on the events, while the other just defines document structure. Yet, as you can see from the above example, they look almost identical. How will you distinguish between such semantically-different elements? -DavidMcLean]

* Sorry, I'm still not understanding your complaint. Blocks look like blocks in JS also. Whether we should or shouldn't tie an event/listener to a document section/segment is an interesting philosophical and usage debate, but I don't see how it "damages" the idea of markup for GUI's.

* [Yes, blocks look like blocks in JavaScript. However, for the most part we don't use JavaScript's blocks purely to specify document structure, as in the <section> tag example. JS doesn't conflate document structure specification with any of its imperative-semantics calls. Your markup proposal does. (I think this would be totally fine if your markup language were ''actually declarative'' and didn't have any imperative semantics, by the way.) -DavidMcLean]

* I don't believe basic sequences of actions ruin the spirit of markup. An HTML statement like this:

    <a href="www.foo.com" target="_blank">Click me</a>

* does two things: opens a new window, and opens a hyperlink directed at the new window. If I made two XML statements that did the same two things in a sequence, you are implying it is now something fundamentally different.  It's not. Why should we limit hyperlink actions to one and only one? '''What is so magic about one action?'''

* [An HTML statement like that does one thing: It specifies a link should be at that point in the document structure. The link itself also does only one thing when activated, which is opening the address "www.foo.com". I don't have a problem with sequencing actions; I do think there may be a problem with sequenced actions being indistinguishable from document-structure specifications. -DavidMcLean]

* "Does only one thing" is a matter of debate. How are you measuring "one-ness"? Even if it was "one", you still haven't answered the question about why we should limit it to one action.

** [I don't think we need to limit action-triggering stuff to trigger only one action. I think we need a way to distinguish a sequence of actions from simple siblings in the document structure, since they have significantly different semantics. -DavidMcLean]
** HTML has some (limited) "actions", and nobody I know has complained about that. I'm not sure what kind of WetWare problem you are trying to solve. Further, the distinction between the two may fuzzy such that forcing a hard border may cause some ugly duplication of concepts across languages.
** [What "actions" does HTML have, apart from <script> tags? -DavidMcLean]
** You'll probably dispute they are "actions", but somewhere here I gave the example of a hyperlink opening a new window (target="_blank") and "telling" that window which URL to go to. I see no reason why the same hyperlink couldn't open two windows without custom scripting. The quantity of one is an arbitrary limit. Why would it be a non-action if it's one but be re-classified as an "action" if it's 3 windows? I don't want to get into a definition fight over "action".
** HTML also has submit buttons.
** [Ah. See, the thing is that all those HTML elements actually have effectively the same semantics. Putting an <a> tag in your HTML means only that an <a> element is added to the document structure, and the stuff inside the <a> tag in the HTML appears inside the <a> element when the document's displayed. Putting a <form> tag in your HTML simply adds a <form> element to the document, too, and the stuff inside the <form> tag just shows up inside the <form> element. Generally, tags and their contents are always interpreted in the same general way in HTML (with the notable exceptions of <style> and <script> tags, but CSS and JS embedded directly in the HTML aren't really recommended anyway). If you added a <listener> tag, or a <task> tag, or whatever other tags you've got planned, they wouldn't work that way: The contents of such a tag don't just end up as document structure, because they're imperative commands. <listener> effectively changes the rules for nested HTML tags, despite looking exactly like a normal HTML tag. And that's my issue. -DavidMcLean]
** It still seems a minor complaint to me. Think of it this way: when you have multiple sub-elements, you split out the "details". Thus, a UL tag will have potentially multiple LI's inside it. If we want a hyperlink to open multiple pages/documents instead of just one, then we'd have to do the same thing: put the list of windows to open within the A tag set. And in the name of re-use, why not allow referring to groups of such statements by name (task name) instead of require nesting? Although such is not common in HTML itself, it is common in conjunction with style-sheets, such as a CLASS reference. Thus, it's using concepts not actually foreign to HTML + CSS, it just uses such patterns to a higher degree, and uses markup instead of CSS for shared references (which should have been done in the first place).
** [Well, yes, you do have to "split out the details". That's what XML requires, by design. However, splitting out details that don't amount to "these are child elements of that other element" is confusing the semantics of HTML. It might be reasonable ''if'' there's exactly one element that's allowed to change nesting semantics, though. Some sort of <task> or <block> element, I suppose? Since the change in semantics is isolated to one particular element, the confusion is lessened; all one has to remember is that that one element works insanely. ;)]

*** I'm not sure what you mean. Do you mean that named references are too confusing compared the nesting? Stylesheets do it, so why is it "bad" if markup also/instead does it?
*** [No, I mean elements where nesting doesn't mean "these elements that are nested are child elements" are more confusing than other elements, because it's inconsistent. -DavidMcLean]
*** You mean the children are not actually visual elements? That's a minor distinction. If something needs a one-to-many relationship in XML, then you nest elements. 
*** [It's a big distinction. You're advocating the introduction of not one but many elements that drop you out of normal HTML into an imperative language with extremely different semantics. Despite this, it's nontrivial to delineate visually when normal declarative HTML is being used and when your imperative offshoot is. Implicit semantics are confusing. -DavidMcLean]
*** Sorry, but I am still not understanding your complaint. HTML already has imperative ideas in it. Expanding it won't kill kittens.
*** [Just <script> tags with embedded JavaScript and event-attributes like onclick=. Using either isn't recommended practice. -DavidMcLean]
*** I'd have to compare to the alternatives to make a judgement on "best practice". Also, I consider hyperlinks imperative, although will agree the distinction between imperative and declarative can be blurry.
*** [The alternatives are "put your scripts in separate files where possible" and "register events using jQuery (or the built-in DOM manip functions, but jQuery is usually clearer)", respectively. Both are recommended for much the same reason: Littering JavaScript code through your HTML markup is mixing unrelated concerns. -DavidMcLean]
*** "Unrelated concerns"? Why should I want the button clicking activity to be 80 light-years from the button spec itself? Hopping around during maintenance is a time sink. And it's not "unrelated". Related: SeparationAndGroupingAreArchaicConcepts.
*** [Web pages are in fact a different thing from traditional desktop GUIs. HTML is for specifying content, marked up semantically. JavaScript is for specifying behaviour. And never the twain shall meet. -DavidMcLean]
*** They are being intertwined; companies don't want to install desktop software. The desktop is a shrinking paradigm. And I've already made the case somewhere around here that lines are blurry between declarative and imperative that I won't repeat here.
*** [Sure, we're using the HtmlStack in place of traditional desktop GUIs. That doesn't mean we should throw away the existing specifications and separations offered by the HtmlStack, however: Content and behaviour remain different things, whether or not we're trying to make our page look like it's not a page. -DavidMcLean]


** [Also, why would you want to change CSS back into markup? Moving all the style-related information that rightly belongs in style sheets back to the document markup is a step backwards; there's a reason <font> is deprecated. -DavidMcLean]

** What do you mean by "move back"? The location would be flexible. I'm not tightening location options. And why learn and manage two different language syntaxes: markup and CSS syntax? Plus, stying with markup makes templating easier because it's the same language, as the opening shows.

** [You should learn and manage two different languages because otherwise you're mixing the unrelated concerns of document structure and presentation. -DavidMcLean]

** There are actually three concerns: 1) Document structure, 2) CGB, and 3) non-CGB. [[Text Added later]]



*** Each different "concern" should be a different language? That's an unusual viewpoint/rule. Further, there are fuzzy boundaries.

*** [Not necessarily, but even if you use XML it still wouldn't be the same thing as HTML. How do you handle selectors? A <select selector="p.class#id"> tag? What benefit would that give you over CSS? -DavidMcLean]

*** That may be a case of GreencoddsTenthRuleOfProgramming. Rather than coming up with a goofy pattern matching/query language/tool, a different approach should perhaps be considered; but I'd have to look at the situation case by case to see if something else would be a better fit.

*** [CSS is nothing like a database. And are you seriously advocating getting rid of it, when you don't even have a better approach in mind? -DavidMcLean]

*** I meant pattern matching via style-sheets. Anyhow, style-sheet overhaul is mostly another topic that I won't delve into any deeper at this time. This topic is mostly about CGB. 

**** See OverhaulingStyleSheets

*** [I know you meant pattern-matching via stylesheets. It's nothing like a database. If you're going to suggest CSS shouldn't exist, or at least that it shouldn't have that feature, you're going to need to come up with a better solution; CSS ''works'' and is extremely capable. Your solution needs to work. -DavidMcLean]


** ''CSS is essentially the minimum syntax needed to do the job whilst being easily machine parsed.  If you can't learn it in literally seconds, you shouldn't be doing Web development.''

** I'm looking to build the best tool, not make an intelligence test. Why have 2 diff languages when one would do? And machine parsing speed should be a minor comparison issue unless the diff is huge. Make the machines slave away hard, not the human. Plus now the client has to run and load two parsers instead of one.

** ''Ah, you want to build the best tool!  Why didn't you say so in the beginning?  The best tool for programmers is LISP.  The best tool for non-programmers is a programmer.''

** Right back to the topic of GreatLispWar.

** [The fictional topic of GreatLispWar, yep. -DavidMcLean]

** Your distaste is noted.

** [But see, here's the thing. What you're advocating on this page is an imperative language using XML for syntax. Like it or not, that's Lisp. You're effectively advocating Lisp, despite your strong opinions against it. -DavidMcLean]

** Well, in a rough sense, but it's '''dumbed-down Lisp''': no explicit conditionals, no loops, no recursion, and no HOF's (sorry). I don't expect app programming/scripting to go away, but rather reduced because the common/commodity gui behavior is taken care of in the GUI markup.

** [The problems with making a language that lacks such things were expounded on earlier, so I shan't repeat them. However, I am curious about something. Under your specification, one can write out a <task>-or-something-like-that element containing imperative markup code, and then one can invoke that <task> using its ID or name, right? If that's the case, don't you already have recursion in the language? -DavidMcLean]

** Don't allow such "subroutines" to call themselves. There would be an execution stack, but we wouldn't be able to execute a routine already on the stack. 

** [And that's ''not'' an arbitrary and confusing restriction because? -DavidMcLean]

** Why is it arbitrary? Recursion shouldn't be the default assumption. The goal is to cover CGB that's relatively easy and strait-forward to cover via markup and leave the rest to an app language/scripting. If you have to use recursion for something, it's not likely to be CGB. But if you can give a few relatively common scenarios/use-cases where such would be warranted, I'll revisit that stance.

** [Execution stacks can be pretty deep. If you don't allow the same procedure to appear on the execution stack ever, you're going to end up producing seriously confusing errors, especially since a procedure being called twice on the stack isn't necessarily actually an application of recursion. -DavidMcLean]

** I don't see a valid reason why it should be more than about 3 deep. Insert the part here where I yet again ask for a realistic common scenario. I agree people will occasionally do something odd, but that's true of anything. 

** And I'm not sure what you mean by the second part. Recursion doesn't have to be via the same routine. For example, in a fairly common tree traversal algorithm, there is a "processNode" and "processBranch" routine. It's still referred to as recursion even though node and branch typically alternative in the call sequence because that's how many trees are constructed.

** [Yes, that's called mutual recursion and is still recursion. There ''are'' still situations where a procedure appears twice on the stack without it being recursion, though; this code from TopOnAbstraction is one example of that: -DavidMcLean]

	[1, 2, 3].forEach(function (x) {
		[4, 5, 6].forEach(function (y) {
			print(x+y);
		});
	});
.

** Okay, but what practical actual purpose does this serve? Remember, I am NOT trying to make a general purpose XML programming language, but cover CGB. [[Note that the code example is messing up the wiki indentation for some reason.]]

** [I'm not really sure what purposes your markup serves yet, since we've only seen about three of its presumably numerous elements. -DavidMcLean]

** What do ''you'' consider CGB, and how does recursion solve a CGB problem that would be difficult to specify with non-recursive markup?

** [Hmm. How about a directory tree, like in Windows Explorer? Trees are best traversed recursively. -DavidMcLean]

** How about some pseudo-code that demonstrates how recursion can do something relatively common that non-recursive markup cannot. Obviously we don't need recursion to specify (describe) a hierarchy with markup because we have UL and OL in HTML to serve as an example.

** [I thought you wanted an example of something that I "consider CGB"? I'd expect to be able to create an Explorer-dir-tree-style hierarchy pane. How would I go about traversing its contents in your markup language, given I apparently lack recursion? -DavidMcLean]

** What's a CGB reason to traverse?

** [Commodity GUI behaviour isn't going to provide reasons for traversing a hierarchy. It's just a toolkit. Reasons for doing things are left to the actual programmers and their specific application. -DavidMcLean]

** If it's application-specific, then it's not CGB. Now whether the CGB system should ''assist'' with traversing or not is certainly an open question. It's my opinion that the DOM should not be your "master database" of tree info because it's not meant to be a database. Each "node" may potentially have data items associated with it, and these shouldn't be in the DOM unless they are related to display or CGB itself. However, this may require a MirrorModel of the tree in the app side, which is not always desirable. Under GuiMarkupProposal, a way is devised to send a "dump" of a structure (markup segment) back the app side (server or client-side app). But it would be up to the app code to parse and traverse the resulting XML. This would be typical for a user "Save" operation. 

*** [Nothing is not application-specific. Not all apps require hierarchy tree-view widgets. Not all apps require buttons, or even GUIs at all. -DavidMcLean]
*** We can potentially look at the frequency of patterns or idioms "in the wild". Of course, the issue of whether to split idioms into sub-idioms comes up and a language/tool designer has to make judgement calls. As far as recursion, we don't necessarily need it often to present and interact with hierarchies from a user perspective. But if you can present sufficient scenarios that can't be done decently some other way, I'm open to changing my mind.

** Now I suppose there could be cases where one wants to '''incrementally traverse''' a tree. But whether this is common enough to justify a dedicated feature or recursion for it is hard to say without more scenario analysis. It's not common enough by my estimation. But a "get next" operation/tag can be devised instead of using recursion for such cases anyhow. The XML "output" sequence typically follows the tree traversal order coincidentally, at least depth-first traversing, which is the most common type of tree traversal I see. Thus, get-next markup element is the same as get-next node of a tree, and thus is dual-purpose.

** [Seems reasonable. However, I'm not sure it's really worth putting effort into ''preventing'' recursion because you can't see an immediate need for it. You said it shouldn't be viewed as a default assumption, but frankly, given the way procedure calls usually work, recursion ''should'' be a default assumption. <callTask> would be documented as "calls the named task", not "calls the named task ''unless it's already been called at some point on the current execution stack''", for example. -DavidMcLean]
 
** Recursion is a feature that can be heavily abused by hackers, job securers, and mental masturbationshists, and slip-of-the-fingers. I vote to exclude it unless there's ample use. Remember, we want dumbed-down Lisp, not Lisp-as-markup.

** [But do you really want to document your <callTask> element as "calls the named task, unless that task is already on the current execution stack, and by the way here's what an execution stack is"? -DavidMcLean]

*** ''Top, why don't you create this CGB XML markup language, and demonstrate to us its marketability and/or capability?  I doubt anyone is going to build it for you.''

*** I moved replies below under "make-it-now".


** "Error: recursion is not allowed. Task 'Foo' was already called earlier upon action 'onClick' in an INPUT tag. (object ID 4724)." Accidental or sinister recursion can be even more confusing because resources fill up and the user gets an "out of memory" or "out of stack space" error without any hint of which statement(s) caused it. No recursion is the least of two evils.

** [Is… is that a runtime error? You're seriously suggesting that a) your language should prevent certain kinds of procedure calls and b) it shouldn't ''document'' the fact that it does that, instead only notifying programmers that it indeed works that way at runtime? That's so awful I shouldn't need to explain why it's so awful. -DavidMcLean]

*** When did I propose excluding it from the documentation?

*** [Implicitly, when I asked how you'd document it and you responded with only a runtime error. -DavidMcLean]

*** Most developers don't read most or all of the "official" documentation and learn by examples they get from the web or "Learn X in 7 Days" books, and trial and error. If there was an issue with lack of recursion, their first encounter with it would likely be an error message.

*** [Can you support that assertion? The official documentation is always my first port of call during development (closely followed by StackOverflow). -DavidMcLean]

*** Nope, it's just personal anecdotal observation, and so too is your counter claim.

*** [Indeed, so both arguments are worthless. -DavidMcLean]

*** I wouldn't go that far. Rather, it's just low on the EvidenceTotemPole. The main purpose of this wiki is not necessarily to give answers, but to make the reader think about issues and arguments they may not have heard before. One of the first steps of science is asking the right question.

*** [Reasonable, but I don't think "we don't need to put effort into writing the official documentation because no one reads it anyway" is a very good argument. ;) -DavidMcLean]

*** I'm not against official documentation, only saying it tends not to have a lot of impact on rank-and-file programmers except when they can't figure it out on their own or Google a fix. It may have more impact on How-To book/article authors.


** [As for recursion causing stack overflow errors, without indicating the source? There's usually a huge hint of which statement caused the overflow, because there's this thing called a stack trace that any non-terrible language will give you when there's an error such as an execution-stack overflow. -DavidMcLean]

** Above you implied that for many users, emphasis on call stacks would be confusing. Now you seem to be changing your tune. And I didn't forbid stack traces. An example error message does not imply it's the ''only'' way to debug.

** [I feel providing an in-depth explanation of call stacks as part of the fundamental <callTask> element's documentation would be confusing. Obviously one ''does'' need to document call stacks if the language's documentation is indeed complete, but it should mostly be possible to store away the detailed definitions of aspects like the call stack in "advanced" sections of the docs. (A stack trace doesn't really necessitate that the developer ''know'' it's a stack trace they're looking at, since they effectively just see a list of functions.) However, if the basic rules of <callTask> rely upon properties of the current call stack, then an explanation of call stacks must be included in <callTask>'s docs too; having to pull in content from the "advanced" docs into one of the simplest imperative elements in the language is going to lead to puzzlement. -DavidMcLean]



* Are you suggesting "indistinguishable" is ''inherent'' to markup, or just a naming convention issue? If you don't like the tag names proposed, then simply propose your own. Done. Boom! Go home and have a sandwich now.

* [It's intrinsic to markup, because of LispLacksVisualCues. You could change the syntax, but then you wouldn't be using regular XML any more. -DavidMcLean]

* It's not necessarily different for JS calls either. Further, nestedness tends to be limited in markup and it uses end-markers that mirror the block name, reducing the confusion as found in Lisp. Further, markup uses angle brackets for the statement start but equal signs for attributes, but Ess Expressions use parenthesis for both.

* [It's different for JS calls because we don't generally express document structure using JavaScript. Nestedness isn't limited; it's practically ''pandemic'' in markup. And yes, I agree that attributes versus elements provides some slight delineation between items in XML, but since there's no semantic distinction between elements and attributes the syntax variation isn't as helpful as you'd expect. -DavidMcLean]

* So you are saying having the "static" structure of the document be via markup and the imperative portion done in a completely different language provides a useful mental bifurcation to identify which "type" of code is which? But the flip-side can also be true. For example, the delta approach is natural and simple if you already know the markup language. You'd have to have a goofy MirrorModel in a different language to approach that kind of thing with JS, meaning two different syntaxes for almost the same thing. It's one of the mistakes CSS made also.

* [I don't think the document's structure and imperative manipulation of it are "almost the same thing", so conflating them so thoroughly is going to lead to confusion. That's somewhat a matter of opinion, though, so I'll let it pass. I have some technical questions, however: First, how does your delta approach work with something like this?]

	<!-- the existing document structure -->
	<ol name="posts">
		<li>a post's content here</li>
		<li>and this is another post</li>
	</ol>

	<!-- the newly added delta is below -->
	<ol name="posts">
		<li>this is a post that was just made right now</li>
	</ol>

* [Does it prepend the new <li> to the existing ones, or append it? If it prepends, what do we do if we want to append instead? -DavidMcLean]

* The default should be append to the end, like current HTML (first listed goes at the top). I believe I stated somewhere that every object gets a sequence number automatically in the internal model (unless explicitly supplied via a "sequence" attribute). If you want to change the position, then you change or supply the necessary sequence number. Although, it may be handy to have "commands" to assist with prepending lists to avoid explicit sequence number analysis. Perhaps alphabetical should also be an option. These issues would definitely play out if we support position dragging, meaning that via mouse one can change position of objects in a list or sequence. Note that we are now tickling GreencoddsTenthRuleOfProgramming.

* [I see no way this is in any way related to GreencoddsTenthRuleOfProgramming, so that's confusing. Could you provide an example of prepending items through your markup-delta mechanisms? It's a very common need, since new content almost always goes to the top. -DavidMcLean]

* The simplest approach would probably resemble:


     <li insertPosition="_top">My content</li>
* However, it's a CGB to have lists/tables that can dynamically sort (on a clicked-on column for tables, perhaps with an up/down arrow). Thus, we could instead consider piggy-backing on such sorting feature(s) with a setup similar to:

	<ol name="posts" sorttype="usa_datetime" sortdirection="descend">
		<li sortvalue="12/12/2012 10:30am">a post's content here</li>
		<li sortvalue="1/3/2013 5pm">and this is another post</li>
	</ol>
* Any new delta-added LI with a recent date-stamp will then automatically be at the top. Perhaps also consider "overflow" strategies such that if the list/table grows too large, some kind of delayed scrolling strategy would be nice, similar to Twitter for long lists. However, it may be over-kill to burden the GUI markup with such report-writer-like features.

* [Ooh, not bad. I'd argue that lazy overflow scrolling (and probably infinite scrolling too) are features that fall under commodity GUI behaviour, though, and should definitely be included in your specs. -DavidMcLean]

------

'''Java Side Discussion'''

''If you believe it so, I suggest you create [a gui markup language/demo].  Perhaps it's an opportunity.''

I'd probably have to use C/C++, which I really don't find pleasant. Some day I may try a mock-up in Tk/Tcl to at least demonstrate what "could be". I tried something kind of like that with Java Swing once, but ended up pulling my hair out. It didn't like the idea of a dynamic data structure holding references to a wide variety of widgets "types".

''The "idea of a dynamic data structure holding references to a wide variety of widget 'types'" is not only the very essence of JavaSwing, it's the very essence of practically every UI toolkit.  Arguably, it's the technical essence of user interfaces in general.  How would you avoid it?''

[Top's not saying that a dynamic data structure holding references to a wide variety of widget types is a ''bad'' thing. Nor does he wish to avoid it. He's saying such a structure is ''good'', he wanted to code that, and JavaSwing didn't support it well. I'm not really that familiar with Swing, but from my (also admittedly rudimentary) knowledge of Java in general I do see how it's kind of complicated to build a data structure holding multiple widget types, at least without just casting them all to Object or something like that. -DavidMcLean]

''I think he's saying he didn't like it.  Specifically, "'''I didn't like''' the idea of a dynamic data structure holding references to a wide variety of widgets".  JavaSwing supports it trivially.  All Swing widgets (and user-defined derivations) are inherited from JComponent, which is trivially contained.  Java supports generics, too.''

[But he didn't say that, silly. He says "'''it''' didn't like the idea", presumably referring either to JavaSwing or Java itself. I think the meaning is that, using Swing merely as a base, Top tried to build a totally different GUI engine, including building his ''own'' data structure containing references to his own widget types.]

''D'oh! *thump*  Sure enough.  (I really should up the font size from my default "I can display the entire Internet in 1920x1600".)  You're right, but as a result his comment makes little sense.  JavaSwing is built on '''precisely''' the idea of a "dynamic data structure holding references to a wide variety of widgets".  In essence, that's what it '''is'''.  I have written much using JavaSwing; whilst Swing has numerous flaws, being awkward to build "a dynamic data structure holding references to a wide variety of widgets" is not one of them.  Even if Top tried to define his own GUI engine via pixel-pushing and bitmaps, at least from a containment point of view, it's trivial in Java or (probably pointlessly, but whatever) in Swing.''

I created a structure that held type "object", but was having trouble getting it to "hold" or point to dynamically-created widgets for some reason. Perhaps I was missing some key knowledge, but most documentation and materials I found only had examples of statically-created widgets. I figured I was in poorly explored waters because people were all doing it the static way and that's what the Swing designers apparently intended. I don't have a lot of Java experience, so didn't want to try to be Christopher Columbus with it. I don't remember the details, it was a while ago.

--------

Re: '''Make-It-Now'''

''Top, why don't you create this CGB XML markup language, and demonstrate to us its marketability and/or capability?  I doubt anyone is going to build it for you.''

That's a huge programming task. Maybe when I retire. Why don't ''you'' do it, then you can put in recursion, and tell me to shove it recursively.

''No.  I have better things to do.  A language that caters to bad programmers who are good at XML?  Bad idea -- one ColdFusionLanguage was already too many.''

ColdFusion does not really cover CGB, as already explained. And you still haven't explained the specifics of CF's alleged evils.

''Then what does "really cover CGB"?  Ideally, you need to provide more than a definition of CGB -- you need to provide a specification.  One of CF's most profound evils is the abominable notion that it's reasonable to use XML tags to express imperative code.''

I agree it would be helpful to have a full spec for CGB, but we don't need such for specific scenarios because we consider each scenario as it's encountered (such as asking how often we need recursion).

* ''How do we know what you consider CGB is what I consider CGB?  I need arbitrary processing of hierarchies, in either depth-first or breadth-first order, with arbitrary processing.  For that, I think recursion is mandatory -- I certainly don't want to be forced to simulate it.  I expect to have HOFs, in order to inject customisation into implementations of common algorithms.  I expect to be able to author arbitrary widgets on HTML5 canvasses.  I do these things a lot.  They are common to me, and common to my colleagues.  Can CGB do that?''

* You are ignoring frequency of field usage/need. If it was truly a common enough need, then you'd be able to rattle off a few actual scenarios. Otherwise, your summary feel for "experience" may be lying to your brain.

* ''That's my point:  How do we know what you consider "common" is what I consider "common"?  How do we know that either is '''actually''' common?  I think the sort of things I do are common, because I do them and I know other people who do them, and I sometimes find StackOverflow questions about similar things, or find articles in blogs about similar things.  Is that "common" enough?''

** Describe them and we'll consider them together. If you say something is common and I say it's not, then we'll LetTheReaderDecide. I will expect you to explain why the design was done the way it was in sufficient details, and that's an area where you guys have been difficult and evasive. I suspect you lack field experience, but welcome you to demonstrate otherwise. If you build things as requested but don't understand the business reason behind them, then perhaps you are not the best person to ascertain actual industry needs. Often there are better ways to do things. For example, line charts may be better than the single-line bar graphs of your demo to monitor patterns. Alerts of highs or lows can be done with flags or text warnings, but the addition of line graphs can show medium-term trends (similar to Windows CPU monitor graphs). Your client may not have thought of that. The reason why such would be rejected would perhaps tell us more about the domain and requirements, because its seems a better solution to me if patterns are being sought. (CF has a pretty good line-charting tool built in, by the way, although not meant for sub-second refreshes, which may not be needed if alerts are available.)

** ''The last time I mentioned my field experience in specific detail, you subsequently complained that you didn't want a resume.  Therefore, I'll try to be more general.  My field experience is extensive. For fifteen years I wrote custom applications and ran a business that developed custom applications, primarily for business-related purposes.  Now I do some development and consulting, but my main career is university teaching in SoftwareEngineering and leading curriculum development in IT and ComputerScience with a particular focus on software development.  I am, therefore, in regular contact with small and large employers of software developers.''

** I meant describing the domain problem/scenario, not yourself.

** ''You mean I don't have field experience describing the domain problem/scenario?? Huh?  Above, you wrote that you suspected I "lack field experience" and welcomed me "to demonstrate otherwise."  So I did.  On ArrayDeletionExample, as part of a debate over the meaning of "'core' custom biz app", you asked me to "list some specific projects" -- presumably which I'd worked on, as it was in response to my pointing out that I'd made my living for fifteen years developing business applications -- "and maybe we can find one that we both agree is a 'core' custom biz app."  So I listed some specific projects I'd developed, and your response -- oddly -- was "I wish to see coded scenarios [...], not a resume."  Huh?  Twice, you've asked me to explain my experience -- because you doubt I have much, apparently -- and twice you've responded that you didn't want to know my experience.  Huh?  Do you feel threatened by the fact that I have extensive experience in the "custom biz app" area and yet I disagree with you?''

** This issue appears to have begun when I said, "I will expect you to explain why [a] design was done the way it was in sufficient details, and that's an area where you guys have been difficult and evasive." An example of that is that you don't know why they didn't ask for or want line graphs (described above) when I asked a similar question earlier. A skilled business analyst would propose that and other designs to the customer to at least better understand what they really need. You guys just seem non-curious about the business side of things and don't seem understand how and why business does what they do, or at least suppress that knowledge here.

** ''The individual who asked for the line graphs (described above) '''is''' a skilled business analyst.  I see no need to second-guess his expertise, much as he sees no need to second-guess mine.  That's why I respect that what he asked for is what he needs, just as he respects that what I delivered will meet his requirements.  It would only have annoyed him if I'd questioned his need for line graphs, and he'd merely have sought a solution from someone else.  As such, it isn't a matter of being "non-curious about the business side of things", it's a matter of the simple reality that the programming issues we discuss on this Wiki almost invariably presuppose that the business requirements have already been identified, so what we're talking about are the technical aspects of implementing them.  This is, after all, a Wiki about PeopleProjectsAndPatterns in SoftwareDevelopment, not PeopleProjectsAndPatterns in BusinessAnalysis.''  

** If you are familiar with his work, that's understandable. Often asking and presenting alternatives is just a way to learn about what it's going to be used for, which allows one to tune it better for fit. There's always '''details''' that have multiple design pathways, and having knowledge of actual usage helps one make better decisions at that level.

** Plus, it doesn't make a very good example/demo if you just say, "The customer told me to make it that way; I don't know why it has pink counter-rotating flowers that squirt lemonade."



* ''Actual scenarios?  Sure:  I create CMS systems where users need to navigate directory/file hierarchies, often with customised per-file displays with retrieval of ancillary information -- for that, I need arbitrary processing of hierarchies.  If I have recursion, I can create them myself.  Without recursion, as long as I can inject custom processing into the directory/file traversal -- injecting a HOF would be ideal for this -- it will be fine.  I also create employee scheduling systems based on genetic algorithms.  For that, I need to be able to inject HOFs into the GA implementations.  I create specialised widgets to suit user requests -- funky stylised wheel menus, for example, seem to be a bit of a "thing" -- so I need to use HTML canvasses and attach associated code.  My colleagues have correspondingly diverse requirements too.''

** ''No comment from you on these?''

** It's below. What does the employee scheduling have to do with GUI's? You seem to be mixing topics.

** ''I don't know about you, but I usually interact with software via GUIs.  Employee scheduling systems are notable for requiring complex editable grids with drag-n-drop between cells.''

** Are you introducing a new sub-scenario/UseCase? If so, either do it all the way or don't do it at all. We have enough partially-explained scenarios already.

** ''Sure, here's the entire UseCase:  It is necessary to be able to drag and drop between cells in a grid where the grid cells can contain any GUI elements.''

** Why does that require explicit recursion? Drag-and-drop is a CGB. Perhaps class sets can be used to control what objects can be copied or pasted into what destinations:

      <foo dragin="yes" dragout="yes" dragsources="myclass,flig,nib"/>

* ''CMS systems often allow the user to navigate their local directories to copy or synchronise their local repositories with the shared server-side CMS content.  CMS systems often allow the user to navigate a hierarchical view of resources on the server.''

** Why do you have a synchronize step?

** ''Users often want to work on their local repository, previewing it frequently, before uploading some or all of it to the CMS.  Users often want to download portions of the shared server-side CMS content to work on it offline.''

* Why is recursion necessary to allow ''users'' to navigate? I agree it may be used to generate a tree from data, but that's generally done in the app code and it should stay that way. I'm not proposing a data processor or general computational engine. (Preferably much of that should be on the server because that's usually where the data is.)

* ''Recursion makes it possible to highly customise the navigation process.  Alternatively, a HOF can be injected into the navigator to customise it.''

* And I don't expect a GUI markup to cover everything. There will always be the cutting edge UI and fashion-wise and we don't need to trying to keep up with that. Where a GUI markup would really be useful is in-house or the back-room of apps that don't need the latest fad interface styles, but merely need to get work done. If the fiddlers of the world invent a GUI widget that's truly a step forward and it has staying power, then we can consider adding it to the kit. Your argument seems to be that since we cannot cover 100% of GUI needs, we should not try to standardize anything.

* ''When a developer wants to stretch the boundaries of the tool and create custom code -- which is what programming is all about, really, and the main reason people become programmers -- limited languages are frustrating.  '''Deliberately''' limited languages are utterly infuriating.''

* Again, I am not preventing an app/scripting language from doing  more with GUI's for special needs. I'm just trying to package common gui idioms into markup. We want the common stuff to be easy and the hard stuff to be possible (by assisting app code).

* ''If you wish to package common GUI idioms into markup, that's quite reasonable.  However, it is not at all reasonable to restrict capability from those who want to do more sophisticated programming.  Restricted capability inevitably forces developers to switch to different products when it becomes obvious that doing something simple -- like recursively iterating through a collection of resources, for example -- is awkward or impossible.  It's one of the reasons 4GL products demonstrate relatively limited popularity whilst general-purpose languages like C#, Java -- and to a certain extent Python, Perl, and PHP -- get used extensively in precisely the domains targeted by 4GL products.''

* You still haven't demonstrated a common need for recursion in the markup with scenarios and UseCase''''''s with things like, "Users need the Foo to light up when they click on the 3rd Glib so that they can visually find all the Ziggs associated with the Norfs (where Ziggs and Norfs are explained)."

* ''Any development tool based on existing use cases -- or the absence thereof -- is doomed to failure.  An effective programming language needs to be capable of handling future, as yet unknown, requirements.''

* You are making up false rules of programming. Besides, even if something has a good run of 15 years and only 15 years, maybe like HTML, it's better than the permanent production-obscurity of Lisp.

* ''I'm not making rules, I'm making an observation.  Deliberately limited languages have a limited lifetime.  LISP, however, is still profoundly influential over fifty years after its invention, and is actively used and developed on a number of fronts.  Recent efforts like ClojureLanguage demonstrate that it's actually growing in popularity.''  

* I disagree with that assessment, as described at GreatLispWar. A limited lifetime may be the price paid for fitting the technology idioms of the day. The Model-T car fit the technology and infrastructure its day. Things changed, and so did cars. The fact that the Model-T is not used anymore does not mean it was a "failure". It served its time and purpose with distinction. 

** {The Model_T was a HUGE success. I'd say that the success of that car and others of its era paved the way for the cars that replaced it. The fact that the Model-T was superseded tends to bolster the case that it was a success, in that it demonstrated the need and inspired further advances.}

* ''Your arguments in favour of a "programming language for dummies" are simply not going to find any favour here amongst us programmers.  You'll have as much luck selling the idea here as selling chocolate hammers to professional carpenters.  We want more powerful languages, not less.  If you have a hope of selling this idea, try to sell it to your boss.  But if you succeed, you should expect a toy language (from a serious development point of view) to have -- at best -- a very short lifetime.  Think PowerBuilder, only a much, much shorter period of much less popularity.''

* PowerBuilder is still around and still works. And I know many programmers who would like a simpler, more approachable way to build web-hosted GUI's other than mastering JS and weird libraries in the HtmlStack, especially for internal apps that don't need the latest and shiniest UI fads. A good many would rather be able to focus on business logic than reinventing CGB by micromanaging or debugging panels, mouse coordinates, and pixels. Your statement reminds me of the Windows C++ programmers versus the VB programmers in VB's early days. The C++ programmers bragged that they had fuller control over GUI's and that VB was a "toy" GUI building system. However, VB expanded much faster than Win-C++ and eventually far outnumbered it in terms of production code. Win-C++ development had a reputation for taking too long to finish projects and/or Win-C++ programmers "cost too much". You may complain about the tool or "stupid owners" all you want, but the industry liked it and embraced it. Different programmers like different things, by the way.

* ''Again, your arguments in favour of a "programming language for dummies" are simply not going to find any favour here.  If you know developers who want your simplified language, perhaps you all can take up a collection to hire a language developer to build it for you.  Here, we're interested in languages that offer power, not limitations.''

* Your kind keeps losing the GreatLispWar as far as market penetration. You can complain about it all you want, but it's not going away.

* [If that's the case, why is every mainstream language becoming steadily more powerful and flexible? -DavidMcLean]

* As explained in GreatLispWar, most languages tend to tack on features over time to keep interest alive, including the latest fads.

* [Even assuming that's the only reason for adding features, doesn't that just support your correspondent's point?  Developers are interested in languages offering power, so languages might "tack on" features over time to afford more power and thereby increase interest. -DavidMcLean]

* No, it's more of a gimmick to keep users and companies feeling like the language is "keeping up with the Jones'". It's a feature check-box contest so that somebody can't come along and say, "But you/they are using Foootran, which lacks Higher Subject-Oriented Zoomda's, and therefore is obsolete!". Many of the known languages are kind of like trees: start out small and simple, hit a big growth spurt, become heavy and cumbersome and full of stale sap, and then wither or die and fall. A new nimble and light batch pops up each generation with the latest BigIdea and repeats the cycle. I remember in a discussion board about whether ColdFusion should offer full-blown objects (instead of just component-like objects), somebody chimed in and screeched, "Just add fucking objects so that people pushing Java, DotNet, and Php stop trashing CF for not having them. Give them a damned bone to shut them up already." (paraphrased). Even COBOL is object oriented now. -t

* [This concept, that adding features is merely a gimmick to keep users feeling the language isn't obsolete, presupposes that added features aren't actually useful on their own merits. Often, they ''are'' useful. In addition, features added to an evolving language are often chosen based on usage patterns, rather than for "bandwagon" purposes; consider generics and anonymous inner classes in Java, for example, both added to improve the use of common Java code patterns. -DavidMcLean]

* Some say they were added as work-arounds to other Java weaknesses.

* ''Who are the "some" who say this?  In a sense, though, it's true.  Missing higher-level abstractions is certainly a weakness compared to having higher-level abstractions. So, adding them to Java makes Java stronger.  Speaking as a Java programmer, I use generics and anonymous inner classes.  My code is simpler, clearer, and more type-safe with them than without them, because that's specifically what they enable.  Java will be even stronger when Java 8, with lambdas, is released.  See http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-4.html for some code examples.''

* Java is gradually turning into a "specialized" language with a longer learning curve and the potential for "spaghetti abstraction", similar to C++. They risk killing it by doing that, but sometimes you have to play the FeatureCheckboxBrochureGame to survive.

* ''Which recognised independent survey of Java developers is your opinion based on?''

* Same as the source of your opinions.

* [How does adding ''general'' features, like generics and lambdas, make a language more ''specialised''? Wouldn't they (trivially, by definition) make the language more general? -DavidMcLean]

* I meant that it's more likely to be used by a "Java-only" specialist. It's not a language programmers tend to casually hop into and hop out of (or use in combination with many other languages in a given shop.) Again, this is its general trend, not a hard wall.....so far.

* [Again, this doesn't make sense. General features, like generics and lambdas, aren't Java-specific, so including them wouldn't make the language require more Java-only specialists. Generics are a feature afforded by practically every statically-typed language in some form or another, while lambdas are available in most any language with first-class functions. -DavidMcLean]

* Your argument seems to be that such features greatly improve programmer productivity and thus require less Java programmers. I'm skeptical of that, at least outside of SystemsSoftware. But that's a diff issue than what "kind" of language Java is anyhow. I'm characterizing the language, not quantities of human bodies.

** [Actually, my argument was that you don't need more "Java-only specialists", as you put it, because these features are familiar to programmers of many other languages; therefore, programmers with less Java-specific experience may more readily develop in Java. -DavidMcLean]

* ''Speaking as a long-term Java programmer, writing both SystemsSoftware and business applications, I would say such features don't "greatly" improve programmer productivity, but they significantly improve code readability and reliability, and make it easier and more enjoyable to develop.  Do not deprecate the significance of developer morale on '''maintaining''' productivity.''

* What's considered "readability" varies widely per person. Peoples' eyes and heads can work very different from each other. Thus, it's not an objective statement.

* ''I assume "readability" as interpreted by the competent majority of programmers, not the few who struggle with programming.''

* Majority? You did a survey?

* ''I didn't have to.  It's obvious.''

* Saying so doesn't make it so.

* [How ''isn't'' it obvious that the majority of programmers do not struggle with programming? -DavidMcLean]

* They do. Managers/customers always want the latest and greatest and desktop-like behavior etc. It's difficult to keep up with all the potential libraries and techniques and fads, both style and tech, coming and going on different browsers and portable devices. And "departmental" IT-divided orgs will also want network and server knowledge.

* ''They don't.  Programming paradigms have been established since the early 1970s and are a standard component of every ComputerScience curriculum.  Learning a new language is a matter of slotting syntax into the relevant paradigms.  Libraries and frameworks are a matter of learning functions and classes (or whatever) for a given language or set of languages.  Network and server knowledge, in most cases, requires little more than some software installation and configuration.  Overall, acquiring new knowledge may take a little time but once the fundamental paradigms are understood it's never difficult.  There is no "struggle".  There is only negligible effort and a bit of time.  Doctors learn advances in medicine, lawyers learn new legislation, programmers learn new technology.  It's what we do.''

* [Programmers are expected to keep up with changes in technologies, designs, paradigms, and so on. People who can't do that shouldn't be programming. This was discussed in detail on GreatLispWar (search "take up knitting"). -DavidMcLean]

* I "expect" my plumber has a degree in hydrological engineering. IwantaPony too.

** {I wouldn't. The connection between hydrological engineering and plumbing is minimal. But I would expect that a plumber that offered to design the plumbing in my house would have kept up on the latest in plumbing designs and that a plumber that I hired to fix that plumbing would have kept up on the latest in plumbing repair techniques.}

** HOF's have been around a long time. They are not "new". And I would expect the plumber use techniques that '''another (future) plumber will likely be familiar with'''. Maintenance matters.

** {Yes, I would expect that future plumber to have kept up also.}

** And if your expectations are unrealistic, or the skills important to you are not that important to most other customers such that few will follow it? Most programmers follow what the market pushes them to follow.

*** {There's nothing unrealistic about expecting competency from those you hire. The rest of your statement is a RedHerring. I'm not hiring for other customers. Yes, needing skills that aren't common might make it harder to find someone, but even worse is hiring someone who can't do what needs to be done.}

*** If you define "competency" different than most customers, then yes it is UNrealistic. The world does not re-shape itself to fit your idealistic mental simulation of what it "should be", unless there is a ''God of Shouldness'' that we don't know about yet.

*** {Really? So, it's unrealistic for Oracle to expect that the people they hire to write their low-level disk drivers actually have the skills to do so? Most customers don't need those skills.} 

*** What Oracle views as "skilled" and what you do may be different.

*** {So? You said, "If you define 'competency' different than most customers, then yes it is UNrealistic." What Oracle needs for it's low-level disk stuff fall in that "'competency' different than most customers" category. Is it unrealistic for them to expect the people they hire to have those skills?}

*** I don't know why you selected disk skills as an example.

*** {It's something I know they've hired for and isn't a need that most companies have. So is it unrealistic for them to expect the people they hire to have those skills?}

*** I don't know, I cannot read their minds and never worked for them. 

*** {You've already said it's unrealistic for me to do so and you can't read my mind and don't work for me. Oracle shouldn't be any different in that regard. So is it unrealistic for them to expect the people they hire to have those skills?}

*** Sorry, you lost me. Developers I encounter for "custom business applications" are not expected/pressured to master certain advanced techniques in general, as I observe it. I'm just reporting my observations in terms of hiring processes, performance evaluations, etc. Objects can do most of what HOF's can do, even if they are a bit more verbose. The frequency is not there to make verbosity a noticeable issue. (If it was, it's probably due to a poor design somewhere.) There may be different patterns at Oracle, but I'm not familiar with "the scene" for SystemsSoftware or Oracle and thus will not comment on their industrial personnel patterns.

*** {You've done more than reported, you've claimed that I should hire based on what "most other customers" want. You did that without reading my mind, working for me, or even knowing what "scene" I'm in. I'm asking you if you would make the same recommendation to Oracle. So is it unrealistic for them to expect the people they hire to have those skills?}

*** No, I'm only pointing out that it may be hard to find an employee that fits your expectations for a situation if the marketplace puts out insufficient incentive to have the skills you value for that general niche. If you want a car with 3 headlamps because you value 3 headlamps, your choices of cars are significantly narrowed. The closer your profile is to the general industry, the wider your selection is. If you focus on traits that other orgs don't value for an industry segment, then those traits become a bottleneck because they are '''"out of sync" with the expectation profile of the industry'''. -t

*** {Should have known you would fall back to a position that is almost, but not quite, totally unlike what you originally said. I'm already aware of that. I'd already said that in this conversation. Your response to my saying that was, "If you define "competency" different than '''most'''[emphasis mine] customers, then yes it is UNrealistic[emphasis yours]. The world does not re-shape itself to fit your idealistic mental simulation of what it "should be", unless there is a ''God of Shouldness''[emphasis yours] that we don't know about yet."}

*** I'm not following. Please restate.


** ''Fortunately, HOFs are now mainstream -- thanks to ComputerScience education and LISP, Pascal, Python, Ruby, Javascript, C# 3.0, Java 8, Erlang, Clojure and Haskell -- so it's entirely reasonable to expect future plumber^H^H^H^H^H^H^H programmers to know them.  Unless, of course, your programmers are uneducated and experienced only in BASIC, COBOL, PHP or ActionScript...''

*** [It's perhaps worth noting that any non-trivial ActionScript code will use higher-order functions, because it's an ECMAScript dialect much like JS and, also much like JS, uses first-class functions for event listeners. PHP has also had a crude approximation of higher-order functions for a while, and it gained closures more recently. -DavidMcLean]

*** Moved reply to NaturalEventSyntax.



** The CBA world mostly ignores Erlang, Clojure and Haskell; and JS made inroads mostly due to QwertySyndrome. 

** ''Perhaps, but the "CBA world" certainly doesn't ignore ComputerScience education, C#, Java, and increasingly, Python and Ruby.  Even PHP has adequate support for higher-order functions.''


* [Having a degree in hydrological engineering isn't actually part of the "plumber" job description. Being able to pick up new technologies ''is'' part of the programmer job description, so it's entirely reasonable to expect it of someone dubbed a "programmer". -DavidMcLean]

* Yes, I have a "to-learn" list of about 25 or so technologies. I rank their order by what I expect the market-place wants and rewards.

* ''Excellent.  Out of curiosity, what's on your list?''

* Windows network security is a hot one. Not that I am anxious for it, but it creates a lot of headaches around this particular shop. Learning Adobe graphics tools to create fancier logos, swooshes, borders, buttons, etc. Oracle server-side programming is also in high demand around here. Flash authoring/programming was high on the need list also, but Google and Apple want to kill it of late, thus I may have to dive into JS libraries until a real client standard comes along.

* [The ''reason'' Google and Apple (and many others, actually including Adobe themselves) are trying to "kill" Flash is that it's not a real client standard, being proprietary. Their intent is to replace it with HTML5/CSS3/JavaScript functionality, all of which are in fact real client standards as put forward by the W3C. -DavidMcLean]

* HTML5 is still immature, and tends to focus on media and visuals more so than GUI idioms.

* [It certainly does focus mostly on media and visual features (<canvas> being a prime example); this is because there's currently no good standardised way to do those things. GUI idioms, by contrast, can ''already'' be achieved through a combination of HTML's primitives (stuff like <input> tags), CSS customisations, and a library to supplement interface scripting such as jQuery UI (unlike Flash, libraries like jQuery UI are open). Why reinvent the wheel by adding those things to the HtmlStack "core"? -DavidMcLean]


As far as CF, the XML is almost whatever you want it to be. The average programmer is not going to be a very good XML language ''interface'' designer (or not care enough to think designs through). It's a lot like writing an essay: writing an essay is relatively easy. But, writing a ''good'' essay takes time (concise, clear, on-topic, etc.) If somebody/something came up with a good XML wrapper standard over CGB, then each Joe Sixpack programmer will not have to reinvent GUI XML. Let master API/XML interface designers or a good vetting process do that, not programmers who only know or care about solving specific problems for specific customers.

''Sorry, I don't follow you.''

CF is an XML domain language builder. If you build a bad XML domain language with it, it's not CF's fault. If you build a Lego horse and the horse has an ass that's too big, is that the fault of Lego or the horse builder? Also keep in mind that the resulting XML is often targeted at graphics designers who know HTML, not necessarily programmers.

''How is CF different from PHP, ASP or JSP?''

It has built-in idioms to make it easier to create markup "commands" to supplement HTML. Remember, this issue started when you stated, "One of CF's most profound evils is the abominable notion that it's reasonable to use XML tags to express imperative code." Keep in mind this is mostly a different issue than CF's built in imperative statements. One does not have to use them to devise a domain-specific or shop-specific XML DSL.

''You mean CF lets the developer add custom markup tags?''

Yes. It's generally used to make it simpler for web graphics designers to add prepackaged features to pages.

''So how is that superior to the various HTML template systems available for PHP, ASP and JSP?''

1) It's built-in so that you don't have library dependencies. 

2) The designer can gradually learn the CF (built-in) imperative markup tags such as IF's and LOOP's.

Yes, you can perhaps make those others resemble ''some'' of CF with enough libraries and plug-ins, but why not get the real deal? (CF also has a JS-like/JS-lite scripting language if you don't want to use markup for IF's, loops, functions, etc.) CF doesn't have a lot of high-brow features, but it has a lot features that to assist low and mid-brow programmers, and help graphic designers write "power HTML". It also allows nested templates that can also optionally do imperative (in addition to custom tags) which is not easy to emulate. You'd have to reinvent an interpreter in Php etc. to get it comparable.

[It's common consensus that having business logic in your templates is a Bad Thing™, and indeed several "logic-less" template languages have been devised to try to ensure separation of concerns in this case. Adding imperative markup tags seems to be a step backwards, with this in mind. How will you ensure separation of business logic from presentation? -DavidMcLean]

The SeparationOfConcerns thing is largely a fad meme. The boundary between "business logic", "presentation", etc. is fuzzy. They are intertwined, designed together and dependent on each other in terms of conventions and interaction between user and features. Plus, it often results in unnecessary maintenance jumps to separate things that have a one-to-one relationship. It's poor normalization, a MirrorModel. I '''do things for a describable reason''', largely based on CodeChangeImpactAnalysis, and not because fad memes say so. --top

''SeparationOfConcerns is not a "fad meme."  In general, it's simply the term given to a self-evident good practice: the avoidance of turning programs into a BigBallOfMud by separating distinct functionality in order to manage complexity.  It's only a MirrorModel or poor normalisation if done improperly.  It applies equally to the Web stack, though there are some HTML tags that allude to presentation (<font>, <b>, <i>, etc.) which may suggest fuzziness but where, in fact, they're merely the result of legacy support for pre-CSS HTML.  Presentation and business logic are fundamentally and inherently separate, by definition.  Presentation is about how data is shown; business logic is about how new data are computed from existing data.  Business logic defines how data changes, independent of whether or not the data is ever displayed.  Presentation defines how data is displayed, independent of whether or not the data ever changes.''

If your app or org has a general shared style, then relationship factoring alone will "agree with you" and one factors the standard style info to a style-sheet or what-not. We don't really have a dispute there. However, if it's a one-off page or screen and the maintainer of the "business logic" side will likely also be the maintainer of the style-related info, then it's generally more economical and efficient to keep it together. I'm confident a study of change probability and hand and eye movement would bear this out. If and when style info becomes shared, or the style maintainer will be diff from the app builder, then factor it out. The back-and-forth mirror-hop for 1-to-1 wastes time and screen real-estate. Plus, it bloats up the style libraries to fill them with one-off's, slowing down the finding of items being sought. Long lists are a PITA. A good portion, perhaps most, developers don't have FastEyes. The people who pay me want efficiency, not vague slogany platitudes. I balance tradeoffs for my designs, not process slogans. Slogans can be good reminders to consider factors, but not a substitute for thinking.

Another example is back-room utilities for in-house apps, such as a user account/role-manager library or screen-set. Most of the time nobody gives a shit about changing their style for internal stuff: make it a generic silver gray. If we make them depend on a shared style-sheet(s), then often one forgets when copying them over to a new app or make them fit the style folder convention of the new app. It's often more convenient if they are '''self-contained''' so that one can move and mix and match as needed without annoying oops-I-forgot ties to a css folder or related conventions. Those remind me of desktop computers with pasta-galore cords hanging off them. You think you unplugged everything to move a PC, and one straggler cord you miss knocks over the coffee and trips the boss onto her face. -t

I agree that MentalIndexability can play a role in how things are divided up, but in this case it's usually not a difference maker because one generally goes to the HTML HEAD section to find the location of the style-sheet(s). If they are in-lined (or at least the one-off parts are), you see them there anyhow.

And how did the CF sub-topic drift to style-sheets? A web/graphics/layout designer may deal with much more than style-sheets.

[Actually, you took us to style-sheets, Top. It's perhaps because of the irritating conflation of meanings for "presentation". In the context of "separating it from business logic", "presentation" refers to code that wraps up values in HTML tags: HTML templates or views, specifically. Feel free to rant about how that's dumb and confusing; I'm inclined to agree. However, the fact remains that business logic does not belong in template/view code, nor do presentational styles belong in ''either'' of those places. SeparationOfConcerns remains important. -DavidMcLean]

I still don't see how "roll your own tags" is mostly about style-sheets. The project involvement level or number of hats other members of an organization vary widely. The segue is still fuzzy.  As far as SeparationOfConcerns between semantics and presentation, OverhaulingStyleSheets already covers that battle.

[It's '''not''' mostly about style-sheets; you've merely interpreted "presentation" as meaning "style-sheets" when in this context it actually means "templates/views". Feel free to reevaluate given the understanding that our source of contention is the mixing of the concerns of ''business logic'' and ''template/view code'' and that at the moment style-sheets aren't important. -DavidMcLean]

UI design is inherently tied to business logic. If a drop-list is limited to 7 items, let's say "order status", that likely reflects business logic. And a non-programming UI designer or domain analyst may be able to specify such in a specification and/or markup.

[A drop-list's being limited to seven items may ''reflect'' business logic, but that does not mean it ''is'' business logic; such a fact actually definitely is not business logic, simply because it's not logic. Templates/views should contain a bare minimum of code needed to render the view appropriately, preferably with as little logic of any sort (business or otherwise) possible. If we're thinking ModelViewController, we want most business logic to be in the models and only in the models. (Depending on the business, some logic may need to be handled in controllers, but none of it should end up in the views.) -DavidMcLean]

Such a thing can be re-projected into formal logic if we wanted to, so your "is not" claim is false. As far as your "should" rule, you need to justify it better. The reader should not have to take your word for it. And MVC is vague.

''Business logic defines changes to data; it has '''nothing''' to do with how the data is shown.  A "drop list" is a display device, so by definition it is part of presentation, not business logic.  Beware of conflating business rules -- which might well dictate that a maximum of seven items be shown -- with business logic.  Business rules may govern both business logic and presentation.''

* Hogwash! A good many sticky reports/screens have tons of business logic to control what is displayed where, when, and why. For example, a footnote marker may go in certain cells but not others, and the logic to control this may be very involved. And it can be very important to the company because executives and/or big customers/investors read such reports. One often has to work closely with domain experts to refine such rules because the presentation experts have no clue other then deciding on the size of the asterisks/markers etc. Where did you get this "it has to be saved to be BL" rule from? (Paraphrased) If we do save a copy of the report, does that transform it to BL? If we save an intermittent version of the report with the footnote markers does this change it into BL? That's rather arbitrary. -t

* ''You appear to be conflating business logic with presentation.  Business logic doesn't control what is displayed where; presentation logic does that.  It has nothing to do with "sticky" or "saved to be BL", and I'm not sure why you think it does.  See BusinessLogicDefinition.''

''MVC is not vague; it describes a clear delineation between representation of data (model), presentation of data (view), and mechanisms to manipulate the view and the model (controller).''

So you say. Anyhow, I don't want to debate MVC defs today. 

''So pretty much '''everyone''' says.''

You haven't done any fricken survey.

''Read almost anything on the topic.''

I can't find any usage surveys. Separation/MVC kind of has been a fad for the last decade or so. Those who propose it under most circumstances write about it and those who are more practical ignore it as another form of GoldPlating it often is. See also MvcIsNotImplementable and WhatsaControllerAnyway.

''Those pages debate specific interpretations of aspects of MVC, not the overall concept.  Those who are practical simply use it.  Note that your TableOrientedProgramming embodies the "philosophy" of MVC:  Tables are the model, views are query results, and the controller is the query language.''

It can be interpreted such that just about anything fits.

''No, though it is quite common.  A given binary search algorithm, for example, isn't MVC -- or at least not necessarily.  However, there are environments and frameworks where MVC is used pervasively, to good effect.''

It's just a RDBMS-atized version of input->process->output.

''It's perhaps as fundamental and significant as input->process->output, but it models ongoing interaction whereas input->process->output is effectively "batch" or non-interactive.  It's controller->(model->view).''
----------

What about this for notifications: Put a single-line red banner at the top of the cell if there is an alert. Clicking on it will show more of the message, if it's longer (as indicated by ellipses or something). Reserve a thin strip at the very top for system-wide alerts.

[That's a fairly nice interface design, but it doesn't address any of my questions.]
-------------

I should point out that server-side programming is generally easier to manage and develop for, even if it is a bit slower for certain behavior. (You may not have to download JS libraries, which speeds up some situations.) Thus, I recommend that one use client-side programming for the frequently-used behavior, but server-side for the rest. -t

------
See also: BradyBunchHeadExample
----
CategoryFunctionalProgramming, CategoryWebDesign
----
FebruaryThirteen