I have personally been on a project where a particular tool - say for
example CMS or a Rules based engine (supposed to be a 6th Gen
Programming Language) was used.

In the case where the Rules based engine was used, development was a
lot quicker --- the tool claimed to replace 5 programmers with 1 and
reduced the development time considerably.

But the tool had a lot of limitations and restrictions, it didn't
support Javascript, a lot of solutions had to be designed to fit *the
tool*. So even though it made development a lot faster it took away
the flexibility that comes with building custom applications.

The cost remains the same -- pre-built tools cost a lot (since they
claim to replace many developers with a few developers) , but in the
end the client who uses the tool ends up paying for the upgrade,
maintainance and support costs.

There are pluses and minuses to using a pre-built solution and with
custom-built solution, I'm speaking from my personal experience.

I choose to stay with mostly open-source programming languages rather
than proprietary vendor-based languages. It is easier to find
projects. :-)

> How about the discussion of build vs. buy, specifically:

Seems completely orthogonal to me. It just means that when you build, you
choose your own technology, when you buy, it's more likely to be chosen by
your supplier. One might argue that the productivity/performance tradeoff is
more likely to favour XSLT for in-house applications rather than bought-in
applications; but I know for a fact there are plenty of people developing
and distributing commercial applications that use XSLT either visibly or
under the covers (some of them are my customers).

Michael Kay
http://www.saxonica.com/