IMHO, we're (intentionally) focusing on body count; number of
books/developers in this discussion. In this category, Java is probably
steamrolling or at least dominant. But what about the amount of work
being done? Productivity represents value for the users of a
language(developers, not end-users), or at least their managers! ;-)
Bodycount represents value for for publishers and for 3rd part product
sales.
Running a development staff, my concern is purely productivity. I
measure the success of Perl in my organization by the amount of projects
and work to completion. I have a 17 year old legacy system to migrate
including some 700 programs, serving 500 employees. My staff has spent a
great deal of time in Java, C/C++, VB, and Perl. Perl for many reasons
has become our language of choice and we are migrating our entire system
to it. This includes core financial (AP/AR/GL/Inventory/Fixed Asset,
etc.), CRM and ERP. Maybe it is more manageable because of the few
developers involved. If I had dozens of remote developers, then maybe I
would have a different decision.
When romancing Java, I concluded that I would need to double my staff in
order to pull this migration off in a reasonable amount of time. Same set
of projects, twice the developers and twice the books sales on our
behalf. So from my perspective, there is indeed a higher ratio of Java
programmers and thus book sales to Perl because many Perl programmers are
already up to par and get new information from module documentation,
etc.; Also the Perl developer can be far more productive as it relates to
internal programming requirements at this level ( so less of them are
needed! :-) ). That looks like a double-chin, doesn't it ?!?
One of our issues was with the frequency of change in Beans and related
technology. Java, VB and the like are product centric versus technology
centric. It is in the best interest of 3rd part Beans development
companies (as with ActiveX/VBX) to release new features often. Those
organizations, especially when publicly held, must demonstrate growth and
really don't have the opportunity in such a narrowed scope to attempt
market saturation(unless you are Microsoft). They must do so with repeat
sales. That implies that the development staff has an ongoing learning
curve.
A final issue with a small staff is that I'm using the same language for
everything from sysadm on Unix to services (Majordomo, fax, alpha paging
and so on) to enterprise level application programming. Conservation of
motion and of knowledge. And living in the realm of the problem versus
armwrestling with language semantics is liberating.
I realize that what I'm discussing is mostly intangible and therefore
miserable to measure BUT I thought worth mentioning.
Just my $.02
Rod
P.S. I think there is a large range of topics in applied usage that could
be written for new titles. In the Java and VB world, I see titles like
"Business Objects", "Enterprise Database Programming", etc. and this is
an area I would *love* to see books on Perl appear.
Nathan Torkington wrote:
> Madeline Schnapp writes:
> > its just that we are beginning to see the Java steamroller beginning
> > to rumble over everything in its path including Perl.
>
> Interesting comment. Where do you see this? The only place I see
> Perl being replaced with Java is in the Java Servlet world. It'd
> still be a cold day in hell before many DBAs and sysadmins changed
> from Perl to Java, I'm thinking. And the death of Perl in the web
> world is greatly exaggerated, I think: mod_perl usage grew by 450,000
> hosts in the last two months, and the number of hosts doubled in the
> last four months.
>
> It's hard to categorize that as being steamrolled.
>
> Nat
