Gosh, I love this thread...
> > Yes, I had the taste of the power of continuations when I dived more
> > into the paper you presented (and implemented myself a few scheme
> > examples to get the feeling of it).
>
> I do like the concept of continuation as well. It gives you a better way
> of writing interactive apps. It's like in the early days of programming
> where you had stuff like this:
>
> write "prompt >"
> read answer
> if answer is correct
> do it
> else
> redo
I think we all agree then: continuations are the way to go.
I think we all need to thank Ovidiu for bringing this on the table. :)
[snip]
> > In fact, for flow-driving semantics, I'd far prefer a ECMAScript-like
> > syntax because it would be
> >
> > a) less verbose than XML
>
> Verbosity isn't always bad (even in the programming concern).
Agreed.
> If you can
> force some verbosity it can make things look much clearer. I remember
> reading books from famous people like Niklaus Wirth where variables in
> his samples where single letter names :(. XML elements and attribute can
> force you to use verbose names which is a huge win IMO.
well, nothing *forces* you to do this, even for XML. as you could write
obfuscated java code as
public class A extends B implementcs X,Y,Z {
public void a(String b) {
return b;
}
}
you could write obfuscated XML schemas such as
<a>
<b>
<c d="..."/>
<d><e>blahblah</e></d>
</b>
</a>
To tell you the truth, having XSLT, it's much easier to obfuscate XML
than Java :)
So, I agree that "good" verbosity it's a good thing since improves
redability, but I disagree that the XML syntax helps you on this.
The only thing that imposes is the context in the closing brackets.
Something that neiter C/C++/C#/Java/ECMAScript nor Scheme nor Python nor
Perl do. (it's only suggested as good programming practice, but since
the compiler doesn't care, neither developers do.
> > b) generally more readable (consider escaping <,>,& or using CDATA)
>
> To be honest, IMO this isn't a big issue. You can always choose
> alternatives as many popular languages are using like lt, gt, and, etc.
> (which makes them even more readable).
Good point, but the problem is 'mindset fit', not *general readability*.
If you had to present something to non programmers, probably
<select>
<when test="$(value) grater than ${limit}">
...
</when>
<otherwise>
...
</otherwise>
</select>
could still be written as
if $(value) is greater than $(limit)
...
else
...
but then, since this is targetted to programmers, they question would
be: why in hell they had to invent this stupid syntax? I would have
written it as (modulo coding conventions)
if (value > limit) {
...
} else {
...
} // (value > limit)
which is much clearer for programmers and gives closing context (even
XML, in this case, doesn't give closing context since the context is an
attribute and you don't have to declare the closing of attributes).
XSLT shows pretty evidently that mixing programming constructs with
markup it's too hard for HTML designers. It doesn't fit in their
mindsets. (I think many of you have come to know this the very hard way)
> > c) easier to learn/use/understand for C/C++/C#/Java/JavaScript people
> > (a very big percentage of the web tech population nowadays)
>
> The "web tech population nowadays" understand HTML as well so this can't
> be an issue.
Oh, I wish you were right on this: resonating with a syntax is a
necessary step for anyone to come close enough to something to learn it
(reason why I tried several times to learn Perl but failed every single
time: there must be some elegance someplace, but the orrible syntax
hides it to me).
But then you journey just began.
Again XSLT is a perfect example: you have to know HTML syntax (and
that's easy nowadays), but you have to grasp basic programming
constructs (selection/choice, variables, queries, expansions, precise
syntax) and then you have to understand hard-core programming concepts
as (nested recursion, event driven programming, inheritance,
multi-dimensionality).
Let me give you an example of this: here is a view of XSTL from a web
designer perspective:
1) XML is HTML with lowercase tag names, attributes with obligatory
quotes "" and empty tags explicitly indicated. [It takes a while, but
this is not an obstacle at all. Rather the opposite, when they learn it,
they go back in writing XHTML for coherence]
2) XML elements have prefixes that indicate what they do. for some
strange reasons, they have URLs associated with them, but those pages
don't exist.
3) xsl:templates are like SSI upside-down: instead of indicating in the
page what to include, we list all inclusions in the stylesheet so that
we can reuse them over many pages. [when they get this, they love it, if
they know CSS, the concept is ever more immediate (sort of IoC for web
designers)]
So far, so good. The hard part comes now.
4) you have to indicate *what* to change and you use XPaths to indicate
that. Just like you use paths to indicate images and such. Once they see
an XML document as a tree, they associate it with a file system tree.
Result:
- simple xpaths are not a problem
element
element/subelement/element
../element
/element
- more complex xpaths take a while but can be learned
element/@attribute
- selective xpaths hit a wall
element[@attribute > "20"]
Your mileage may vary, but conditionals seems to be hitting a cognitive
wall.
My personal perception is that conditionals are explicitly procedural
constructs and the great majority of the people hasn't been trained to
think procedurarely since the world is event driven (when something
happens, do this).
In fact, the <xsl:select> construct is easier to understand, once you
explain it to them. The problem is that they rarely can "rotate" their
declarative cognitive space into a procedural one, by 'atomizing' the
selection concepts.
I know it's absurd for us: we even "enjoy" doing this. It's like trivia
every time.
Buf for them is hard.
5) if you present them a stylesheet already written, they can
understand almost anything: complexity of the template markups doesn't
influence their judgement because they are used to grasp the important
parts of a page inside tons of verbose HTML.
everything *but* xsl:apply-templates
I couldn't find a way to teach the concept of apply-templates that could
resonate with them, probably because the concept of explicit recursion
is too far away from their mindsets (in fact, XSLT xsl:apply-templates
is very close to Scheme call-with-current-continuation, if you think
about it!)
Well, this should not surprise you: even Jon Stevens (which I personally
consider a great programmer) wrote Anakia because he didn't like the
declarative-way of programming XSLT and resulted in performing a bunch
of explicit iterations over JDOM instead of letting the processor call
your templates.
But I have the impression that is not declarativity that shocks (in
fact, the concept of templates wasn't hard to teach), it's
xsl:apply-templates. It's like a jump in hyperspace for them: you
disappear here and you end up someplace else. The incoming document
drives your trip around those hyperspace jumps inside your stylesheet.
You clearly need a very abstract way of thinking to be able to do this.
In fact, it was a lot easier to teach XSLT to a friend of mine that
studies physics but had no previous web experience (just a few personal
HTML pages) than it was to my girlfriend who studied art and drawing but
has been designing web pages web since '95. The results are striking:
while he became an XSLT master in a few months (so much so that Gianugo
hired him instantly :) but required the resulting HTML to 'mount' it, my
girlfriend is able to adapt the included HTML in a stylesheet that
somebody else wrote (me), but she can't write one herself (yet, at
least, but I strongly doubt she will find pleasure in doing it, due to
cognitive friction).
I can tell you for sure, that both couldn't have used DSSSL because the
unknown syntax would have been too much of a gap for them.
So, results:
1) the syntax should be tuned for the cognitive needs of those who work
on it: since there are two kind of people working on XSLT (those who
write the skeleton and those who write the included content) the XML
syntax works because the first group can adapt better than the second.
[This has lead me to believe that even XSLT has the same problem of XSP
regarding concern overlap since the xsl: namespace could be seen as
'logic' and the rest as 'content'. Maybe, the concept of taglibs could
be inverted for XSLT as well.... something for the future]
2) the syntax is only the first step: just like nice-looking web sites
are likely to attract more people than poor-looking ones, it's the
functionality that will bring them back.
In this context, syntax must be friendly enough not to scare people away
(unlike Perl, for example) but it's the semantics that should be
rewarding and makes somebody like a language (just like Perl: oh, how
much I wish I could jump over that huge entry gap that is its syntax for
my eyes!)
> > At the same time, for global site-mapping semantics, the XML syntax is
> > still the way to go.
>
> This is a big +1 for me. After seeing the way how Ovidiu's proposals in
> the scatchpad area defines pipelines in a Scheme/Lisp syntax I strongly
> propose to stay with what we have in the sitemap today. The introduction
> of map:call elements into the sitemap and the proposals from Berin
> to separate pipeline definitions from mapping show
> IMO a clear way where to go.
I tend to agree here: the use of XML for the sitemap seems to be a more
friendly look for the underlying semantics.
> > > --
> > >
> > > I think with the new model, there's no need for actions, redirects and
> > > other things that the sitemap currently has.
> >
> > Yes, I've always expressed my feeling that Actions were hacks.
>
> :) They aren't hacks, the are only in the wrong context because of lack
> of alternative places to place them.
Ok, granted :)
> Redirection was introduced to reduce frition to visitors when web
> masters had to reorganize their sites. Nowadays web programmers use it
> as a natural *feature* for web programming (which is as Stefano
> mentioned somewhere similar to GOTO programming).
>
> BTW this concept isn't new since servlets. I remember old days where one
> wrote programs for the IMS/DC Online Transaction Monitor which had the
> exact same approach (including mechanisms like servlet chaining but not
> redirect as this isn't a feature character terminals had unlike
> browsers)
>
[snip]
> > Giacomo knows that I never really liked this approach, but I didn't stop
> > the effort because I wasn't able to provide a more elegant solution.
>
> I have to make this clear, I've choosen the scratchpad concept than and
> was forced to move it to the main trunk by the community because of lack
> of alternatives.
Granted as well. Please, understand that I don't have anything against
actions: they are powerful and users like them. But I think we can come
up with a more elegant solution than this and this is what I think we
should aim to reach.
> > Interesting enough, what you described in your above example is exactly
> > the kind of 'flowmap' that I've been looking for in order to move away
> > actions from the sitemap.
>
> I have no objections to this :)
All right. Then we have a clear direction to follow, which is a great
thing indeed! :)
> > I knew that the intrinsic 'wait for request' behavior of the site forces
> > the sitemap to follow a declarative approach, as much as the 'drive the
> > flow' behavior of a web application would force the flowmap to follow a
> > more procedural approach.
>
> Agreed.
>
> > Even more: since the sitemap might be written by people used to publish
> > information and documents, the XML syntax is more suited for their
> > skillset. At the same time, since the flowmap is written by people used
> > to write programming languages, a java-like syntax is better suited for
> > their skillset.
>
> Still not sure about that. XML can be easier parsed and validated and
> thus forced to what ever we like it to be (concerning verbosity).
Hold on a sec: no problem if you aren't sure about which syntax would be
best for a flowmap (I still have doubts myself and want to see working
examples before deciding where to go), but your arguments don't count
that much on this concern.
Java is parsed by a compiler, syntax well-formeness is checked, then
validation is performed on all the external class mappings. But still
NPE are the biggest problem to java debugging (at least, poorly written
code).
Interpreted languages, lack the compile-time validation phase (granted!)
and are likely to introduce more run-time problems, but they reduce the
try/fail/recode/retry cycle time and increase 'what if' kind of
programming.
Many people complained about the high latency of sitemap changes that
reduces the try/fail/retry production cycles and validating the sitemap
might remove issues with tag mispelling, but will not remove problems
such as class-not-found or more internal errors.
So, I believe the argument about XML validativity is a very weak point
for flowmap syntaxes.
> > In this vision, Berin's proposal to make pipelines reusable by adding
> > variable substitution might allow both sitemap and flowmap to use sort
> > these pipeline definitions (pipemaps?) and reduce overall verbosity.
>
> Big +1.
>
> > Anyway, I think that by trying to prove the Flowmap concept wrong,
> > Ovidiu gave us the best example of a flowmap in terms of syntax
> > (code-based instead of XML-based) and functionality (continuations-based
> > instead of FSM-based).
>
> code-based: +0
> continuation-based: +1
ok.
> > > If you need to describe logic, you do it using the language. This
> > > describes which pages are sent in what order. When you want to
> > > generate a result, you call send-page() with the source document, a
> > > pipeline definition that should process your document, and additional
> > > data to be used in generating the source page dynamically.
> > >
> > > To generate the source document, it's better if we use a markup
> > > language that prevents users from doing computations in the page. The
> > > page should be generated only from data passed to the pipeline by
> > > send-page(). I haven't used it before, but Velocity seems to be a good
> > > fit for this, as it doesn't allow any embedded processing in the page.
> >
> > Since Cocoon content will always be XML-ized, I see two possible
> > solutions here:
> >
> > 1) use XML-orthogonal solutions (Velocity)
> >
> > <p>Today is ${date}</p>
>
> -0 it mixes too much IMO.
>
> > 2) use XML-namespaced solutions
>
> +1 this is what XSP wanted to force.
>
> > <p>Today is <dxml:date/></p>
I have mixed feelings about this myself. Again, we'll propose the two
different solutions and let the community decide what to do.
> > Again, the semantics are exactly the same, but the first approach if
> > more friendly to code writers, the second to HTML writers. We could even
> > have both and let the user decide which one he/she like the best.
>
> FS
might be, I know, but I'm not sure at this point.
> > > With this model we have the clear separation of concerns. Each layer
> > > does only the things it's supposed to do, in a clean way.
> >
> > Absolutely:
> >
> > sitemap -> handles the stateless needs
> > flowmap -> handles the statefull needs
>
> pipemap -> handles the resources needed
Good. Should we start from describing pipemap semantics, then?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
