Slashdot Mirror
Perl for System Administration
The Scoop Despite being what some call 'the purest distillation of Unix thought,' Perl has earned a place on many Windows and Macintosh machines for its power and flexibility. Unix administrators have developed and honed small scripts for decades, but their brethren elsewhere have had no such luck until recently. Enter ActiveState, IndigoPerl, and MacPerl, to provide the tools, this book the knowledge. Floating subtle suggestions between pragmatic tips and tricks, David N. Blank-Edelman weaves nets, strong and sophisticated, for the perpetual battle against encroaching entropy. What's to Like? Anything that saves a beleagured sysadmin time is very good. Any one chapter read in isolation will yield at least one new idiom, if not many ideas on improving efficiency and accuracy. The central theme of the book ('make things better by using a database to store all of your information') is an excellent and timely idea. It's not essential to the presented examples, but has the potential to simplify your work dramatically. Besides maintaining a central repository for usernames, accounts, network information, and passwords, it allows automated configuration file building. Imagine never hand-editing DNS records again, or having to enter user data only once.
The sample code is clean and understandable, taking full advantage of many CPAN modules. When competing modules exist, Blank-Edelman demonstrates each, with an eye to advantages and disadvantages. This pragmatic analysis governs other discussions, especially concerning cross-platform and Pure Perl versus glue-code isses. Realizing that most networks combine many different clients (Unix flavors, the Windows cousins, and Apple machines), the author provides solutions to the same problem on all applicable platforms.
Though pushing the envelope on certain technologies (at the expense of others), the Appendices provide adequate introduction. The LDAP and SNMP sections stand out in particular. The author provides enough background, whether on Active Directory, TCP packet construction, or e-mail headers, to flesh out his examples. A table at the end of each chapter lists all modules covered, authors and versions, CPAN ids, and alternate download sites. In addition, the book provides many links to further information on techniques, RFCs, references, and vendors. If you're left wondering where to go to learn more, it will be your own fault.
What's to Consider? The book assumes a working knowledge of Perl. Anyone who's made it through 'Learning Perl' or 'Elements of Programming With Perl' should have no trouble -- complex idioms and module peculiarities receive sufficient explanation. Beware, though, that the sample code does not enable warnings or run under strict mode. (Production programs need error checking, which, the author explains, could easily double the size of his examples.)Not all sections apply to all OSs. The Macintosh, for example, has no concept of multiple users (OS X not being covered). These differences could hinder the text, but are clearly marked and can be skipped with no ill effects. Besides, few networks are homogenous, and astute readers will learn more about the system in general from the similarities and differences.
Some common administrative tasks have been left out in favor of emerging or more complex technologies. There's nothing on managing printers or backups. A sysadmin of reasonable experience who makes it through the book will have gained a proper mental framework to tackle other tasks, though.
The Summary Perl for System Administrators is packed with useful tips, making the most of Perl's ecological niche. Whether you're a junior administrator venturing out into the wild world for the first time, or a seasoned BOFH, you'll find something to digest here. You might even get some free time out of it. Table of Contents- Introduction
- Filesystems
- User Accounts
- User Activity
- TCP/IP Name Services
- Directory Services
- SQL Database Administration
- Electronic Mail
- Log Files
- Security and Network Monitoring
- The Five-Minute RCS Tutorial
- The Ten-Minute LDAP Tutorial
- The Eight-Minute XML Tutorial
- The Fifteen-Minute SQL Tutorial
- The Twenty-Minute SNMP Tutorial
You can purchase this book at ThinkGeek.
Pardon the nit-picking, but...the correct title is Perl for System Administration, not "Perl for System Administrators".
I'll admit that I've rarely done things with Perl outside web development and system administration. And Perl doesn't often seem to be the best choice for large projects. Still, it's been useful outside of those contexts often enough and some of your objections seem crazy enough that I feel compelled to reply. Even though I know 37 other people will.
First off, the biggest idea I take issue with is that web development isn't programming. Web applications can match other applications in their scale and the engineering effort required. You come up with requirements, you spec, you code, you test. The fact that the UI comes through a browser through a web server doesn't change this. And boy, I *long* for the wasted months of youth that could have been saved if I had only used Perl for some of these projects instead of C.
OK, some line by line responses:
Object orientation - Perl's oop features are available, but not enforced. Real programming languages like java and pascal try to enforce good programming methodologies. This is a good thing, and the reason we don't code in assembly anymore.
People still code in assembly sometimes. Why? When it gives them an advantage they're looking for. Ditto for Perl. Except Perl arguably has a larger set of advantages. OK, most people really do a lot of the things we think of as for assembly in C. But wait. C's object orientation features aren't enforced -- they're nearly non-existent (though you can and should learn to do OO in plain ol' C). Alright, C++. Which has a dozen workarounds for its OO features and doesn't enforce their use. Still pretty popular for all sorts of things. I assume some people find its feature set useful somehow.
Readability - I know that it's possible to write readable perl, but nobody does it. Go search cpan, look at how many people bother to explain their line noise looking regexes. If programmers are allowed to be lazy, they will.
Been said before, will be said again (at least by me): bad code can be (and is) written in ANY language. Especially C and/or C++. Which are still widely used by developer for their advantages.
(That said, Perl programmers really do seem to gloat sometimes over their terseness and cleverness. Great, guys... just don't put it in code someone else has to maintain. Same goes for you clever C programmers).
Standardization - Perl isn't standardized. There's no guarantee that ANY language feature will work in future releases. Do you want to stake your buisness on that?
Well, for one thing, I don't have a problem staking my business on that because any version of Perl is pretty much freely available.
And furthermore, in practice, I find that Perl is as portable as anything I've written in C or Java or Pascal. Maybe more. The problems with all the latter languages are usually with libraries and class frameworks and proprietary extensions, but they're still there. The only problem I've ever had with Perl portability has to do with certain features not being available on *nix but not DOS/win32. And so I put some extra effort in and wrote cross-platform Perl.
Maintainability - Perl is damned near impossible to maintain bin the real world. Combine terseness with "there's more than one way to do it" and you have a recipe for disaster. Competent programmers can maintain another competent programmers perl code, but when was the last time you were assigned to maintain good code?
When was the last time your were assigned to maintain good code in any language?
This is practically the same argument as readability above. All the same responses apply.
When was the last time someone competent was hired to maintain yours?
Three weeks ago.
There's a reason why COBOL and VB are so popular in buisness, and that's that any idiot can write and maintain them.
This is a virtue? COBOL and VB have virtues that Perl has not? Ahhhh... ok.
Tweet, tweet.
I think offtopic threads like this one are a great way to lose karma. No only will you lose it, but everyone who replies to you will lose karma too.
Pissing off mac loyalists is the best though. I dropped 25 karma in a day that way.
--Shoeboy
I would expect a book titled, "Perl for System Administrators" to assume no knowledge of Perl. The language has it's system administrative niche in the ability to create small programs between maybe 1 and 100 lines for tasks involving some quick text processing or glueing two applications together. In other words, the tasks you would most likely find Perl applicable for involving System Administration are the tasks that wouldn't require in-depth knowledge of Perl, but would instead simply require a foundation in Perl, a thorough grounding in regular expressions, and most importantly, a solid description of how to program secure Perl code.
Ok, sadly I have to admit to buying this book right after it came out. This book is trash. It is redundant and insipid. If you are a "system administrator", you should probably know how to do these things anyway. Of course, one of the problems with the book is the author never defines administrator as "solaris admin" or "nt admin", so he has to gloss over all the really good stuff. As an example of how dumb and boring this book is, in one of the chapters he has you implement log rotation with a perl script. GOOD CALL! Maybe when I boot up my copy of SunOS 2.1 I'll have to roll my own log rotation, but just about every UNIX has that now. If you have to have this book, just steal it. It's not worth the forty something bucks they want for it. I have to say I usually like O'Reilly books, and this is the only one I haven't liked in a while.
------------
a funny comment: 1 karma
an insightful comment: 1 karma
a good old-fashioned flame: priceless
this sig limit is too small to put anything good h
The book is called "Perl for System Administration" not "System Administrators"
It's rather frustrating trying to search for a book that doesn't exist!
gee... that sounds rigid...
(10 lines of code)
# woohoo!!
(10 more lines)
# wee!!! i'm a comment
(yet another 10 lines)
# kiss my ass! i ain't commenting shit!
even easier to circumvent than the lameness filter.
On each point:
Object orientation: is this the truly the end all, be all idea that if it doesn't force a programmer to do oop then it's a bad language? I don't think so - there are plenty of languages that don't force oop and are considered excellent. C anyone? or how about VB? They don't force anyone to oop.
Readability: I've yet to see any program that is not in a book that could be deciphered. It's not perl fault if people can't devine regex's.
Standardization: What language is truly standardized across all versions? And how many companies based their business on other languages only to have features disappear? Alot, this isn't a problem with the language but with the process of standardizing anything.
Maintainability: How much code is easy to maintain? Not much, doesn't matter if it's VB (eech!) or COBOL (double eech!). If programmers don't document their program then it isn't easy to maintain.
Overall, everything you mentioned in Perl has already happened to every other language and will continue to happen. Why? Well, that is evolution of a language. To fault one is to fault them all. Nothing is perfect but it's nice to have a language that will forgive you of your trespasses and allow you to complete the work. Large scale or not, Perl always completes it's goals and then some.
Don't like it - Don't use it! But Perl is so that you don't have to be a great programmer to complete great projects. How many languages can do that?
Save Pangaea!! Stop Continental Drift!!
As we java developers say: program to the interface. You can't do that in perl.
Huh? Then what the heck is CPAN? A big archive of interfaces, with documentation and conventions startlingly similar to javadoc.
Properly-written perl modules work exactly like properly-written classes, with the exception of not enforcing types, for obvious reasons. Oh, and not having to type 80 characters to get to your function. ;)
Java can stop some idiot coming and screwing up your code by ignoring the APIs
Ahh, so idiot programmers are perl's fault. I see.
All of your arguments seem to be against any large-scale coding project. Improper interface documentation and infrequent or non-existant code reviews will screw you up regardless of the programming language used. It seems like you've been screwed by some idiot programmer in the past. If this perl programmer is screwing up your project, you should be talking to your manager, plain and simple.
1st Law Of Networking: Loose ends are bad, termination is good.
WWJD? JWRTFM!!!
I think you are missing the whole point. There are obvious reasons why programmers dont crimp cat 5 cables, and there are obvious reasons why sys admins dont work on full life cycle project development, start mixing stuff, and you ll end up in a mess. Segreggation is important.
Don't be silly. When you're a sysadmin and you are in charge of:
Unix (3-4 flavors)
WinNT
Novell
Cisco and Motorola routers
And also need to be proficient in 4-5 programming/scripting languages, that no one else on staff knows, you need help.
This book (I own it) has examples that you can apply to your own systems with minimal modification. Why re-invent the wheel?
-nme!
Lots of people have mentioned that you are wrong. I would like to cite an example.
Tivoli's TME10 Enterprise Management Framework, and the associated products which tie into it, employ a significant number of perl-based CORBA methods.
This is not a large application entirely written in perl, but it is a large application which contains a significant quantity of perl. Perl has a number of significant advantages, in that it's cross-platform (as long as you take into account what kind of system you're running on) and easy to work with. If you treat perl more or less like an uncompiled C which is loosely typed, it's not difficult for multiple people to work with.
Arguably, since the people most interested in flash tend to be artists... well, I'll let you draw your own inferences.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Most of the reviews from people so far, bitching about it, seem to either be coming from system admins trying to learn perl (bitching that using it requires a knowledge of perl), or perl programmers bitching that it doesn't teach them system administration.
If you want to learn perl -- buy Learning Perl. If you want to learn system adminstration, get the Unix Systems Administration Handbook. They're both good entry level books in their field.
Perl for System Administrators was to me, more like the Cookbook -- it tells you about lots of things that you can do with the language, as 90% of the perl books out there seem to focus on text processing [eg, HTTP interfaces] Personally, I got it as a reference for work I'm doing with HTTP interfaces to LDAP. Most of the rest of the book either I don't need to worry about right now, or I've already done before, so is only useful if I want to find out why the way I did it was wrong.
This is a _very_ niche book, as you need to know both system administration and perl, and actually care about one of the chapters in the book. If you fit into that category, it'll probably be of immense help. I know it was to me.
Build it, and they will come^Hplain.
Review the 3 out of 10 books! Hey, consider it a challenge. Find a book in a subject area that should be reviewed on Slashdot, but that richly deserves a 0 on a scale from 1 to 10. There has to be at least one. Warn us all before we waste our money!
if the scale is from 1 to 10 you cant give a 0 to a book. The least you can give is a 1.
That was my point. There are some things that deserve to be off the bottom of the scale. There are movies that should not be watched and books that should not be read because they are such a waste of precious hours.
The net will not be what we demand, but what we make it. Build it well.
Er, this might have something to do with the fact that C has existed rather longer than has Perl. In fact, I suspect that the Obfuscated C contest itself is older than the entire Perl language. :-)
Other than that, interesting points. :-)
I could have sworn that you were describing Java. Doesn't soud like the Perl I know.
domc
I've heard the difference summed up this way: Systems administrators know how to do things, and programmers know what to do. Both useful, but ultimately divergent, skills.
---- I'm going to lead you kicking and screaming, giggling and laughing into the future.
--
--
--
We have fought the AC's, and they have won.
Me too!
Also FatPhil on SoylentNews, id 863
A better analogy would be professional mechanic (sysadmin) and professionial automotive engineer (programmer). The mechanic has to work with what the engineer gives him, but he could also be have a little machining shop to make a custom part.
Hows about Programming Perl, that's got lots of programming focus or whatever it is it's got.
*shrug*
In part this is because the reviewers here mostly review books they've taken the time to read all the way through. Those books tend to have several qualities:
These add up to scores above 5 on a scale from 1 to 10. Perhaps what Slashdot needs is for a few of us to admit some of our book-buying mistakes and review the real dogs. And for any of you out there who have ever been given a really bad book, this is an opportunity:
Review the 3 out of 10 books! Hey, consider it a challenge. Find a book in a subject area that should be reviewed on Slashdot, but that richly deserves a 0 on a scale from 1 to 10. There has to be at least one. Warn us all before we waste our money!
The net will not be what we demand, but what we make it. Build it well.
Well, I just happened to get a first post, with a +1 bonus. There goes three right there. Pretty soon I'll have to stop this crap and start whoring again.
It may look like I'm doing nothing, but I'm actively waiting for my problems to go away.
--Scott Adams
Of course perl doesn't actually prevent this in any literal way. However, the practical result of perl code is that once it gets above a certain size, the whole tends to glue together into one creaking mass. Perl simply doesn't support advanced language features such as reflection in java, which allows you to ensure that your code is cleanly separated.
As we java developers say: program to the interface. You can't do that in perl. Java can stop some idiot coming and screwing up your code by ignoring the APIs, in perl you're forced to rely on trust. A trust-based coding system simply doesn't work once you've got more than just a couple of coders working together. Bondage can be good for you.
The vast majority of programmers do not have the skills or the discipline to produce maintainable, readable code. This is why, for large-scale development projects, teams either insist on rigid coding standards (i.e. if you don't comment every ten lines, you can't check your code in), or languages which enforce their own standards. As an example, the US Ministry of Defence has long insisted that all defence-related software be written in Ada, solely because it is a safe language with enforced coding standards. My organisation, on the other hand, insists on Java and Eiffel.
I'd really like to see someone substantiate these claims that people write maintainable, readable perl. Anecdotal evidence would seem to sharply discredit this view, as would looking at most major large perl projects. Perhaps this code exists in on the hard-drives of these virtuoso perl bigots, who shield it from the masses as the Israelites shielded the Ark of the Covenant from the rabble. Who knows?
> Why does everybody seem to think that since OOP was created there is no longer a need for procedural programming?! ;)
/. worth reading! Don't be so boring serious!
You forget functional and logic programming, you bastard
> From the Jargon file "Real Programmers Don't Document: If it was hard to write, it should be hard to read"
Most of the time, Perl isn't hard to write, so it shouldn't need to be hard to read. Except for the regexps, of course, which are _allways_ harder to write than to read (despite what newbies seing a regexp for the first tim e thinks).
> It's easy to obfuscate any language
Of course. But most languages doesn't come with _auto_obfuscation_...
Trolls are what makes
--The knowledge that you are an idiot, is what distinguishes you from one.
Perl for Stoats? ("Squeak squeak." -- the author.)
How many of these Perl for Increasingly-Small-Demographic books do we need? Can't system administrators just get Programming Perl and figure it out? It's not rocket science.
I think you're right. Most programmers have to do some system administration. Many sysadmins have to acquire programming skills.
But what I'm finding is that any computer owner has to be a sysadmin for their own system. The tasks are different and vary in depth and patience required from platform to platform, but they're all there. Linux raises the bar -- in order to run your own Linux box, you have to become a *nix sysadmin.
The only situations I can think of where I haven't had to be a sysadmin is when I worked for places large enough to hire their own.
Tweet, tweet.
First you talk about clarity, then you mention LISP...
:)
Which is it?
I like you, Stuart. You're not like everyone else, here, at Slashdot.
Are you sure you're not describing Windows programing with MFC and not Perl? I think most, if not all, of your points apply for that. :)
(Only meant as a joke, I'm not blindly bashing.)
It's easy to obfuscate any language
Of course. But most languages doesn't come with _auto_obfuscation_...
Two words for you...
LISP
APL
I like you, Stuart. You're not like everyone else, here, at Slashdot.
I've used bookpool before. They usually sort to the top by price when I use one of the book specific search engines. Never had any problems either. My deep discount was due to the retailer's error. The sign was removed immediately and I was the first (and last) customer to get the book at that price.
--
As a matter of fact, I am a lawyer. But I play an actor on TV.
You, sir, are an idiot. One of the real strengths of Perl is in its adaptability to generic programming techniques. These make code highly reusable, and customizable. My experience has strongly been that any use of inheritence from anything other than an abstract base class or an interface tends to cause maintainability problems. It is unfortunate that this technique is very pervasive throughout Java. Every piece of java code around here is full of casts... can't get anything out of a vector without casting it. Was it supposed to be a type safe language? What kind of enforcement is going on there? Ah... I see... 1990 style OOP is the only thing they support... no modern programming techniques. (alright, a bit of an exageration... but not much.) Readability is among the strongest features of Perl; it has much more flexibility in the specification of commands than most other languages. This flexibility gives you significantly more control over how to express intent. Obviously any sort of freedom is a double edged sword; but the freedom to do things well vs. a consistent mdeiocrity... I'll take the freedom. Maintainability is 100% a matter of design. Any 'well' designed project is going to be maintainable; any 'poorly' designed project is not. COBOL and VB popular? (What rock do you live under? Just want to know so I can avoid it.) I have found both to be total maintenance nightmares (especially VB, for some reason there seems to be an abundance of poorly written VB is the world.) I'd list the three big strengths of perl as: 1. Its quick to develop in 2. Its easy to maintain 3. Potentially a high level of code reusability 4. Acceptably fast
How long has O'Reily been publishing *nix oriented books? I really don't know, but I would imagine that it's been a while. Perhaps all these bad reviews are from the guy who started reading O'Reily books to learn how to be a sysadmin, 10 years ago...not the 20 something guy who's just leaning the ropes.
Maybe back 10 years ago, the venerable sysadmins were ripping the O'Reily books you were reading. I haven't read the book...but I am a sysadmin with 5 yrs in the biz. I'm not a perl guru, and I've really never had time to learn it. Perhaps I should...perhaps I shouldn't. But it seems that if you know everything there is to know about being a sysadmin, you shouldn't need this book. So why are so many of you complaining about wasting your money?
I disagree with this. We have actually built complete ordering and tracking systems solely in perl. If the organization defines the standards which have to be followed then the readability, standardization and maintanibility as well as testing and Q.A can be performed without any major difficulties in any language. Object oriented features and mechanisms in perl follow the OO principles, it is people who dont bother reading documentation that wind up saying java or pascal are better just because that is the enviroment they are used to working with.
Alright, I see your point. There's a difference between the skillset of this person who we call a "sysadmin" and... well, me. Software developer for years, UNIX/PC/Mac/TI-994A user for years more. Generally computer savy. But mediocre at system administration.
Yet I don't think it's incorrect to say that every computer owner -- who doesn't have someone to do it for them -- has to do system administration tasks. And that (from what I've read) is what the folks at Nautilus (the Eazel folks) figured out: that most often, it's not a matter of mastering UI that makes computers hard to use for people. Most folks can learn to navigate a GUI or use a CLI just fine. They just aren't sysadmins, but they're called on to do system administration anytime they install software or change a setting from what it was out of the box.
Tweet, tweet.
you start working on your resume, because...
no.
I haven't worked all the way through Linux Programming Unleashed... if there's a review there, it won't be smiley happy. Look back to the second or third of the Learning Linux articles for some harsh comments about a book that got stuff wrong.
I don't take the scores too seriously, though. I take off points for stuff that's obviously wrong, stuff that's hard to read, and stuff that doesn't fit the focus of the book. Beyond that, you're just reading a summary based on my opinions. They're free, non-fattening, and if Hemos sends me a copy of Teach Yourself and Other Assorted Idiots Perl 6 in 24 Minutes, I'll rip it up. Just for you.
--
how to invest, a novice's guide
----
I bought this when it was released several months ago, and it's been a very useful tool. I also got a chance to meet the author at LISA 2000 where he was giving a tutorial on the same topic, as well as speaking at O'Reilly's booth.
Timothy, is CmdrTaco rubbing off on you? Is is ineptitude at spelling contagious?
Or just ineptitude at grammar. 8?)
Let the person without sin cast the first stone...
Why is there only one Monopolies commission?
How about a Ruby or Python book review?
GONE FISHING
Sometimes I think that the best way to lose karma around here is to compile a well-thought-out, on topic, insightful post. The way moderation goes, you'll probably be hit with "troll", "flamebait", and "overrated". Example: my original post somehow got an "underrated." Of course, the simple explanation is that that moderator was a /. denizen, modding up an obvious crap post. The other funny explanation is that the moderator was a sadist, and seeing my wish to lose karma, purposely modded my up just to watch me squirm.
It may look like I'm doing nothing, but I'm actively waiting for my problems to go away.
--Scott Adams
Could we have a single Perl-related article on slashdot where the comments actually deal with the article at hand, and don't degenerate in to a general discusion of 1) Perl, 2) the readability and maintainability thereof, or 3) the inferiority or superiority of Perl as compared with Python or any number of other languages?
Uninformed generalizations are a dime a dozen.
--Bruce Fields
While all of these O'Reilly books are pretty good, they lack the programming focus that I think this book should fill nicely.
If you want "programming focus," don't use Perl. You'll end up needing Bi-focals and magnifying glass just to get a smidgen of clarity from it.
If you want real programming focus, take a couple of intro classes at your local University. Use Lisp.
Juicy cranberries grandma!
I have a pretty strong suspicion that you're just trolling but on the off-hand chance you're not I'll try to make a somewhat educated rebuttal. Note that I'm not a CS major (computational chemistry), but that I do program a lot and I have done so for money. In other words, I tend to have a very pragmatic outlook on computer science.
Object Orientation -- Leaving aside the large and very valid debate about whether or not OO is a panacea (it's not IMHO, grotty OO code is still grotty, as is grotty functional lang code, et al.), bondage-and-discipline languages that try to force developers into doing something are not a good thing. Why? People get pissed off about the restrictions and find ways around them. Example: #define private public in a C++ header file. If you subscribe to the ``efficient market'' theory (lots of smart people looking at the same problem will arrive at roughly the same answer (c.f. the stock market and share valuation)), and believe that strict programming languages are a good thing, then why isn't everything being written in Ada today? (Oh, and the ``Real programming languages'' bit is really idiotic. I guess Linus was just using those toy languages C and asm when he coded linux's kernel...)
Readabilty -- is a function of the programmer, not the language. Regexps are line noise but they are the most effective way of transmitting meta-lingual patterns, so it's just a sub-language like any other proigramming language (you're programming matches on text instead of bits on a chip). It's just as easy to write bad Java as it is bad perl, and it's _really_ easy to write bad C (don't forget the obfuscated C contest has been around longer than the obfuscated perl one).
Standardization -- Nothing is constant in the IT industry. Just ask the guys who wrote the DB code for the airlines back in the 60's before the whole relational db / SQL revolution. Standards for a langugae are of overblown importance anyway, just go and try to tell me that advanced (read: uses all the advantages of the environment) C++ code for VC++6 and g++ are the same, even if you use "Standard C++". :-) To use one of your examples against you (of a "real" programming langugae), Java isn't standardized. Sun could decide tomorrow that "well, we never did like the + operator so we're deprecating it in favor of $%$(*@ as the addition operator". Secondly, since when do businesses recode everything as soon as a new release of somethig comes out? 4 of the last 5 places I've done contract work for were still using RH 6.0 and perl 5.005. (The other place was using 6.2 and 5.005) Thirdly, the language is communaly designed so it is highly unlikely core language features are going to change night-and-day in one or even two releases.
Maintainability -- so in essence you're saying every programmer before and after you is a Forrest Gump? Uh, yeah. Basically this boils down to the same thing listed under readabilty: to get good code you need good (disciplined and technically proficient) coders. Try arriving on a consensus in your coding dept as to code standards (<-- this will be much more effective if the coders themselves come up with it that a dictate from on high), and make sure you hire good (see de above) people. The rest will work out. COBOL and VB are popular in business becuase they just want something that will get the job done, and since both of the langugaes were designed to fit into the "problem space" of business, they are a path of least resistance. (They are the "good enough" solutions, although I think and hope that Java is beginning to replace them.)
As to your original thesis that perl isn't used by real programmers, well, I have about 200Kb of genome analysis code that ties into some hefty vis libs written in OpenGL that proves it wrong. :-) I.e. I think that's outside of the realm of webdev and sysadmin (which perl is very good for but is hardly it's sole strong point)
This is not to say that everything should be done in perl. All true masters of their trades[1] realize that no one tool is the perfect one for all tasks, so each should be used in accordance with its strengths. I.e. I'm not going to be writing any kernel modules in perl any time soon, kOrbit notwithstanding.
[1] I'm not claiming I am one, just noting a fact. Michaelangelo used more than one brush painting the Cistine Chapel. (I think that's the guy, but even if I'm forgetting the name the point stands.)
--
News for Geeks in Austin, TX
They don't mention that half of this book is written for Windows NT.
Anyone that believes that needs shooting, IMO. It's the programming equivalent of saying "i have a proof that this works, but it is too large to fit in this margin" (sorry if that quote isn't spot on there).
What next, windows for dummies? oh wait...
--
Slashdot didn't accept your submission? hackerheaven.org will!
Unix admins, maybe... NT/W2K sys admins need this book. Every one I've been acquainted with has been surprised when I told them how much you can do with Perl.
---
where there's fish, there's cats
all ya had to say was...
python!!!
python!!!
python!!!
python!!!
see?
Well, I have both side represented in my resume, and since I did spend a lot of time on the programming side, I'm now looking the other one.
Enough with my personnal story.If you want to venture in analogies, I will try to take more close examples, even the mechanic one is very good. If you leave the programmer alone, I think that the people doing whole system/integration test are close to sysadmins :
They know the system on the whole, with a more a global point of view than of any particular areas.
The same way, they learn to look at the system in a more organic fashion : a programmer will go for the log files, a tester will know right way something is wrong because that operation is taking too long...
they have to go deeper into details (code) when something is wrong, so they might end up criticizing/commenting on the design
they have to be anal-retentive, to make sure that every dark corner is covered
even if this is less obvious for tester, since they have some good troubleshooting knowledge on the system, they well might end up answering customer questions, even if that's not their daily job.
This is obviously looking at the same system from a different point of view : the builder and the maintainer.
However, every each roles have to deals with the innards of the system at differents phases of its life.However, one of the great advantage of having sysadmin do developpment and developper doing sysadmin is on the requirements gathering. Since getting relevants requirements is one of the thorniest problems into software developpment, having both roles allow to much more communication.
A sysadmin doing/having done developpment will quickly assess the technical feasibility of some tasks, whether an programmer will try to deal with system ressources in a more knowedgeable way. Some examples (out of experience) :troubleshooting/sysadmin people are complaining because soft X has no log files to troubleshoot
the design team create log files
after a panic caused by a full disk, the troubleshooting/sysadmin people are complaining again
th desing team add circular logging.
This is a typical examples where overlapping is not only desirable, but should be required, because a lot of reverse story exists as well.
[warma_khoring] Perl is a good example of a language for sysadmin/developper : it allows you to write short shell chirurgical shell scripts as well as huge frameworks.[/warma_khoring][Pruneau
hevyd is absolutely right.
Although PERLs syntax is fairly easy to learn, and syntacticly clean, much of the advanced functionality availible is implemented through hundreds of external modules. How is every sysadmin supposed to just instantly know what modules are availible for what purposes, or to another extent, which ones are the best.
You also mentioned man pages for PERL? Have you ever seen the monster? Even the FAQ is split between some 9 different man pages? All of the functions are on the same page, and even though they are split up into usefull categories they man page is less than intuitive.
Perhaps this book may not be well suited to _you_, however, I'm certain there are a whole host of sa's who have at least a strong foundation of PERL, but would like to extend that knowledge to allow for more advanced scripts to be written.
"Who cares if it doesn't do anything? It was made with our new Triple-Iso-Bifurcated-Krypton-Gate-MOS proccess!"
They must keep forgetting how to spell dictionary.com :D
"Free your mind and your ass will follow"
LISP isn't auto-obfuscated, you just hate parentheses.
It'll take 5 minutes. Register!
I have seen the book become an invaluable aid for Windoze admins who had no idea that such power could be had for free. There are more in-depth books (most notably Dave Roth's excellent Perl on Win32 books), but this book does a good job of saying "Hey, look what you can do with this!".
And remember, Perl's role on Windoze (as I see it) is mostly subversive. It's a great way to introduce more computer professionals to Open Source software in an environment they're familiar with.
I would say an oyster, but that's to obvious.
No boom today. Boom tomorrow. There's always a boom tomorrow. - Cmdr. Susan Ivanova
Every computer owner (well, almost every) does indeed have to do some system administration. I wouldn't dream of arguing that point. That doesn't make them a sysadmin, though; anymore than programming admin tasks in perl makes a sysadmin a programmer. It's a matter of which task is your major job and/or skill.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
I agree that the O'Reilly MySQL book sucks. However I found the New Riders book reasonably useful. Like you, I still prefer the official manual.
Despite myself, I have some emotional loyalty to O'Reilly and I really want them to stop printing trash. Or maybe use a different cover theme for books that are garbage. In this case, George Reese's name on the cover was a good indicator of the quality. Remember his anti-perl flames on usenet?
What I think you're really saying is that it's human nature to bypass the API and access a private variable if convenient, but it's also human nature to respect a minimal access barrier.
But Perl already has a minimal access barrier that's understood by Perl programmers - I've read lots of good and horrible Perl, but I've never seen a programmer getting/setting a variable in an object rather than use the API.
In any event, the whole thing is a tempest in a teapot. Object-orientation solves a lot of imaginary problems but has little linkage to the real problems programmers encounter.
I don't think sys admins will be helped by this book. most sa's know about perl. There are already many references out there for free. Cpan. man pages. How-to's. Most problems a sys admin faces have been solved by someone else. It is usually a better idea to modify an existing work than reinvent the wheel.
Yep, I never spell check.
More incorrect spellings can be found he
Want to see some good Perl? Check out Randall's WTR columns. And his UnixReview columns which are more tutorial.
Of course the biggest collection of Perl is CPAN. I disagree with the previous assertion that modules on CPAN are sloppy. The one's I've bothered reading are really clean and nice.
You cite slashdot as an example of sloppy Perl. Please realize that it tracks a moving target. Code that powers web sites tends to be sloppy because web sites change in unpredictable ways. Want to see clean code? Look at Net::Ping for example.
I guess we live in two different worlds. The kind of projects you work on are the ones I avoid like the plague. I would never work with idiots or work under strict arbitrary rules, not when there are so many great places to work. Maybe your workplace has a vicious cycle - the barriers you've erected to keep the 'sad wankers' at bay scare off the more talented programmers.
Penguins postulate Perl programming. The Linux Pimp
--It's Pimptastic!--
Ummm... "impossible" to do large-scale development, meaning Perl actually prevents this?
So C's not a real programming language, then?
Yeah, that's Perl's fault. Impossible.
Yeah, Java never deprecates any features. Nothing in the C or C++ standards ever changed or broke existing code. And Pascal (the real programming language you mentioned, still used for so many groundbreaking large-scale projects) certainly is standardized -- who cares that none of the popular Pascal implementations came anywhere near the standards?
And any idiot will, which is where the fun begins. But then, I thought we were talking about Serious Professional Programmers.
What's next, Slashdot for Illogical, Ill-Informed Posters?
-paul"Irony is so September 10th"
Matt Miller, alt.fan.spinnwebe
but every book that gets reviewed on slashdot get an 8 or a 9. use a scale of 1 to 3 if your spread is 3 points!
i'm not saying i've never found slashdot's reviews helpful, just optimistic. (and positive reviews of the two mysql books [o'reillys and new riders] tricked me into buying books significantly weaker then the online docs)
thanks kellan
ps. if your getting sick of o'reilly, manning is has put out a number of truly quality offerings lately.
Object orientation
Why does everybody seem to think that since OOP was created there is no longer a need for procedural programming?!
Readability
From the Jargon file "Real Programmers Don't Document: If it was hard to write, it should be hard to read"
Standardization
Every try to build a Visual C++ project with gcc?
Maintainability
It's easy to obfuscate any language
Now get back under your bridge, troll.
--Dave
The Macintosh, for example, has no concept of multiple users (OS X not being covered).
Before any other Mac users rush in to flame the reviewer by pointing out that Mac OS 9 in fact does support multiple users, I would like to point out that it, in fact, does suck rocks and is incredibly brain-damaged compared to even Windows 9x's multiple-user capabilities. About the only thing it's good for is putting up a login password at startup (which can quite easily be circumvented) and for impressing your easily-impressed friends by using the voiceprint verification password thingy, which never works unless you:
a) are in a silent room
b) are speaking into a wired microphone
c) are setting it up for the first time (always fails after then)
Can't wait for OS X.....
--
I use Macs for work, Linux for education, and Windows for cardplaying.
Not!
The only thing of any use in this book was the Appendix, it provided a good intro to RCS (useful for training operators or non-admin staff) and a decent explanation of LDAP and SNMP.
Otherwise, it is a complete and total waste of time and money.
Conformity is the jailer of freedom and enemy of growth. -JFK
OK I agree with your post except the last line. VB definetly has advantages over perl in some situations.
Just think, if you have to write a little COM component that all it does is get something from an Access database and return it and it also has to be maintainable by the manager's teenage son/daughter.
Do VB's virtues become apparent now?
I'm not convinced that Perl couldn't do this job, but I think I see your point:
... it's a requirement impossed by an earlier (possibly poor, possibly good) choice. #1 could arguably be a true virtue of MS products.
1) MS products have the virtue of being more highly integrated with other MS products. In some cases, this is an advantage
2) If you're writing something for someone with an investment (knowledge or technical) in a certain system, it's to their advantage for you to make that investment work best.
#2 is not necessarily a virtue of VB
Tweet, tweet.
I'm surprised you could POST IN ALL CAPS.
cpeterso
Thank you mister "Troll" moderator. However, I believe that mister "Underrated" moderator must be either a crack-smoking moron or a sadist. Of course, he could be both.
It may look like I'm doing nothing, but I'm actively waiting for my problems to go away.
--Scott Adams
How's that for 'educating the maggotry'?
"We'll need 2000 crickets, 4 cans of Easy Cheese, and the fluid from 18 glowsticks for this plan to work...." - ph0n1c
...my Windows NT Server Networking Guide just fell of the shelf into the bin, making way for an ever expanding O'Reilly collection !
br>
It wasn't funny back when I did it.
Age hasn't improved it any.
--Shoeboy
Sorry.
I'm humbly trying to lose karma. What is your suggestion for the best way to accomplish this. I found that flaming Linux worked very well in another story, however, I could not think up a good enough Perl flame in time to get a decent #(st|nd|rd|th) post, and thus attract moderator attention.
It may look like I'm doing nothing, but I'm actively waiting for my problems to go away.
--Scott Adams