Jan Zwicky, Wittgenstein and Form

I was thinking that had PART ONE had the single line page headers and PART TWO had double-line page headers ... too obvious? A one unit and then a two unit length line as page headers? Golden ratio lengths? Imagine the unexplained subtle elegance of the book without the PART pages themselves being required as partitions.

§
What about a poem which opens with a left indent to

I wonder if it is the case that 

    [and then stanza(s),
    finally ending with
    a right indented ]

        I think that it is so.

Imagine starting to see this as a recurring form in poetry magazines, anthologies.

A paradigm case of  the ugly: a single quote from misguided Ernest Gellner Words and Things, 1st Ed. ?

Dal segno al coda would require us to use U+1D10B as the non-printing HTML UNICODE escape sequence &#1D10B;

The printer or the author was selective in the LW segno chosen?

It was not the segno

Repeat:

And then to the coda.

.htm for Mini Mobile and .html for aLL eLse Larger?

2014 might not be too late to achieve this simple option:

  htM for Mobile web content

  htmL for Laptop and aLL other Layout

Luckily, we never had an "xhtml" file extention - and we were permitted both SHTM and SHTML for server-side includes.

The reason to consider HTM for mini displays is that it would not require typing by users to shorten or lengthen the extension if browsers would agree on a hot-key combination.  A smart browser would check at any site offering an HTML whether there was an HTM if the last URL used was HTM by user choice and so offer the option visually to the user for the current site.  It would be a simple browser  configuration option for those devices, the format of which, was neither Large nor Mini.

Lately I have been using htm for 4.01 HTML and html for XHTML and also for HTML5.  As the web moves to the latter, we should be able to set a meta value to flag that, say,  this .html file has a sibling .htm file for constrained display and vice versa.  And ditto for .shtm and .shtml and whatever might follow from 2014 until we achieve 20/20 hindsight.

curlgen using Scala Lift. Not. Or: XML considered harmful

The other day I was looking at a modest web framework's HtmlTag class and saw that it had a parent class: ComponentTag.  Fine; I'll subclass CurlTag from that parent. Not. The parent of ComponentTag was none other than XmlTag.  What made this almost funny is that this framework claims to spare you XML configuration pain.

Imagine if the authors of the first unix shell had required that scripts be written in COBOL.  COBOL was ubiquitous in business systems at that time.  And then just imagine some key, patented component, say, suid, somehow required that a hidden .conf  file parse correctly as COBOL ...

So here I find myself today re-visiting Lift, the web framework stalwartly bearing the Scala standard onto the field of software slaughter.

The author of the Scala 2.7.6 compatible Lift 1.0.1 web framework has admitted that to set a non-XML MIME Content-Type for a Lift app that you must manually re-code Boot.scala in your app.

Imagine.  Here is a framework where convention has triumphed over configuration.  Run a few maven tasks and all is installed and one more maven task and you are up and running.  So long as anything you output as web content has an HTTP response payload starting with

    ?xml version=
and then
   !DOCTYPE html

Even with the content type manually flipped in Boot.scala ( and that is not as obvious as the web posts and sanguine responses might lead you to believe) the XmlParser is invoked.  Oh vey. LiftRules.determineContentType must be called after this and before that ...

Perhaps when Martin Odersky wisely included Traits (from the Swiss Smalltalk team up the road from Laussane in Berne) it became debatable whether IoC containers would require implementaion using Dependency Injection.  But here I am, reaching into the bowels of Scala Lift, just to flip a MIME type and free myself of an enforced XML parse.  All this just to output a page of non-XML, non-HTML, non-XHTML and yet not mere text/plain web content.  When did all internet markup become trapped in angle brackets?

The GOF warned that the Hollywood Principle can make for software which is dificult to understand.  Imagine the starving actor.  Even in Kafka's world the anti-hero could petition to change, if not improve, his lot.  But we who might serve must now sit and wait in the hope that we might be called.  It has been said that IoC prevents spaghetti code at the price of macaroni code.  We were promised a platter with a few of these and a little of those.  All at the openly shared feast freely offered in the marketplace.  But not without risk of something indigestible in the stuffing.

There must be room for some measure of configuration in this mad rush to impress the CIO's with the trivial app that hints at a killer app.  RAILS is not a killer app.  Emulating RAILS is folly.  Software - and with no effort at all. Imagine.  Less effort than learning to unicycle.  But you won't touch that page without a Ruby programmer at your elbow.  Call it "peer-web-dev".  The Rubyist will be peering over your shoulder.

There are supposedly highly-principled reasons to prefer Lift to RAILS (though perhaps not to GRAILS) and, in fairness, perhaps Lift version 1.1.x will break this fond coupling with XML and XHTML.  But if Lift was to be an indication of the advantages of the Scala IT shop over the Java-only shop and C#-only shop then Scala has surely not found its "killer framework" in Lift.

My Kafka-esque nightmare: a revival of Hermes, from IBM, in the Aufhebung above and beyond the split of OS from application process - the messenge has almost arrived! - only we find that PlanK only installs in our wristwatch ant-gravity gadget if Maven was first installed ... POM-da-da-POM.