Out of curiosity, what unwritten Perl book would you like to read? I think I'd like "Perl AI Applications." Even though I know Perl's not the greatest fit for AI, it's still a great language for understanding concepts without letting too much synthetic code distract from the intent.
Re:"Machine Learning in Perl"
jdavidb on 2004-07-13T14:03:58
Maybe the cover would be a borg-ified camel?
:-) Thank you for making me laugh. I'm glad I wasn't drinking anything...
:)
Re:Go Enterprise
cbrandtbuffalo on 2004-07-13T12:05:51
I'd like to see something along these lines, but specifically about managing Perl itself in the enterprise. I know there was a talk at OSCON about this a few years ago, and I've read the slides, but they didn't help me much. I think you had to be there.
The book should cover how to maintain an enterprise version of perl, how to distribute it across an enterprise to multiple machines on multiple platforms. It should cover issues with upgrading, how to keep modules at correct versions, how often to upgrade modules, how often to upgrade Perl. Also, how to deal with new requests to add modules to the distribution when these modules may be unknown quantities. A QA distribution?
I would think it would have a best practices section and a section talking about how some big companies actually do it.Re:Go Enterprise
malte on 2004-07-13T12:41:13
I that case why don't you just print out a cover and put it around some boring Java book.Re:Go Enterprise
jplindstrom on 2004-07-13T15:18:32
I don't have any Java books:) Re:Go Enterprise
wnodom on 2004-07-13T15:56:56
why don't you just print out a cover and put it around some boring Java book
It doesn't have to be that way. Here are a couple of paragraphs from my notes that I mentioned above:
While it's certainly possible to write Perl that looks like
Java, you're probably using Perl because it affords a different
approach and a different philosophy to solving problems. Don't
consign that philosophy to the scrap heap just because the
problem is bigger.
---
Be aware of the unique advantages that Perl brings. Many of the
strictures of other methodologies exist because it is so *hard*
to do anything with other languages. Taking a rigid, methodical
approach is the only way to ensure, or at least encourage,
timely, reliable results. Perl is different. In the time it
might take to perfect one particular version of a C++ program,
the Perl programmer can try ten different approaches, select
the best one, and move on. This is the form of TMTOWTDI that
we don't often celebrate -- that it can be used as a means to
finding the *best* way to do it.
---
Perl programmers are rightly suspicious of this sort of guide.
Too often, it's an attempt to relegate programmers to
diagram-reading, spec-following drones -- just another set of
interchangeable parts. This guide will *not* be like that, and
should work to gently but firmly correct that line of thinking.Any "Perl for the Enterprise" book would have to take Perl's philosophy and culture into account, or it would go absolutely nowhere.
--Bill
Re:Go Enterprise
wnodom on 2004-07-13T15:52:32
Funny you should mention this; Andy Lester and I were talking about it just a couple of days ago.
We both want this book, for two main reasons:
- We want a quality guide we can hand our developers and say "Build Perl applications this way."
- We want to establish greater credibility for Perl with management, to show that "enterprise applications" can and should be built with Perl.
In case anyone's interested, here are some notes that I wrote along these lines quite a while back.
--Bill
Re:Go Enterprise
Ovid on 2004-07-13T17:29:14
Possibly one of the biggest problems I can see with a book like that is the average Perl developer. For Java, I think you can really get away with having developers less skilled than many and still have a bit of safety. Encapsulation, type-safety and checked exceptions are examples of constraints that simply don't exist naturally in Perl, but are the safety net for the Java programmer. This also means that the Java programmer must weave that safety net rope-by-rope or he's not allowed to do his acrobatics. This "one size fits all" approach is not always the best route.
Perl allows programmers to skip the safety-net weaving and go straight to the acrobatics, but this is dangerous. It's so much easier and quicker to do most things in Perl (reading from files is a perfect example) that many developers don't understand the ramifications of what they're doing. How many times have we looked at larger scale open-source Perl and seen people writing to files without a flocking a sentinal or or reaching straight into an object to get the data? How many times do people call external resources without checking to see if those resources exist or the calls failed? Perl programmers can get a lot more done, but I often see it done in a fragile, haphazard fashion. You simply need a better class of Perl programmer to get enterprise programming done, but there are fewer of those programmers out there and many find it tough to evaluate the quality of a Perl programmer.
But perhaps that explains the need for the book
:) Re:Go Enterprise
chromatic on 2004-07-19T23:06:45
Having actually seen "enterprise-class" Java, I label the parent post "-1, Unnecessary Community Self-Loathing".
Trust me, there are enough terrible and dedicated programmers in the world to jump through Java's hoops to produce absolutely hideous code.
