How would I do this in perl?

[Ilya Zakharevich]

To the contrary: unless in a 1-liner, one should carefully consider
using bareword filehandles.

[If code is supposed to be reused, you rarely know on which version
of Perl it is going to be reused.]

If the code needs to be backward compatible to before 5.6, then you have
much bigger problems to worry about than bareword filehandles.

I really have no clue what you are talking about. (I never worry
about bareword filehandles. Only about non-bareword ones...)

Yours,
Ilya

 

[Ilya Zakharevich]

*I* can generally be fairly certain my code won't be used on perls
before 5.6. For one thing, I almost always 'use warnings'.

Yet another counter-productive pragma... (Unless in a module...)

Yours,
Ilya

 

[ccc31807]

You have never mistyped a filename?

Who types filenames? I use Windows at work, and Windows has a nifty
shortcut that allows the insertion of filenames without typing them.

You are so awesome!

Thank you very much -- you've made my day. ;-)

checking the return value from open() is needed in every situation,
because it can fail in any situation.

Maybe this is the point. It's NOT needed in every situation. We all
can think, in theory anyway, and we all can determine when to take
shortcuts and when to paint by the numbers. Yesterday I revisited a
script that I had written some time ago and in which I had used a
number of infamous Perl shortcuts, and which took me several minutes
to interpret -- and which I immediately rewrote in a literate
programming idiom because I needed to reuse the logic in what will
become a standard script.

It's not that using shortcuts is wrong, and that using literate
programming practices is right -- it just depends.

I have open() with return value checking saved in an edit buffer, so
I won't be tempted to spew bad code upon the world.

Now, that's a good idea.

Code posted here is likely to be copied by posters days, weeks or
years from now.
Seeding failure is a disservice to our community.

Can't disagree with that.

If you cannot be troubled to post Good Code, then don't post code,
Perl programmers will be the better for it.

And what is 'good code?' I got slammed in another thread a few weeks
ago for not using typical shortcuts, such as using $_ in a block
instead of assigning $_ to $line and using $line in the block.
Readability and terseness are both virtues, but they mostly are
mutually exclusive. Example: I've been writing Lisp in my off time and
have learned that writing Lisp is easy because it's very abstract, but
reading Lisp is difficult because it's very abstract.

'Good code' is many times a matter of opinion, and we've got better
things to do than imposing our opinion as code police.

CC.

 

[Charlton Wilbur]

cc> me several minutes to interpret -- and which I immediately
cc> rewrote in a literate programming idiom because I needed to

"Literate programming" does not mean what you apparently think it means.

cc> And what is 'good code?' I got slammed in another thread a few
cc> weeks ago for not using typical shortcuts, such as using $_ in a
cc> block instead of assigning $_ to $line and using $line in the
cc> block. Readability and terseness are both virtues, but they
cc> mostly are mutually exclusive.

Except when they're not.

Using $_ idiomatically is terse and readable. Providing a variable name
to alias is also idiomatic, though less terse, and also reasonable.
*Assigning* $_ is almost never idiomatic; I'd say "never," except that
if I did so, someone would come up with a rare situation where it is
idiomatic.

The correct solution for someone who cannot follow using $_
or @_ idiomatically because he or she is new to Perl is not to eliminate
$_ and @_, but to explain the use of $_ and @_ so that he or she can
learn about idiomatic Perl. The audience for my code, simply put, is
not Perl novices.

cc> 'Good code' is many times a matter of opinion, and we've got
cc> better things to do than imposing our opinion as code police.

We're not talking only aesthetics, which are a matter of opinion --
we're also talking best practices versus sloppy practices.

There is no reasonable argument that not checking the return value of
open is a sloppy practice. Do it in quick-and-dirty scripts if you must,
although typing 'or die "error: $!"' involves substantially less effort
than you've put into the defense so far; just don't delude yourself
that it's acceptable to post that quick-and-dirty code to Usenet.

And if you do persist in the delusion -- which looks likely, because
this is not the first time we've wrangled this out with you -- then at
least accept that if you persist in posting sloppy code, we will persist
in correcting it and commenting on it.

Charlton

 

[ccc31807]

Umm... OK. You've never written a script to create a file that didn't
exist yet?

I write them all the time, usually in the context of creating a report
from a data file. This might be hard to believe, but in my experience
open() usually fails when a file is locked (e.g., by Excel), and those
kinds of error messages are pretty clear.

I don't think you know what 'literate programming' means. AFAIK there
are no LP tools for Perl. (They are mostly unnecessary, of course, since
Perl is a higher-level language than Pascal.)

I understand 'literate programming' to mean writing code as much as
possible like natural language, using self-documenting names, using
abstractions to hide the details, as so forth.

    use autodie;

Not familiar with this, but I'll check it out.

Readability and terseness are both virtues, but they mostly are
mutually exclusive.

I strongly disagree. Verbosity can be just as confusing in a programming
language as it is in a natural language. The aim should always be to
make it clear what the code is doing and why, with as little extraneous
mess as you can manage. Sometimes this means spelling things out;
sometimes an idiom like

    s/\s+$// for @lines;

is much easier to understand than something like

    for my $i (0..$#lines) {
        $lines[$i] =~ s/\s+$//;
    }

(and even that has at least two constructions that would be completely
bewildering to someone just starting to learn Perl.).

Not to mention 'common' shortcuts, like using <> alone to grab the
header of a file:
my $header = <DATAFILE>;
or using ||= to check for initialization of a variable:
my $header ||= $_;

I would write the above as:
foreach my $line (@lines) { $line =~ s/\s+//; }

AIUI reading (well-written) Lisp is supposed to be easy, because it's
very abstract. However, I don't know Lisp, so I can't really say.

My trouble with reading Lisp is that the style seems to promote the
multiplication of small functions that are deeply nested, so that it's
easy to get confused tracing all the calls. It's very easy to create
and test functions on the top level, so you write a myriad of very
small functions and use them to build a more complicated structure ---
but just try to revisit your code after a month and untangle it.

CC