There are a lot of “12 CS books every programmer must read” lists floating around out there. That’s nonsense. The field is too broad for almost any topic to be required reading for all programmers, and even if a topic is that important, people’s learning preferences differ too much for any book on that topic to be the best book on the topic for all people.
This is a list of topics and books where I’ve read the book, am familiar enough with the topic to say what you might get out of learning more about the topic, and have read other books and can say why you’d want to read one book over another.
Some time ago I posted two comments in the Perl group about the “speed” topic. The Need for Speed: use 5.024; and The Quest for Speed: What not to do. The first one is a simple recommendation to use Perl 5.24 as it really gives your real world application a speedup of roughly 25% overall – sometimes it may be even 200% (regular expressions), sometimes less. The second was basically a negative report on my compile optimization endeavors and the lack of (significant) success. On a side note, I debunked the performance claims of cperl – which is something I am truly sorry about, because some day I really would like to see cperl to actually be where it claims to be today.
I also promised to write a thing or two about what you really should do, when you’re looking for performance (aka execution speed) in your Perl programs. If your goal is not 25% improvement and not even 200% or anything short of “10 times as fast as the original code”, then this article is for you.
This is the question that we get asked immediately when we tell someone that we use Perl. Our extensive use of Perl to build many of our internal services often comes as a surprise to many and we can understand why. Perl is a dinosaur among mainstream programming languages. It lacks the glamour that other, relatively younger languages have. There is also a common misconception in the programming world that modern software engineering practices cannot be followed with a language like Perl. In this post, we hope to debunk that myth. We want to give you a glimpse of the developer experience (DX) here at Semantics3 where we write a lot of Perl code but still manage to employ the latest engineering best-practices. We would like to highlight that we are able to do so with the help of a tool-chain written entirely in Perl.
Useful One-Line Scripts for Perl Dec 03 2013 | version 1.10
-------------------------------- ----------- ------------
Compiled by Peteris Krumins (email@example.com, @pkrumins on Twitter)
http://www.catonmat.net -- good coders code, great reuse
Latest version of this file is always at:
This file is also available in other languages:
Please email me firstname.lastname@example.org if you wish to translate it.
Perl One-Liners on Github:
You can send me pull requests over GitHub! I accept bug fixes,
new one-liners, translations and everything else related.
I have also written "Perl One-Liners Explained" ebook that's based on
this file. It explains all the one-liners here. Get it at:
No Starch Press has published "Perl One-Liners" as a real book too:
These one-liners work both on UNIX systems and Windows. Most likely your
UNIX system already has Perl. For Windows get the Strawberry Perl at:
by Pete ‘Zoffix Znet’ Evstratov
- Get the current version of these slides in HTML, PDF, or POD from here:
- See Appendix 1: Fonts at the end of this talk for instructions on font set-up.
- These slides were written in pod using vi, with the help of a score of Unicode tools available via the link in Appendix 2: Tools.
- This slide show was built using
Pod::S5 by Tom Linden, which in turn uses
S5 by Eric Meyer. Slideshow controls appears if you hover near the bottom right corner, but I ﬁnd it easier to use keystroke commands to navigate.
- I’ve used next to no HTML tricks here; nearly all fancy‐qua‐weird stuﬀ you see here is actually Unicode.
“Perl has a long tradition of giving nicknames to some of its operators (possibly a form of Huffmanisation). These nicknames are based on the appearance of the operator, rather than its function. The well-known examples are the diamond operator (
<>), nicknamed by Geneva Wall and the spaceship operator (
<=>), nicknamed by Randal Schwartz. Some lesser known Perl operators with a nickname are the fat comma (
=>) and yada yada (
The Perl “secret operators” have been discovered (or created) by Perl obfuscators and golfers, usually when looking for a shorter way to perform a given operation. Secret operators are not actually secret, and they are not actually operators either. The perl parser does not specifically recognise them, and no one is trying to hide them from you. But they are like operators in the sense that these Perl programmers see them often enough to recognize them without thinking about their smaller parts, and eventually add them to their toolbox. And they are like secrets in the sense that they have to be discovered by their future user (or be transmitted by a fellow programmer), because they are not explicitly described in the Perl core documentation.
Because secret operators are not operators they don’t have real names, and so they need nicknames. Like the above Perl operators, their name is usually related to their shape.
The term “secret operator” was probably coined by Abigail in a
comp.lang.perl.misc post in January 2003…”
“Not “all of Perl 6”, because we don’t have time. Rather, enough to help you bootstrap an understanding of Perl 6, so you will be able to go away and keep learning…”
“Perl Training Australia regularly sends out a useful tips about the Perl programming language to make your coding easier. These tips include Perl’s core features, useful modules, tricks and traps, and recent developments…”