>> Selena wrote:
>> I don't care, because my clients (or the people who make technology
>> purchasing decisions) don't care.
> Adam wrote:
> This is a valid POV. Just because someone has an AIX box (or any
> other "boutique platform") doesn't invalidate their need to solve
> problems though.
> Someone else also wrote:
> Sure, that's fine. However, I don't care about non-technical issues.
> It's my job to get the tasks done that are important to keep my
> company working well. If we need to get something done on a PowerPC
> running Linux, it matters a great deal to me that Java is not an
> option.
You are both absolutely right of course! In rereading my original post,
perhaps that line dripped with too much rhetoric to be truthful :)
I guess to be more clear about my intentions....In whole, I do actually care
about the technical issues, and I do care about promoting or advocating perl
within a technical communty. Thus, there is certainly a place for technical
arguments.
However, it is just that with a marketing cap on (which, whether appropriate
or not, is what I wear when reading this particular "advocacy" mailing
list), I am more interested in how to advocate Perl to non-technical
managers who make purchasing and hiring decisions. I honestly think this is
the "harder" and possibly more important task to overcome in the larer
picture
I felt as if the conversations, as many do in these communiuties, quickly
degerenerated into techie talk....
>> Selena also wrote:
>> Aren't we supposed to be working together to think of more efficient AND
>> MORE REVENUE-GENERATING ways in which to advocate Perl here? (Remember,
I
>> am a newbie so I may be totally wrong).
> Adam Replied
> There are projects out there where revenue generation isn't a primary
> concern; cost to develop and time to develop predominate the decision
> making, which may lead into revenue generation as a second-order effect.
> I used to work for a company making enterprise software that had to be
> truly cross platform. We used Perl; we deployed on multiple different
> versions of AIX, Solaris, DEC Unix and Tru64. We would have left a few
> million dollars on the table if we didn't have that flexibility.
When I said money-generating, I meant that since I sell perl products,
advocating perl more effectively is more money generating for me :)
However, I think you are absolutely right. Time to market, cost to market,
cost for maintenance, cost and ease of support, and other similar issues are
what affect how managers make their decisions about technology.
>From your statement, I glean that "if" the job involves a highly
cross-platform solution, then according to you, Perl shines. I tend to
agree with you, but unless you have a highly cross-platform issue, the
benefits of this may not outweight other negatives of going with Perl.
What if there is no great need for cross platform....does Perl dull in
comparison to other technologies?
>> Selena also said:
>> I believe that the the initial point made by Adam could be summarized
as...
>>
>> "The Java development/application environment can be very difficult and
time
>> consuming to install."
>>
>> I think this is a valid point.
> Adam responded:
> That's only half of it though: Perl isn't anywhere near as difficult
> for your typical installation. Perl also is happily devoid of the
> licensing issues, multiple implementation concerns, etc.
>
> In all of the holy wars about Java vs. Perl, this is one point I've
> never heard raised. Lots of times it comes down to disliking Sun or
> lack of dynamic binding or deep object support -- issues that don't
> have anything to do with the price of Tea in China.
Hmmm, one thing just to make sure we are talking about the same
thing....when I compare Java to Perl, I generally compare Java to mod_perl
(or some other acclerated quasi-app server environment) and I am talking
about web applications as a subset of the Perl universe. If you are talking
sys admin programming, for example, then there is no discussion....you use
Perl. It is only in the enterprise web application market that the Java
versus Perl tension is really apparent. And it is only this market that gets
lots of press.
So....setting up an enterprise Perl environment (with caching, session
management, database conection pooling, thread management, business object
management, and all the rest of the bells and whistles that come by default
with J2EE Java) is actually pretty tough.
Not only that, but writing mod_perl safe perl applicaitons is not simplistic
in my experience either. Thus, you need highly trained infrastructure AND
software development speciailists in a Perl project.
In fact, for all its trouble, setting up a Java environment can sometimes be
easier over the long run.....
Of course, you do have a point with licensing issues....does anyone out
there have some juicy case studies where competing technologies were
intensely annoying in this regard?
What do you mean by "multiple implementation concerns?"
>> Selena said:
>> Is our best advocacy strategy to say that, "we don't suck"? Or, more
>> correctly, is our best advocacy strategy to say that our competition does
>> suck? Isn't that really what the meaning behind the first email from
Adam
>> was?
> Adam replied:
> It occured to me that with all of the bitching and moaning about Perl
> these days, I stumbled across an aspect of Perl that's remarkably well
> engineered and in fact doesn't suck. Many years of effort have gone
> into the process, and today anything that can be made to look like a
> UNIXish environment can install Perl pretty darn easily.
>
> This is certainly not the case for Java2, outside the supported
> platforms where point-and-click install binaries aren't available,
> and source code isn't readily available since it's not open.
Beautifully said. I understand better your original post now. My next
question then would be....how important of a benefit is this in the greater
market place and how to better express this benefit when trying to advocate
perl?
>> Selena said:
>> I think that Elaine is 100% correct in saying that the pointy-hairs will
>> simply say that they can buy a support contract from SUN and the issue
will
>> disappear from their world.
> Adam said:
> I agree with Schwern in saying that's a cop-out. I don't need a support
> contract to program in C, C++ or Perl, why *should* I need one for Java?
Well, it depends on your organization type. If your core competency is not
technolog, it can make a lot of dollars and sense to outsource support.
Cetrainly, most of my clients (large banks) prefer to be able to outsource
this stuff. Thus, they need a technology infrastrucutre that can be
supported by third party vendors.
> Adam continued
> If I need to spend my ever-shrinking IT budget more wisely, is that
> something I need more than an upgraded server or database engine?
Many clients find that it is cheaper and more cash-flow conscious to
outsource support rather than maintain full time staff to do it, especially
when technology is not their core competency.
You know, I joke about pointey-haired bosses and all, but it is important to
underdstand that technology decions are not, and should not, be based on
technical criteria alone. Technology decisions are business decisions and
business decisions must balance conflicting demands and the solutins may
seem paradoxical or even bone-headed to the technologist who is not taking
the time to look at the oveall picture.
If we are to advocate Perl, as technologists, we must take a step back and
think about the needs of those we are trying to advocate to.
