This is an interesting and frustrating conversation.

Most modern languages are capable of doing almost anything. They all
have strengths and weaknesses.

I have worked in many languages starting in Fortran, and, while I have
favorites, I like the fact that I can be productive and efficient by
concentrating on one language at a time. Because my day job is mostly
Drupal, for me that language is PHP. When I started, I was working
with ColdFusion (ok, maybe not "really" a language), Java (meh), and
Python (++). I didn't love PHP or choose it, but I appreciated that it
could do what I needed it to do. At the time, that work included a lot
of XML manipulation.

I think that PHP has a good toolset for dealing with XML. I am sure
that there may be something better, but that really does not matter,
since my team has sufficient facility with PHP to complete anything we
take on and the experience and resources to do it with economy and
efficiency.

We haven't abandoned everything else. We use Python for server
management — its AWS libraries sealed that deal — finally displacing
Perl, and Ruby for DevOps (why this gets capitalized at all, I have no
clue) and deployment. Solr keeps us vaguely in touch with Java.

This boils down to: If it is your decision and you have a tool you
prefer, use it.

Thanks,

Cary

On Mon, Feb 18, 2013 at 6:00 AM, Ethan Gruber <[log in to unmask]> wrote:
> The language you choose is somewhat dependent on the data you're working
> with.  I don't find that Ruby or PHP are particularly good at dealing with
> XML. They're passable for data manipulation and migration, but I wouldn't
> use them to render large collections of structured XML data, like EAD or
> TEI collections, or whatever.
>
>
> Ethan
>
>
> On Mon, Feb 18, 2013 at 8:52 AM, Jason Stirnaman <[log in to unmask]>wrote:
>
>> This is a terribly distorted view of Ruby: "If you want to make web pages,
>> learn Ruby", and you don't need to learn Rails to get the benefit of Ruby's
>> awesomeness. But, everyone will have their own opinions. There's no
>> accounting for taste.
>>
>> For anyone interested in learning to program and hack around with library
>> data or linked data, here are some places to start (heavily biased toward
>> the elegance of Ruby):
>>
>> http://wiki.code4lib.org/index.php/Working_with_MaRC
>> https://delicious.com/jstirnaman/ruby+books
>> https://delicious.com/jstirnaman/ruby+tutorials
>> http://rdf.rubyforge.org/
>>
>> Jason
>>
>> Jason Stirnaman
>> Digital Projects Librarian
>> A.R. Dykes Library
>> University of Kansas Medical Center
>> 913-588-7319
>>
>> ________________________________________
>> From: Code for Libraries [[log in to unmask]] on behalf of Joe
>> Hourcle [[log in to unmask]]
>> Sent: Sunday, February 17, 2013 12:52 PM
>> To: [log in to unmask]
>> Subject: Re: [CODE4LIB] You *are* a coder. So what am I?
>>
>> On Feb 17, 2013, at 11:43 AM, John Fereira wrote:
>>
>> > I have been writing software "professionally" since around 1980 and
>> first encounterd perl in the early 1990s of so and have *always* disliked
>> it.   Last year I had to work on a project that was mostly developed in
>> perl and it reminded me how much I disliked it.  As a utility language, and
>> one that I think is good for beginning programmers (especially for those
>> working in a library) I'd recommend PHP over perl every time.
>>
>> I'll agree that there are a few aspects of Perl that can be confusing, as
>> some functions will change behavior depending on context, and there was a
>> lot of bad code examples out there.*
>>
>> ... but I'd recommend almost any current mainstream language before
>> recommending that someone learn PHP.
>>
>> If you're looking to make web pages, learn Ruby.
>>
>> If you're doing data cleanup, Perl if it's lots of text, Python if it's
>> mostly numbers.
>>
>> I should also mention that in the early 1990s would have been Perl 4 ...
>> and unfortunately, most people who learned Perl never learned Perl 5.  It's
>> changed a lot over the years.  (just like PHP isn't nearly as insecure as
>> it used to be ... and actually supports placeholders so you don't end up
>> with SQL injections)
>>
>> -Joe
>>



-- 
Cary Gordon
The Cherry Hill Company
http://chillco.com