Yesterday I posted about not overwriting a file until you knew you had completely and correctly stored its data. Part of that was about data security and another part was completeness for other consumers. I used a temporary file and rename to move the new file into place. That’s not the entire story though.
Continue reading “Copy instead of renaming to preserve hard links”
How do you replace the the contents of a file? This is something I’ve been thinking quite a bit about because we often get away with bad practices, and it’s completely within the scope of Learning Perl to know how to do this. It might make a good edition to the next edition of the book.
Someone on Stackoverflow asked if it was okay to read from a file then write back to the same file. In this case, completely read the file and once done, write to the same filename. Most of the answers deal with the mechanics and miss the wisdom of that design.
That’s a problem with tutorial books too: there are only so many pages.
Continue reading “Use a temporary file instead of clobbering data”
In Chapter 12 of Learning Perl, we have an exercise for people to practice using the file test operators. Our answer, which can only use the stuff we’ve covered in the book to that point, is simple: Continue reading “Ruling the world with Perl and Excel”
There’s a debate raging in Perl 5 Porters over some updates to perlopentut. Mike Doherty sent a patch to remove the bareword filehandles, stepping into the overlapping minefields of fashionable practice and documentation authorship. That second one is beyond the scope of Learning Perl, so I’ll ignore it even though that’s almost the entire debate.
There are three reasons we teach bareword filehandles in Learning Perl: generality, immediacy, and history. Having said that, we are not choosing between barewords or filehandle references, even if we do use the references for most of the book. We’re agnostic, and we leave it to our reader to make the best choice for them. We don’t see out job to tell you how to program. We just want to explain what Perl actually lets you do.
Generality: We don’t write books for individual people. That just doesn’t work since it would take more time than any author has, even if authors did nothing but write every second of every day. For a book such as Learning Perl which sells tens of thousands of copies just in the paper version, we have many sorts of people to think about, virtually none of whom we have ever met, will ever meet, and will never give us feedback. We don’t know why you are using Perl. You could be system administrators, web programmers, data mungers, or, sometimes, non-techies. We don’t know if you are writing new code or adjusting old code. We don’t know what you need, so we don’t make judgments based on what we don’t know. If you are talking to one of us during a face-to-face class, we can ask you questions and find out more about what you need.
Perl suffers from success in vastly different areas. You can write quick one-liners or huge, enterprise systems. You might need an interactive user interface, or not. Different tasks and different domains require different practices. Instead of assuming that you are going to limit yourself to just one of those areas, we aim to make Learning Perl useful to most of those areas.
Immediacy: In a tutorial like Learning Perl, we have to start somewhere. A bad book can quickly overload a reader with several concepts at once. Our goal is to get people writing code as soon as possible, which is the fundamental goal of Perl. Larry Wall wants people to be able to program even if they don’t consider themselves programmers. He doesn’t want people to have to spend hours of research to be able to doing something useful quickly. Larry’s term for this is “baby Perl”.
There are several concepts that go into a this single line of Perl, none of which are immediately useful to someone who wants to write the sort of short program we consider in Learning Perl:
open my $fh, '<', $filename or die '...';
In their first afternoon of Perl, the new programmer has to be comfortable with my as well as the concepts around open, its modes, and its lack of punctuation. That my $fh inside a larger expression is really confusing for beginners. We don't make any judgements based on that. We just know that's the way it is. To avoid the extra sources of confusion, it's easier to reduce the problem to one with the fewest distractions:
open FILE, $filename or die '...';
Don't forget that the tutorial for open is almost 1,000 lines long. This is not a simple built-in. Once people get used to the idea of a very basic open, we can expand on that to add more to the readers knowledge and understanding. All education is a continual process of refinement and adjustment as you integrate new concepts with what you already understand.
History: Finally, no matter what we personally think about one form or the other, we can't deny that people are going to see the bareword versions. The "Modern Perl" movement would like to pretend that bareword filehandles don't exist, but they can't ignore STDOUT, STDERR, STDIN, or DATA. Perl has bareword filehandles and most people are going to write new code using bareword filehandles, indeed, even relies on those barewords, even if they subscribe to all of "Modern Perl". Putting that aside, though, people are going to see bareword filehandles in old code. Our readers need to know what those are and what they do. Programming is not just about writing code, it's about reading code. We can't hide widespread patterns because they've become unfashionable to some people.