[Israel.pm] Perl for C, C++, C#, Java, COBOL and VB programme rs

Yuval Kogman lists at woobling.org
Wed Mar 10 12:41:48 PST 2004


On Wed, Mar 10, 2004 at 22:01:57 +0200, Eitan Schuler wrote:

> Yep. Programming is a human work. Perl code can't program. It can lead the
> programmer to better solutions, to locate the problematic code.
> So we actually want to approve the perl is better than the old and well
> known grep and egrep.

I beg to differ - i use grep end egrep all the time, for weeding files.
Unless it's part of a program that's written in Perl, or I would need
captures, evaluation, the various funny assertions or conversion, I
wouldn't touch perl. Just because egrep and grep are old, and simple,
doesn't mean that they won't be useful.

	perl -ne 'print if /pattern/'

is longer than
	
	grep pattern

by 16 chars, and two of them are not very home-row savvy.

Everything has it's use. Especially if you follow the unix philosophy
that everything should be kept simple and reusable (a philosophy many
people use against perl, due to it's bloated nature (to which larry once
replied, and i'm paraphrasing, "this is untrue - people write small
tools with perl every day")).

The number of times I write 'cat' in one day is remarkable in contrast
to it's out-of-the-box usefulness.

The point that requires most attention, from my perspective, is that
perl allows you to do things that are a bit more complex than looking
for a pattern, and you can do them well with it.

For example, you can replace text interactiely in very few lines.
Suppose you want a multpile choice replacement filter, with slightly
more complex patterns than egrep can offer? Suppose you want to put a
small command that will give you more context? How much would this take?
50 lines? 100? That's not much.

The problem is that people are afraid of input greater than 10 lines.
They believe it has more complication, inherent problems, caveats and
unnoticed bugs, the need for stuff like variable initialization, and so
forth.

With simple, proper training, and a bit of the good laziness, Perl can
be used to overcome these problems, and give back far more value than
the cost of the little quirks it still forces upon you.

Regexps are not a good example. A good example is simple templating,
conversion, encoding, generation of constant data, test data, mock
objects (like devices, or other processes), documentation maintaince,
release preparation and distribution - all the things that are a bit
too much for a plumber with no intent on even saving the code that will
be executed into a file.

-- 
 ()  Yuval Kogman <nothingmuch at woobling.org> 0xEBD27418  perl hacker &
 /\  kung foo master: /me groks YAML like the grasshopper: neeyah!!!!!!




More information about the Perl mailing list