velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Dekany <ddek...@freemail.hu>
Subject Re: What's the ideal syntax? Was: [ANN] Viento - WHY?
Date Sat, 08 Oct 2005 23:56:31 GMT
Saturday, October 8, 2005, 10:43:57 PM, Jason Pettiss wrote:

> Take HTML as the ultimate liberal markup language and then look at its
> popularity with the general public.

Of course it is 100% popular since people had no choice. A lot of people
needs to create web pages, and they practically must use HTML, and all
the broken browsers. (And is it good that most of the HTML-s on the net
are broken? In general, can we call the state of Web design world good?
No, it's really a big chaos...)

And again:

  popular != good

It's like most people like to eat a lot, and then they will be fat like
pigs and sick and everything. So although eating a lot is popular, you
still wouldn't recommend it to your loved ones, right?

> You often don't need to close your elements, casing doesn't matter,
> invalid content is quietly ignored, and you can even bungle the

And after learning from all of this, what is the direction of the IT
world? XML, XHTML. I.e. you must explicitly close all elements, and case
does mater. And I think browser will become more draconic too, at least
as far as they get XHTML with the proper MIME type.

> nesting and most browsers will display everything close to what the
> user intended. Very popular, user friendly.

I think these are false friends... People like to sweep under the carpet
as I said, but they eventually just lose with that, on the long run at
least. Just they don't recognize it. Again, it's like you will like the
people who don't tell you anything negative (because they are polite and
like).

> A total headache for the
> browser engineer. You want an example of a liberal programming
> language this is incredibly popular and usable by non-programmers?
> Javascript.
>
> I mean I hear you-- debugging these things and *proving* they are 
> correct is difficult, sometimes impossible.  Fortunately if you've got a
> language that's usable with little skill and a lot of trial and error--
> no big fat error messages, no explosions, no need to check logs or 
> understand parser error messages or count line numbers-- then you the 
> developer have just saved yourself a LOT of boring monkey work.  Because
> you can hire monkeys to do it for you.  And the more the monkeys can 
> figure it out by just banging away on the keyboard, the less you get 
> interrupted from the FUN stuff-- "real" coding with "real" languages 
> that DO blow up in your face and demand perfection from you.

You think the template authors will solve the problems alone, if instead
of getting error messages they get whatever arbitrary behavior. I think
rather the opposite is true. Well, yes, assuming that the error messages
are helpful and are displayed right in the browser window, but this can
be expected from any serious template engine.

> Most people psychologically can't deal with compiler errors. They need
> to see constant forward motion, or they get discouraged. They see a
> page, with colors, pretty pictures, and a few stray $userName's,
> they're happy. They go fix those, and they see less stray $fooBars,
> they're happy. If any time they have things wrong on the page, they
> don't see their page-- instead they see a dry listing of errors...
> no... that just doesn't fly... they get frustrated reeeeeal quick...

Yeah, sure. People are psycho. Just, although building on the top of
human stupidity is a winner strategy if you measure success with
popularity, it's not necessary a good strategy if you want something
that *works* better.

-- 
Best regards,
 Daniel Dekany

 
> --jason
>
> Daniel Dekany wrote:
>
>>Saturday, October 8, 2005, 8:13:15 AM, Jason Pettiss wrote:
>>
>>  
>>
>>>It's an interesting question... I guess it's a tradeoff between syntax
>>>stability and error robustness.  The former favors smart users who are
>>>used to dealing with the absolutes imposed by programming languages, the
>>>latter, artsy-fartsy types who honestly have trouble terminating html
>>>elements properly.
>>>    
>>>
>>
>>I'm not sure I understand what you mean. Which variation is for the
>>artsy-fartsy types? Because I say they are who need something that is
>>stupid-simple and damn strict. Because otherwise they will bungle the
>>templates all the way... Unlike a sophisticated programmer, who will
>>enjoy if he can do smart abbreviations like $foo instead of ${foo},
>>while he will not shoot itself on foo.
>>
>>  
>>
>>>JSP for example has absolute delimiters which are glaring (and ugly).
>>>You get one of those wrong, your whole page breaks fantastically, and
>>>without a nice error system or checking the logs, you won't know where
>>>the problem is.  Taglibs just make things worse because in a page that's
>>>designed to generate HTML they hide really well... and still even one
>>>mistake and BOOM!  Developers dislike it, artists fear it...
>>>
>>>Velocity needs just a single character most of the time, and it's very
>>>tolerant of mistakes.
>>>    
>>>
>>
>>That's actually rather a problem than a good feature. If I made mistake
>>I *want* a big error page into my face, rather than the error to hide.
>>Because if I have made a mistake then I have buggy template... hence it
>>should be fixed, right? Especially I want it for the "artsy-fartsy
>>types" because they *will* do a lot of mistakes, so let the template
>>engine help them by pointing out the mistakes, because they don't see it
>>themselves. If the template engine tries to suppress errors, that's a
>>maintenance and quality assurance nightmare.
>>
>>That JSP has ugly error pages... well, yes, that's a problem. BUT that's
>>not the question of the language design, that's the problem of the
>>currently widely used implementations. If you design a new template
>>language, just let assume you will not be that lame and can output
>>helpful error messages, "Dude, you have forgotten to close the tag
>>with %> at line 10, column 5 (<%if x === 1...etc.). Will you?"
>>
>>  
>>
>>>Most of the time it'll spit out a full page and the non-technical user
>>>can see exactly where they screwed up, and why.
>>>    
>>>
>>
>>Will they? If the error has really prominent effect 99% yes... But not
>>all errors are prominent (or even visible with certain input data
>>(context)). But if there is somewhere a $windowName.close() or
>>#elseWHITE literally printed in the middle of the markup, especially
>>into an attribute value or CSS that is not displayed directly... (Not to
>>mention the non-syntax related problem of an #if where the condition
>>always evaluates to false because of a typo like #if(usreLoggedIn)... I
>>just mention it because it's something related to strict VS loose error
>>handling approach.) And then consider later quick modifications to the
>>templates during maintenance, when the only checking is a quick look at
>>new output by a single people.
>>
>>  
>>
>>>This makes it very friendly for the user, and intuitive for most 
>>>purposes, but at the expense of having an absolute way to escape and 
>>>delimit...
>>>    
>>>
>>
>>But really, why is it friendly that if I write #forecah instead of
>>#foreach, then it will not be an error? I mean, this is what computers
>>are good at and people are bad at... finding stupid-mindless formal
>>mistakes like this. And then the computer doesn't help me? Yes, of
>>course I know why is it friendly. People likes to sweep problems under
>>the carpet. Ostrich policy. But I really belive it's a foolish habit of
>>people, and at the end they just lose with it. (It's bit like people
>>don't like those people who tell their mistakes into their face... they
>>rather like nice guys who always smile, no mater what.)
>>
>>  
>>
>>>which means sometimes the mechanism breaks down.  Typically
>>>this is just a minor annoyance to a non-technical user, who most of the
>>>time doesn't grasp the difference between dynamic and static content 
>>>anyway-- and so is using trial and error, and will do so here, to get
>>>over the little stumbling blocks imposed by a very liberal syntax.
>>>    
>>>
>>
>>There is some irony in calling a syntax to liberal because it has no
>>clear delimiters. Because, liberty means that you are free to do
>>something that you otherwise (if there is no liberty) you could not. And
>>what is that thing? Bungling templates without getting error. Well... I
>>don't know how is it in other countries, but it's a lot of analogy with
>>ultra-liberal political parties here: they want to let people do
>>whatever obviously bad, injurious thing. But nonetheless many people
>>want to do those things, so ultra-liberals are popular. Just,
>>popular != good.
>>
>>  
>>
>>>Due to the lack of reliable escaping, Velocity would break down entirely
>>>if the page being generated were, say... oh I dunno... another Velocity
>>>template!  Fortunately this is highly uncommon and I don't think it's
>>>the intention of the language.  Velocity also isn't well suited for 
>>>strict content where whitespace and newlines really matter-- like 
>>>certain WML--
>>>    
>>>
>>
>>No template language can be too good at that... Simply, the basic idea
>>of a template languages is incompatible with strict white-space control.
>>
>>  
>>
>>>but then again, JSP is pretty terrible at this too.  As a
>>>general purpose template language in a world awash with XML and HTML 
>>>lookalikes, Velocity does well.  If the web were composed of shell 
>>>scripts I am sure it wouldn't be as well accepted.
>>>    
>>>
>>
>>The thing why template engines with template engines syntax is much much
>>more important question that with other languages: it has to work well
>>together with another syntax. Now if what's the good template syntax
>>depends on what that other syntax is. But, there are template syntaxes
>>that are good almost for everything, like Template Toolkit's [% ... %]
>>for example. Still, obviously a template engine that is specialized on,
>>say, Java Language, will be the better for that than a more general
>>purpose template engine syntax. Life is full of dilemmas... I tend to
>>think that a template engine ideally should support multiple syntaxes.
>>
>>  
>>
>>>I do think there's got to be a way to get the flexibility and liberal
>>>syntax in the 90% scenario, yet have a way to reliably escape, delimit,
>>>control whitespace conventions, etc, in the "other" cases.  Also-- the
>>>template language I want also lets me choose the syntax markers and 
>>>define them in the content.  Then all I have to do is choose delimiters
>>>which don't appear that often in the page, and I'm always basking in the
>>>sunny 90% scenario... ;-)
>>>
>>>About the macro-with-body... that's really just two macros on either 
>>>side of some content, isn't it?
>>>    
>>>
>>
>>No. Consider (with a hypothetical template language):
>>
>><@macro foo>
>>  <@local x>
>>  <@set x = 1>
>>  <@doBody />
>>  <@set x = x + 1>
>>  <@doBody />
>>  ${x} <@-- 2 -->
>></@macro>
>>
>>What I meant to show is that you go back to the caller's context with
>>the <@doBody />, but still didn't lost the local context and whatever
>>local state (like the last instruction) of the foo macro. It can be very
>>convenient. Also, you was able to chose if for how many times do you
>>execute the body. Here it was executed twice (but most commonly it's
>>about conditionally not execution it at all or executing it once).
>>
>>  
>>
>>>Its nice to not have to remember to "close", but you have to do that
>>>with for loops and if statements and comments anyway, right?
>>>    
>>>
>>
>>Right, but what's then? You still want to do it your macros as well.
>>
>>  
>>
>>>--jason
>>>    
>>>
>>
>>  
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org


Mime
View raw message