 |
 |
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