I personally would never ever advice a novice perl programmer to use common::sense, Modern::Perl or whatever module that replaces use strict; use warnings; and use autodie; for several reasons. The main reasons are:
- They are not part of perl CORE. That implies that the user has to install perl modules, which is most likely not part of their homework.
- They are not likely to show up in any example code in the standard perl docs.
- It does not hint towards what these programmers will see in everyday scripts and examples they see on the internet when they browse for examples.
In fact, it is way more likely that I will remove such declarations in scripts that I receive from others if I have to use it, than that it is likely that I will change my headers to move to whatever replacement for the default tantra is currently seen as best.
Remember that this is a guide for a homework-beginner. Not for a seasoned programmer that knows exactly why (not) to use common::sense.
I think I am a seasoned perl prgrammer, and I use git, elvis (a vi clone), strict, warnings, and more and more autodie.
Enjoy, Have FUN! H.Merijn
| [reply]
[d/l]
[select] |
Remember that this is a guide for a homework-beginner.
That's exactly why the second page of the Modern Perl book shows how to use Modern::Perl and explains what it does. It's awfully silly to poke fun at all of the boilerplate Java programmers have to convince their enterprise strength IDEs to emit for them before they can write "Hello, world!" when any correct Perl 5 program worth writing in 2010 has several lines of equally opaque boilerplate.
| [reply] |
#!/usr/bin/perl
use strict;
use warnings;
instead of two lines:
#!/usr/bin/perl
use Modern::Perl; # Or whatever todays fad boilerplate is
The savings of not typing a single line of code doesn't out weight the issues Tux mentions.
Now one may argue "but my 'use Shiny::Boilerplate;' includes a whole shit load of additional modules", but that only makes your boilerplate less generic. Because for each additional module/pragma in your boilerplate, a significant (probably > 50%) part of my programs/modules doesn't need it. | [reply]
[d/l]
[select] |
| [reply] |
Hi!
Thank you for your reply.
To offer a different perspective, I love git and I'm very happy with vim as my editor. I also prefer common::sense rather than strict and warnings.
Nothing against vim ... I'm just talking about users who come from a non-Unix background (Windows or OS X). When I first started using Perl under Windows, I was grateful for eshell and the respective output windows provided by Emacs.
In case someone wants to use vim under Windows to edit Perl, I would recommend installing MSYS - the Windows DOS box has too many limits.
Finally, when you're new to Perl, it's tempting just to write everything yourself. You'll burn up lots of cycles that way -- check CPAN instead and see if there's a module that does that already. You never know until you look.
Fine - as soon as students work at home, they're free to download and use any module they want.
In a computer lab, however, restrictions similar to those discussed in Yes, even you can use CPAN apply: even when your disk quota is high enough to install CPAN modules locally, your instructor might want you to solve a given problem yourself. | [reply] |
I'm a vim lover, but I'd take that first bit about "what editor to use on *nix" completely out (or else, do a real survey). You do not have to pick between emacs and vim, and I would not necessarily recommend either of them to people both new to programming and the *nix environment. Why not tell them how to sit in the chair as well -- and that the chair must be on a pedestal with wheels, not four legs? And that you must have a wheel on the mouse? Etc...
There must be close to a dozen GUI editors with syntax highlighting for perl available under linux, and most systems will have one, eg, gedit, available. Those tools are very simple to begin using at once, especially for windows users who will be comfortable with their mouse and menu driven interface. Vim and emacs are great, of course, and no doubt later on you may want to explore the real tish, but gedit is totally sufficient at first and requires no attention, leaving you to focus your mind on perl and not contemplating bells and whistles like "code completion", key macros, six different ways to cut n' paste, etc. Or having to read a tutorial in order to type a script, save it, and load it again without problems. Type. Save. Load. Syntax highlighting. Cut n' paste. Maybe print. That's it. All the common linux desktop environments (gnome = gedit, kde = kate, xfce = mousepad, et. al.) have something standard integrated into them that will do those things via some nice iconic toolbar. Point and click. No installation or tutorial required.
Other than that diversion, this looks like a nice, succinct set of beginning tips. WRT use strict, etc:
use warnings FATAL => qw(all);
Is a great thing to know about. Beginning programmers easily ignore warnings "because they aren't real errors" and miss the significance of, eg, mistakenly using uninitialized variables in the wrong place. Generally when developing something, I don't want it to "keep going anyway" if I get warnings -- it's much easier to stop right there and fix the first problem that arises. And, just like there is no good reason for a program to be unable to run strict, there is no good reason for it to produce any warnings. Start with the good habits and best practices right away and you will never find them a hassle later on. | [reply]
[d/l]
[select] |
I find that gvim works quite nicely native under Windows. And I agree that the instructor might well insist on the student solving it on their own. Sometimes we learn more from a re-invented wheel than from simply 'remounting' one.
My best professors made us learn what useful tools did by writing one before they allowed us to use them. Of course that was back in the stone table an dbear skin days
Misha/Michael - Russian student, grognard, bemused observer of humanity and self professed programmer with delusions of relevance
| [reply] |