Re: User Design Issues, principle, and the whole philosophy (who is your customer, anyway?

[Dave Glowacki <dg...@ssec.wisc.edu>]

Jon Stevens wrote:
> on 9/1/2000 2:05 PM, "Dave Glowacki" <dg...@ssec.wisc.edu> wrote:
> 
> > Jon, I basically agree with your main point, however you didn't answer
> > my previous message on #begin and #end being more mnemonic than
> > { and }, and here you refer to them as "feature crap".
> 
> My point that has also been ignored is that if you had never heard of
> #begin/#end, would you have thought of adding them?

Yes, I took Pascal back in college :-)

But why does my linguistic inventiveness have any bearing on the
usefulness of #begin...#end?

> > How do you see them as features when they don't add anything to
> > the feature set of the language,
> 
> The are a "feature" from the point of view that they didn't exist in the
> first version of WM.

Is the official target for Velocity, only the features present in
WebMacro 0.75?

> > but merely make the language
> > a bit more friendly for non-C programmers?
> 
> I don't necessarily agree with that.
> 
> For instance, is there a case where you would use {} over using #begin/#end?
> Maybe if you are doing a lot of #if statements or something like this:
> 
> <input type="radio" name="jon" #if ($foo) { checked }>
> or
> <input type="radio" name="jon" #if ($foo) #begin checked #end>
>
> I think that the {} is much more readable because the #begin #end start to
> look like it belongs in the HTML vs. looking like it belongs in the template
> language.

I personally prefer to keep the logical bits in obvious places,
rather than embedding them too deeply inside the HTML.  I might
write the above as:

  #if (foo)
  #begin
  #set $jonChecked = "checked"
  #end
  <input type="radio" name="jon" $jonChecked>

I don't, however, recall anyone advocating that {} be *replaced*
with #begin...#end.  They're merely alternatives.

> I guess my point is that we need to start using more examples in our
> descriptions vs. what we "think" might be better or worse for people. If we
> come up with use cases, then it would be interesting to find out what people
> think of it.

Unfortunately, {} and #begin...#end are used in exactly the same way.
{} is the concise form, #begin...#end is the verbose (and more easily
remembered) form.  I don't see how use cases would help here.

> Since I'm a co-founder and share holder in a 130 person web design shop that
> has been around for 5 years now, I will ask what they think about this issue
> and get back to you. :-)

Of course, since you're a co-founder you may have slightly influenced
the opinions of those people, so that probably wouldn't be of much
value as an objective viewpoint :-)

What I'm trying to get at is that I see value in having both {}
and #begin...#end, and I haven't seen you make a case for
why *both* can't be present.

Re: User Design Issues, principle, and the whole philosophy (whois your customer, anyway?

[Jason van Zyl <jv...@periapt.com>]

On Fri, 8 Sep 2000, Stefan Mainz wrote:

> Jon Stevens wrote:
> > 
> > on 9/1/2000 3:08 PM, "Jon Stevens" <jo...@latchkey.com> wrote:
> > 
> > > Again, I think that having alternatives in the language is a bad thing. It
> > > isn't definite enough and in this case doubles the amount of things that
> > > people need to be aware of.
> > 
> > Perl is another bad case of this.
> > 
> > In my opinion, having more than one way to do the same thing isn't necessary
> > a good thing. It makes for code that is readable by one person, but not
> > necessarily readable by another.
> 
> I totally agree with you Jon. Having more twan one syntax for a block
> does confuse
> users. We switched to use the #begin # end syntax just because it is
> more readible
> in templates and conforms more to the syntax of the other directives in
> webmacro.
> 
> Personally i would like to have implicit blocks like someone suggested
> #if .. #end.
> 
> If the parsers are plugable we could have one for each syntax. 

That's exactly what we're doing right now!

> The
> interpreter part
> does not need to know the syntax of a block to interpret it if it is
> given an tree
> to work on.

Yup, we are settling on an intermediate format for the parse
tree. All parsers will profer up a parse tree in the intermediate
format then the rest of the tools take over. So anyone who
creates a parser can take advantage of the rest of the
tools in velocity. You could make your own syntax if
you like! I don't really recommend that, but you could :-)

jvz.

-- 

Jason van Zyl
jvanzyl@periapt.com

Re: User Design Issues, principle, and the whole philosophy (whois your customer, anyway?

[Stefan Mainz <St...@Dynaware.de>]

Jon Stevens wrote:
> 
> on 9/1/2000 3:08 PM, "Jon Stevens" <jo...@latchkey.com> wrote:
> 
> > Again, I think that having alternatives in the language is a bad thing. It
> > isn't definite enough and in this case doubles the amount of things that
> > people need to be aware of.
> 
> Perl is another bad case of this.
> 
> In my opinion, having more than one way to do the same thing isn't necessary
> a good thing. It makes for code that is readable by one person, but not
> necessarily readable by another.

I totally agree with you Jon. Having more twan one syntax for a block
does confuse
users. We switched to use the #begin # end syntax just because it is
more readible
in templates and conforms more to the syntax of the other directives in
webmacro.

Personally i would like to have implicit blocks like someone suggested
#if .. #end.

If the parsers are plugable we could have one for each syntax. The
interpreter part
does not need to know the syntax of a block to interpret it if it is
given an tree
to work on.

Stefan
-- 
Dynaware Systemberatung GmbH                 Tel: +49 89
743130-15                 
Am Westpark 7                                Fax: +49 89
743130-05            
81373 Müchnen                                mobil: +49 171
6920761               
http://www.dynaware.de                      
mailto:Stefan.Mainz@Dynaware.de

Re: User Design Issues, principle, and the whole philosophy (who is your customer, anyway?

[Jon Stevens <jo...@latchkey.com>]

on 9/1/2000 3:08 PM, "Jon Stevens" <jo...@latchkey.com> wrote:

> Again, I think that having alternatives in the language is a bad thing. It
> isn't definite enough and in this case doubles the amount of things that
> people need to be aware of.

Perl is another bad case of this.

In my opinion, having more than one way to do the same thing isn't necessary
a good thing. It makes for code that is readable by one person, but not
necessarily readable by another.

-jon

-- 
http://scarab.tigris.org/    | http://noodle.tigris.org/
http://java.apache.org/      | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/       | http://www.sourcexchange.com/

Re: User Design Issues, principle, and the whole philosophy (who is your customer, anyway?

[Jon Stevens <jo...@latchkey.com>]

on 9/1/2000 2:46 PM, "Dave Glowacki" <dg...@ssec.wisc.edu> wrote:

> Yes, I took Pascal back in college :-)

So did I. I took a year in college and high school. I still hate that
language.

> But why does my linguistic inventiveness have any bearing on the
> usefulness of #begin...#end?

Because it isn't useful. As you said, it is simply a mnemonic and those
generally tend to add confusion to things. Users who see portions of the
page containing {} and other portions of the page containing #begin/#end are
going to get confused by a syntax they may or may not understand.

>>> How do you see them as features when they don't add anything to
>>> the feature set of the language,
>> 
>> The are a "feature" from the point of view that they didn't exist in the
>> first version of WM.
> 
> Is the official target for Velocity, only the features present in
> WebMacro 0.75?

You are missing the point.

>>> but merely make the language
>>> a bit more friendly for non-C programmers?
>> 
>> I don't necessarily agree with that.
>> 
>> For instance, is there a case where you would use {} over using #begin/#end?
>> Maybe if you are doing a lot of #if statements or something like this:
>> 
>> <input type="radio" name="jon" #if ($foo) { checked }>
>> or
>> <input type="radio" name="jon" #if ($foo) #begin checked #end>
>> 
>> I think that the {} is much more readable because the #begin #end start to
>> look like it belongs in the HTML vs. looking like it belongs in the template
>> language.
> 
> I personally prefer to keep the logical bits in obvious places,
> rather than embedding them too deeply inside the HTML.  I might
> write the above as:
> 
> #if (foo)
> #begin
> #set $jonChecked = "checked"
> #end
> <input type="radio" name="jon" $jonChecked>
> 
> I don't, however, recall anyone advocating that {} be *replaced*
> with #begin...#end.  They're merely alternatives.

Again, I think that having alternatives in the language is a bad thing. It
isn't definite enough and in this case doubles the amount of things that
people need to be aware of.

>> I guess my point is that we need to start using more examples in our
>> descriptions vs. what we "think" might be better or worse for people. If we
>> come up with use cases, then it would be interesting to find out what people
>> think of it.
> 
> Unfortunately, {} and #begin...#end are used in exactly the same way.
> {} is the concise form, #begin...#end is the verbose (and more easily
> remembered) form.  I don't see how use cases would help here.

Use cases will reveal what people prefer to use.

>> Since I'm a co-founder and share holder in a 130 person web design shop that
>> has been around for 5 years now, I will ask what they think about this issue
>> and get back to you. :-)
> 
> Of course, since you're a co-founder you may have slightly influenced
> the opinions of those people, so that probably wouldn't be of much
> value as an objective viewpoint :-)

I don't work there anymore and I actually don't even know half of those
employees.

> What I'm trying to get at is that I see value in having both {}
> and #begin...#end, and I haven't seen you make a case for
> why *both* can't be present.

See above.

-jon

-- 
http://scarab.tigris.org/    | http://noodle.tigris.org/
http://java.apache.org/      | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/       | http://www.sourcexchange.com/