Re: Comments on XSP 1.1 (long)

[Matt Sergeant <ma...@sergeant.org>]

On Tue, 31 Oct 2000, Stefano Mazzocchi wrote:

> True, logicsheets are written by programmers, but how many programmers
> are confortable with inlining code into XSLT stylesheets? how many
> programmers like to write their own SAX filter to create code that is
> futher compiled?
> 
> SLL glues markup and OO code. If you think you don't need it for Perl,
> well, no problem, but are you sure all your joe perl programmers are
> able to handle nested taglibs with no hassle?
> 
> If so, well, I can't wait for Perl 6 to come out so that I can compile
> it on a JVM and use it inside my XSP :)
> 
> But, for now, I believe SiLLy (despite its name) is a very clever
> approach for markup-java logic connection.

I think though that there's a better middle ground to be struck here. I
don't know what it is or where it is, but SiLLy seems too verbose at the
moment. I wish I could say more about what I think that middle ground is
or should be, but I can't - I'm really just saying that I personally
wouldn't be happy working at a company writing logic sheets using the
lingo supplied in the example. It seems to make things easier for *Cocoon*
(or AxKit or whatever), but not for the developer...

PS: Don't hold your breath for Perl6 :-)

-- 
<Matt/>

    /||    ** Director and CTO **
   //||    **  AxKit.com Ltd   **  ** XML Application Serving **
  // ||    ** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // **     Personal Web Site: http://sergeant.org/     **
     \\//
     //\\
    //  \\

Re: Comments on XSP 1.1 (long)

[Stefano Mazzocchi <st...@apache.org>]

Matt Sergeant wrote:
> 
> On Wed, 1 Nov 2000, Stefano Mazzocchi wrote:
> 
> > Let's try to come up with an example:
> >
> > 1) you are asked to write a taglib that has to be nested with a number
> > of taglibs that are not written by you.
> >
> > 2) suppose these other taglibs are written in XSLT+Java (no SLL or
> > anything), and you don't have documentation for them (like it is today)
> >
> > What do you do?
> >
> > Like many people here can guarantee, you try to see what the rest of the
> > taglibs do and try to come up with a resonable way to inline code that
> > works.... after a few hundred attempts, it does what you want and you
> > are happy.
> >
> > Then, the taglib grows and it has to be refactored.. new people work on
> > it, people that are not used to XSLT+Java, neither to your own vision of
> > "how to make a taglib". The code is refactored, rewritten, it costs more
> > to refactor it than to write a new taglib from scratch.
> >
> > Result: costs grow more than linearly and saturation happens. You can't
> > have more than N taglibs developped by your team and after a few years
> > they become black boxes... it's easy to throw them away than to see what
> > they do and how.
> 
> I totally understand all the issues, Stefano. Really I do. I just think
> there's probably a better syntax out there (maybe even an XML syntax). I
> know thats probably really unfair since I haven't personally put any
> effort into SiLLy, so lets get the xsp list setup and hash out something
> simpler.

Ok, great, if only I can find a damn person that knows how to set up a
mail list around here, damn it!
 
> > Perl people normally don't care about code management costs: they just
> > want to get their job done and it's not their fault if nobody else will
> > ever be able to manage it.
> >
> > But everyone knows that software management costs are *much* more than
> > the costs of creating the software at the beginning. SLL also tries to
> > provide hooks to reduce taglib management costs in the long run.
> >
> > If you don't care for it, then you should use it, but like OOP teaches
> > you, every moment you spend in designing an elegant and solid
> > architecture is a moment you save in the future.
> >
> > Larry Wall doesn't understand why europeans care so much about code
> > elegance...
> 
> I think all these statements are a bit unfair and sweeping really. Perl
> people are just programmers. We care about code maintainence and elegance
> just as much as the next person. Some would argue we care about elegance a
> whole lot more than other languages, but lets not go there on this list.

In "http://dev.perl.org/~ask/als/larry-als.txt", Larry Wall said:
>> "Users care about elegance."  No, they care about getting their job
>> done.  For some reason lots of languages that come out of Europe have
>> this thing about elegance that I don't quite get.  Obviously.

Let's see how you get out of this :)

> > but he never wrote an operating system in Perl :)
> 
> You've not heard of PerlOS then? Seriously, there is an OS written in
> Perl, providing most Unix features. Of course its not exactly fast - it
> was just done for fun and as a proof of concept.

does "providing most Unix features" include support for a gazillion
device drivers and all that stuff? I don't think so.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------

Re: Comments on XSP 1.1 (long)

[Matt Sergeant <ma...@sergeant.org>]

On Wed, 1 Nov 2000, Stefano Mazzocchi wrote:

> Let's try to come up with an example:
> 
> 1) you are asked to write a taglib that has to be nested with a number
> of taglibs that are not written by you.
> 
> 2) suppose these other taglibs are written in XSLT+Java (no SLL or
> anything), and you don't have documentation for them (like it is today)
> 
> What do you do?
> 
> Like many people here can guarantee, you try to see what the rest of the
> taglibs do and try to come up with a resonable way to inline code that
> works.... after a few hundred attempts, it does what you want and you
> are happy.
> 
> Then, the taglib grows and it has to be refactored.. new people work on
> it, people that are not used to XSLT+Java, neither to your own vision of
> "how to make a taglib". The code is refactored, rewritten, it costs more
> to refactor it than to write a new taglib from scratch.
> 
> Result: costs grow more than linearly and saturation happens. You can't
> have more than N taglibs developped by your team and after a few years
> they become black boxes... it's easy to throw them away than to see what
> they do and how.

I totally understand all the issues, Stefano. Really I do. I just think
there's probably a better syntax out there (maybe even an XML syntax). I
know thats probably really unfair since I haven't personally put any
effort into SiLLy, so lets get the xsp list setup and hash out something
simpler.

> Perl people normally don't care about code management costs: they just
> want to get their job done and it's not their fault if nobody else will
> ever be able to manage it.
> 
> But everyone knows that software management costs are *much* more than
> the costs of creating the software at the beginning. SLL also tries to
> provide hooks to reduce taglib management costs in the long run.
> 
> If you don't care for it, then you should use it, but like OOP teaches
> you, every moment you spend in designing an elegant and solid
> architecture is a moment you save in the future.
> 
> Larry Wall doesn't understand why europeans care so much about code
> elegance...

I think all these statements are a bit unfair and sweeping really. Perl
people are just programmers. We care about code maintainence and elegance
just as much as the next person. Some would argue we care about elegance a
whole lot more than other languages, but lets not go there on this list.

> but he never wrote an operating system in Perl :)

You've not heard of PerlOS then? Seriously, there is an OS written in
Perl, providing most Unix features. Of course its not exactly fast - it
was just done for fun and as a proof of concept.

-- 
<Matt/>

    /||    ** Director and CTO **
   //||    **  AxKit.com Ltd   **  ** XML Application Serving **
  // ||    ** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // **     Personal Web Site: http://sergeant.org/     **
     \\//
     //\\
    //  \\

Re: Comments on XSP 1.1 (long)

[Stefano Mazzocchi <st...@apache.org>]

Matt Sergeant wrote:
> 
> On Tue, 31 Oct 2000, Stefano Mazzocchi wrote:
> 
> > True, logicsheets are written by programmers, but how many programmers
> > are confortable with inlining code into XSLT stylesheets? how many
> > programmers like to write their own SAX filter to create code that is
> > futher compiled?
> >
> > SLL glues markup and OO code. If you think you don't need it for Perl,
> > well, no problem, but are you sure all your joe perl programmers are
> > able to handle nested taglibs with no hassle?
> >
> > If so, well, I can't wait for Perl 6 to come out so that I can compile
> > it on a JVM and use it inside my XSP :)
> >
> > But, for now, I believe SiLLy (despite its name) is a very clever
> > approach for markup-java logic connection.
> 
> I think though that there's a better middle ground to be struck here. I
> don't know what it is or where it is, but SiLLy seems too verbose at the
> moment. I wish I could say more about what I think that middle ground is
> or should be, but I can't - I'm really just saying that I personally
> wouldn't be happy working at a company writing logic sheets using the
> lingo supplied in the example. It seems to make things easier for *Cocoon*
> (or AxKit or whatever), but not for the developer...

Ok, the fact that you wouldn't like to work for a such company is a
serious concern.

Let's try to come up with an example:

1) you are asked to write a taglib that has to be nested with a number
of taglibs that are not written by you.

2) suppose these other taglibs are written in XSLT+Java (no SLL or
anything), and you don't have documentation for them (like it is today)

What do you do?

Like many people here can guarantee, you try to see what the rest of the
taglibs do and try to come up with a resonable way to inline code that
works.... after a few hundred attempts, it does what you want and you
are happy.

Then, the taglib grows and it has to be refactored.. new people work on
it, people that are not used to XSLT+Java, neither to your own vision of
"how to make a taglib". The code is refactored, rewritten, it costs more
to refactor it than to write a new taglib from scratch.

Result: costs grow more than linearly and saturation happens. You can't
have more than N taglibs developped by your team and after a few years
they become black boxes... it's easy to throw them away than to see what
they do and how.

Perl people normally don't care about code management costs: they just
want to get their job done and it's not their fault if nobody else will
ever be able to manage it.

But everyone knows that software management costs are *much* more than
the costs of creating the software at the beginning. SLL also tries to
provide hooks to reduce taglib management costs in the long run.

If you don't care for it, then you should use it, but like OOP teaches
you, every moment you spend in designing an elegant and solid
architecture is a moment you save in the future.

Larry Wall doesn't understand why europeans care so much about code
elegance... but he never wrote an operating system in Perl :)
 
> PS: Don't hold your breath for Perl6 :-)

I know, but it's good to know integration will be easier when it comes
:)

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------