I look this up about every couple weeks, so I’m posting it here for posterity. In order to nicely format Data::Dumper output…
I almost always set
$Data::Dumper::Indent = 1; $Data::Dumper::Sortkeys = 1;
Data::Dumper. The first statement makes the output more compact and much more readable when your data structure is several levels deep. The second statement makes it easier to scan the output and quickly find the keys you are most interested in.
If the data structure contains binary data or embedded tabs/newlines, also consider
$Data::Dumper::Useqq = 1;
which will output a suitable readable representation for that data.
Much more in the perldoc.
This is a new, but very promising project to bring Perl support to NetBeans 7.x. I can’t really articulate *why*, but I’ve always preferred using NetBeans to other cross platform IDE’s (e.g. Eclipse).
Both IDE’s are written in Java, but for some reason NetBeans always seemed more polished (and faster) to me. It could all be in my head, but I’m glad to see a push to bring Perl support back to NetBeans.
They also have a Facebook page that you can follow for more news and updates about the project.
From the Perl-on-NetBeans project website:
This project aims at providing support for Perl on the NetBeans platform. It aims at filling in the void for Perl programmers on NetBeans platform.
Initially, the following are the features that are planned to be integrated with this IDE:
1. Perl File Type Support
2. Perl Project Type
3. Code Execution
4. Syntax checking
5. Perl Tidy and Perl Critic (Source code formatting and analysis respectively)
6. Syntax highlighting
7. Brace matching
8. Real-time error parsing
9. Code completion
10. Code folding
11. Debugger Support
Have you ever seen (or written) something like this in your Perl scripts?
if ( $^E eq "Access is denied" ) #...
I know that I have, and I also know that 2 years later I found that snippet much less readable.
$^E is one of Perl’s predefined variables that reports error information specific to the current OS. However, it has an equivalent/alias that is much more understandable:
That’s right, $^E is the same as $EXTENDED_OS_ERROR
So a better example of the original snippet would be:
if ( $EXTENDED_OS_ERROR eq "Access is denied" ) #...
I’d highly suggest that you always use the long-hand equivalent version of all the predefined Perl variables. Another option is to add the following to the top of your script:
use English qw( -no_match_vars ) ; # Avoids regex performance penalty
This module provides aliases for the built-in variables whose names no one seems to like to read. Variables with side-effects which get triggered just by accessing them (like $0) will still be affected.
For those variables that have an awk version, both long and short English alternatives are provided. For example, the
$/variable can be referred to either $RS or $INPUT_RECORD_SEPARATOR if you are using the English module.
See perlvar for a complete list of these.
This is pretty handy for someone like me that knows Perl pretty well, but is interested in learning other languages like Python and Ruby. This is also great as a cheat sheet for a language you already know well: http://hyperpolyglot.org/scripting.
For instance, I’ve been using Perl for years and had no idea that they had a REPL mode…well, it’s more of a pseudo REPL mode but it lets me use Perl interactively:
perl -de 0
Great article on Perl and Unicode. http://www.perlmonks.org/?node_id=551676
The days of just flinging strings around are over. It’s well established that modern programs need to be capable of communicating funny accented letters, and things like euro symbols. This means that programmers need new habits. It’s easy to program Unicode capable software, but it does require discipline to do it right.
There’s a lot to know about character sets, and text encodings. It’s probably best to spend a full day learning all this, but the basics can be learned in minutes.
These are not the very basics, though. It is assumed that you already know the difference between bytes and characters, and realise (and accept!) that there are many different character sets and encodings, and that your program has to be explicit about them. Recommended reading is “The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)” by Joel Spolsky, at http://joelonsoftware.com/articles/Unicode.html.
A word of caution, you don’t really need to care that Perl stores strings internally as UTF-8:
Please, unless you’re hacking the internals, or debugging weirdness, don’t think about the UTF-8 flag at all. That means that you very probably shouldn’t use is_utf8, _utf8_on or _utf8_off at all.
Perl’s internal format happens to be UTF-8. Unfortunately, Perl can’t keep a secret, so everyone knows about this. That is the source of much confusion. It’s better to pretend that the internal format is some unknown encoding, and that you always have to encode and decode explicitly.
I’m always a little wary when someone writes an application targetting the .NET Framework and then says it’s only 80k. Well, assuming you have the .NET Framework/runtime installed…which weighs in at hundreds of megabytes depending on the version and CPU architecture.
Details on the hardware requirements now that .Net 4.0 has been released. The minimum disk space requirements (as of September 2010) seem a little steep:
.Net 2.0 x86: 280 MB x64: 610 MB
.Net 3.5 x86: 280 MB x64: 610 MB
.Net 4.0 client x86: 600 MB x64: 1,536 MB (1.5 GB)
.Net 4.0 full x86: 850 MB x64: 2,048 MB (2.0 GB)
I know I’m a snob, but I’ll stick to native programming languages when it comes to writing desktop applications. And hack everything else together with Perl ;-)
A good reminder that you don’t actually know anything about programming ;-)
In all seriousness, I ran across this and think it’s an excellent way to test yourself on your understanding and knowledge of not only a programming language, but operating systems and writing software as a discipline.