Date: Mon, 21 Jan 2002 16:20:06 -0600 From: "Mike Meyer" <mwm-dated-1012083607.1cac06@mired.org> To: Cliff Sarginson <cliff@raggedclown.net>, Wayne Pascoe <usenet@penguinpowered.org.uk> Cc: questions@freebsd.org Subject: Re: Re[2]: what is a good language for system administration? Message-ID: <15436.37910.635122.378864@guru.mired.org> In-Reply-To: <123382329@toto.iv>
next in thread | previous in thread | raw e-mail | index | archive | help
Cliff Sarginson <cliff@raggedclown.net> types: > On Sun, Jan 20, 2002 at 10:07:25AM -0600, Mike Meyer wrote: > > Alfatrion <alfatrion@cybertron.tmfweb.nl> types: > <SNIP> > > True. There's a couple of Python-specific remote method invocation > > implementations floating around, but I haven't investigated them. I > > like the ability to choose the language appropriate for each object > > that comes with using CORBA. > Mmm, considering this and other answers (including my own), they are > all trying to answer the question (what is "good" for system > administration). The question may have have been what, in a practical > sense is the best to learn in terms of portability, skills, and > what may shine best on your CV as a "Unix Systems Admin" The last one tends to run counter to the first two. > For the wider world I think the answer is still: > - Know the shell backwards and all the needed tools for use with the > shell. Yup. > - (Painful as I find this to say) learn Perl. There is such a huge > amount of canned modules for Perl available, and it is increasingly > used where people used to write "C" for something too slow to be > done in the shell, that I don;t think there are any other players > seriously in the game yet. I think Perl is more useful on your resume than as a system administration language. On the other hand, you're almost certain to encounter it most places, so being able to read and debug it will be handy. Python - and Ruby, for that matter - both have a large collection of canned modules. More on that in a bit. Python and Java are both being used where people used to write C (or some other compiled language) because the shell was to slow, or lacked the facilities. In some cases, they come out faster because the stuff that really needs to be fast is now done in carefully tuned C in the VM instead of the stuff thrown together for the job at hand. Outside the sysadmin domain, Python is seeing a lot of use in scientific modeling. You wrap the model code in an object, then the users get to play with the model in the Python REPL loop, which beats the old method of writing a C program to invoke the model routines hands down. Wayne Pascoe <usenet@penguinpowered.org.uk> types: > <scanner@jurai.net> writes: > > > rene@xs4all.nl writes: > > > > * checking if a remote host is up > > > > * pumping files & RAM data through external tools > > > > * calling scripts written in the same language on a remote machine, to > > > > 'pickup' data that was pumped to that machine by a local script. > > > Perl was written with sysadmin work in mind. That was the original Which means it was designed to be comfortable to people who knew the shell and C. Which is why it's incredibly ugly. I mean - can anyone name two other languages that use non-alphabetic characters on the end of the name to denote the type of a variable, and you can have multiple variables with the same name but different types? > > Perl is a hideously ugly language that should be taken out and shot. Since > > your soliciting opinions :-) Python is a much easier, cleaner, and nicer > > language for sys admin tasksfor me then perl. My favorite story about Perl is when someone approached Larry Wall and Eric Allman at a Usenix and asked "What does $* mean?". They both had an answer. > Correct me if I'm wrong, but isn't Python completely object orientated > ? And doesn't it force you to write your code in an OO structure ? to > me that just seems like overkill for the average day to day sysadmin > task. As others have pointed out, this is wrong. The real difference between Perl and Python is that Python was designed with OO support, whereas it was tacked onto Perl later in life. As a result, some of Perl's builtin facilities are objects in Python which is to Perl's advantage. You can do pretty complicated things in Perl without having to know about loadable modules and objects. Even simple things in Python require you to deal with them. On the other hand, nearly all the Python modules are OO, which is to Python's advantage. It means that if an expansion module does *almost* what you want, you can import it and write a subclass that applies the appropriate changes. In Perl, you'd wind up copying the module and changing the new copy unless the module was done in an OO style. Real-world example of such: I needed to fetch a file from an FTP server. Both Perl and Python have modules to do that. However, this FTP server needed an ACCOUNT sent to it - check the RFC for FTP to see what that is - which neither could handle. In python, I just imported the ftplib module, subclassed it and provided a new login() method that accepted an optional account name(*). The Perl FTP module available then didn't allow that, and would have required either fixing the module, or copying it and fixing a new one. > Perl code can be ugly and wrong, but if written properly, it is easily > readable and easy to work with. "Proper Perl Style" reminds me of "Correctly Configured Emacs." <mike *) The python module now includes support for accounts. The perl ftp module included with the base system - which Perl I know is sadly out of date - still doesn't. -- Mike Meyer <mwm@mired.org> http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15436.37910.635122.378864>