* A. Pagaltzis <[EMAIL PROTECTED]> [2006-08-16 20:40]:
> Integration of heterogenous systems is much easier that way –
> even subsystems for which no explicit format emitter is
> available can participate without much trouble. You can easily
> scale the complexity of the participants at either end of the
> wire to match your needs.

Case in point: a rudimentary TAP library for Oracle PL/SQL.

http://use.perl.org/~jdavidb/journal/30641


* Adrian Howard <[EMAIL PROTECTED]> [2006-08-17 09:55]:
> You're right it can be a bonus. But to sell that to a group of
> people who already have something that works very well, is
> already integrated with their IDE, continuous integration
> package, build  system, etc. you've got a tough job ;-)

I think it’s likely to be a hard sell precisely because it’s bad
in the ways that IDE-integrated stuff is good, but very good in
the ways that IDE-integrated stuff is bad. Look at the example
above – how much effort would it take you to hook testing for
your SQL scripts into your IDE, compared to the effort it took J.
David B. to write a pretty featureful TAP emitter? He didn’t even
have to write most of that code, 1/3 of it would have been enough
for a primitive library, which is sufficient to hook into
Test::Harness – or whatever other TAP infrastructure we’ll cook
up in the future.

This is exactly the kind of thing I was espousing in my other
mail.

Of course, the problem here is one of world view. A heavily IDE-
centric developer isn’t likely to think in these terms in the
first place.

Perl, OTOH, has a cultural bias towards heterogenous environments
and tool independence. It’s easy to imagine why TAP sprung up
here.

I guess the best marketing opportunity would be to target the
developers who have to deal with at least somewhat heterogenous
systems despite their use of typical IDE+xUnit languages –
they’re the most likely to be feeling the sort of pain from their
current tool that will make them receptive to the benefits of
TAP.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

Reply via email to