Andy Wardley writes:
> Yep, I agree.

Now we are getting somewhere. :-)

The issue here is not whether TT is a bad approach, but rather why the
syntax is not Perl.  It doesn't have to be, but you would save
yourself a lot of code and debugging.  In addition, there is more
opportunity for reuse if you can just say:

use Bla::Bla;

And, reuse test infrastructure, syntax-directed editors, etc.

Chris writes:
> Perl handels Regex's better than C, this is one of the reasons people use 
> Perl.

I disagree.  Perl's Regex processor is written in C.  The difference
is that it has outgrown Henry Spencer's regexp library.

> It makes (some) hard things easy and (some) impossible things 
> hard ... within it's domain. XSLT is no different. Use the appropriate tool 
> (or Toolkit) for the problem.

Agreed.  Perl is good at text manipulation.  It is imiho superior to
XSLT in all spaces which XSLT claims to solve.  Once you have an XML
parse tree in Perl, it's trivial to write a translator to any format
more correctly than XSLT.  My favorite example is XML to CSV.  Every
example I've seen in XSLT is cumbersome and wrong.  You'd think it
wouldn't be hard, but try it. ;-)

> existance beyond the Towers of Hanoi problem. But I haven't seen it solved 
> in TeX either (::know's there's gotta be a link for this::).

I'm sure Randall wrote a TeX to TT translator to generate his TT
version of ToH. ;-)

> Rob, is what you are suggesting that one should not use a turing complete 
> language for visual markup or that simply the language should be the best 
> match for the solution? I'm just looking for clarity on your position.

The question really surrounds "little languages".  Perl is ideally
suited to creating them.  There's no reason to invent a new syntax ([% %])
or semantics for standard structures.  I think you should write
classes in Perl that map to some interface which defines the language.

Here's another example, trimmed from our Integer.t:

Bivio::Test->unit([
    'Bivio::Type::Integer' => [
        get_min => -999999999,
        get_precision => 9,
        can_be_negative => 1,
        from_literal => [
            ['9'] => [9],
            ['x'] => [undef, Bivio::TypeError->INTEGER],
            [undef] => [undef],
        ],
    ],
]);

What does this do?  It "compiles" the list of tests and then executes
them.  It makes for very dense unit tests.  Perl's powerful
introspection mechanisms allow you to do this.

> benefit I have gained thus far from Perrin's eToys article (that and using 
> it to sell mod_perl to my superiors as a better solution than Java "eToys 
> delt with 10x these many customers ... I think our system can handle the 
> load").

It's pretty much gotten to the point where nobody gets fired for
choosing Java.  I've lost many contract bids because I didn't say Java
was the right solution.  I haven't lost a single customer who let us
solve the problem for them.

Perrin Harkins writes:
> In the companies I've worked for, it seems that political pressures 
> cause an HTML re-design every few months.

Weinberg strikes again: It's always the people problem...

> I also notice that bivio.com has a relatively clean and simple design. 
> If it were up to me, all "application" sites would have this kind of 
> simple design, but more often than not I seem to end up with designers 
> who are determined to take their interface cues from H R Giger prints.

Giger is awesome.  We need to work him into bivio.

A significant difference between our worlds may be that we're selling
a web-delivered application.  I'm guessing that your businesses were
more focused on selling products via the Web.

> (http://sourceforge.net/projects/poop/).

Great, another mailing list. :-)  Thanks.

Rob


Reply via email to