Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

Re: Unix shell versus Perl

by sundialsvc4 (Monsignor)
on Feb 19, 2008 at 17:03 UTC ( #668846=note: print w/ replies, xml ) Need Help??


in reply to Unix shell versus Perl

I generally concur with that opinion, although I would have stated it in far fewer parargraphs and bullet-points and I would counsel you to do the same. (“Preachers” tend to get crucified, even if their message is immortal.)

Simply stated, I think that “shell scripts” are intended to be just that:   a moderately sophisticated way to tie shell-commands together. Nothing less, and nothing more. Shell-designers weren't trying to invent a general-purpose programming language (like Perl) since such languages already existed. Instead, they gave you the ability to use any command-processor you like, through the simple mechanism of (#!commandname) “shebang.”

A shop should agree upon a working-standard and then stick with it. But they should make sure that they're using the right tool for a particular job. All you'll get for the wasted-time that you just spent proving that a wrench can be used as a jackhammer is maybe “w00t! w00t!” (While you're perfecting your curious monstrosity, your colleagues are munching fish-n-chips down at the pub.)


Comment on Re: Unix shell versus Perl
Re^2: Unix shell versus Perl
by eyepopslikeamosquito (Canon) on Feb 20, 2008 at 04:44 UTC

    But they should make sure that they're using the right tool for a particular job.
    Using the right tool for the job is important; I've worked at shops where people wrote thousands of lines of C to accomplish what could be done in ten lines of Perl. Yet companies need to set a practical limit on the number of supported languages when they commit to maintaining code in these languages over a period of many years. After all, mastering, as opposed to dabbling in, a language, and its libraries, and its community, takes a lot of time and effort.

    What is a sound practical limit on the number of languages a company can comfortably support? I don't know, and it depends on the company, but my perhaps conservative opinion is that my company should support just one "fast" statically typed language and just one "dynamic" language. Maybe two. Any more than two would be a mistake IMHO. For example, I feel writing part of our system software in D, another part in Haskell, another in Erlang, and another in C++ would be a strategic mistake, even if each was indeed the "right tool for the job". Ditto for writing in a combination of Perl, Ruby, Python, and Lua.

    Update: Even a company as big as Google only allow three languages to be used for production code, namely C++, Java and Python.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://668846]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (11)
As of 2014-07-23 06:49 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (134 votes), past polls