Been using Perl for almost 10 years now. I've used Perl for almost everything. Web development using CGI::Application, developing my own web framework, console apps (using the ncurses library), POE (Perl Object Environment), Web socket stuff and more.
My main job currently involves maintaining and developing a huge code base in Perl including three websites (soon to expand to much more). Perl just works. I thoroughly enjoy coding in it. I've not spent too much time optimizing and testing code though. mod_perl is pretty fast in itself (using Apache).
That being said Perl certainly lacks the in-built features which would make meta programming a quick and easy job. Yes, I still have to start using Moose. Perhaps in 2014!
Happy 26th Birthday Perl! Without you, I wouldn't have a job!
I'm personally interested to see how this develops.
As to my own Perl story, I used it exclusively in my first (non-student) programming job, back in the summer of 2000. I built an e-commerce website, CGI, with a cookie-based shopping cart. All from scratch, no frameworks, etc. I don't even know if there were any back then.
Fast forward to the year 2011. I started using Perl again, and loving it. Still use Perl every day. A fluid mixture of procedural, functional and object-oriented code. I really enjoy the language.
Ha ha, your nickname says it all. Back when I started programming in 2000 all my yahoo, MSN and skype (when it was released) accounts either had the word linux or perl in it.
Then unfortunately I had to become more professional and started using my real name. :)
That's cool. :) But I'm sure the correct statement would be untangling messy code written in "your non-favorite language" and rewriting it in "your favorite language or management's choice based on buzzwords". :)
Is there growth in the actual number of Perl full-time positions or is it declining?
Companies obviously need Perl programmers to maintain and enhance existing systems, but we don't see or hear about any new start-ups using Perl as part of their stack.
Fwiw: I don't use Perl anymore but was a fan and love Moose and CPAN.
We're a growth stage startup hiring perl programmers to do new development in the Los Angeles area. Perl isn't the only language we use (we have some python), but it's widely used throughout our systems.
I started in a new Perl position with my current employer in 2012. We just filled another new (mostly) Perl position a few months ago. I can't speak to the total numbers of positions available, but there is work out there for sure and it's not by any stretch strictly maintenance programming.
Perl is definitely a cool language. I've used it for 15 years. However, I feel like it made a wrong turn somewhere and Ruby and Python both passed it. I've done a a little Ruby and some Python. They've never grabbed me like Perl, but practically speaking I don't think there are enough reasons to choose the 3rd most popular scripting language. (Btw, I've listened to the CPAN argument for 10 years. It's not enough)
The wrong turn was "Perl 6", and despite what you may think, the problem was more in the "6" than the "Perl". There's nothing wrong with Perl 6, except that it should have been called something else so it didn't convince people it was the next Perl version. The Perl community has now recovered from that, Perl 5 and Perl 6 are officially understood to be distinct languages that merely love each other very much, and Perl 5 development has resumed at full speed, but it lost a lot of time and mindshare before finally getting there. (Probably not a heck of a lot of use share, though. It's still there in a lot of places, working away, quietly.)
True. I started with Perl in 2003, and there was news of Perl 6 being just round the corner then. The constant chimes of it will be ready "soon" with no specifics kept people excited for a while, but that wore off.
So when I went to Google I learned Python. I enjoyed the language and used it a lot, it has a solid support base and pretty much anything you wanted to do you could import a module to do it. When I went to Blekko they were a perl shop, which was a bit intimidating at first, but after programming in it for nearly 4 years now I find I can get from concept to first test faster in Perl than I could in Python. And I hadn't realized how much the Python indentation stuff bugged me until I got back into a scripting language with braces.
At the end of the day I find I prefer perl for quick things, and Python for multithreaded things.
Python's philosophy may be limiting for some people, but I'd rather have code that I have a decent chance of reading and understanding the run-time behavior of than a language that encourages extreme personalization.
So you can't stand any and all programming languages? Because you can do anything in more than one way in all languages. And that's the whole point in 'programmability'.
And secondly its extremely rare that you will run into some obscure feature which indulges in the whole parsing thing you mentioned.
I'd rather have a language where i can look at the code and decide with a glance whether it's batshit insane or not, than a language where the best code possible looks just like the most horrible and insecure garbage. :)
Can you please expand a bit on "Python for multithreaded things"? My understanding was that Python interpreter has a GIL, which limits the concurrency and performance.
It is a reasonable question. I tend to write like I talk, which the Chicago manual of style frowns upon. It isn't a particularly 'creeping' pattern, it is quite common amongst people with whom I have regular informal conversations.
That said[1], I probably feel the same way about the use of 'because' in informal speech. Which was recently upgraded to include the form "because <noun>." I don't find that a particularly compelling upgrade.
There was a recent album release called "Because the internet". Absolutely horrific :-)
---
I think what gets me about leading with "So" (more so in spoken converstaion) is that it makes the speaker sound like they're constantly, and consciously, having to reframe things in a form that the poor dummy they're speaking to will understand.
Politicians do it a lot when answering questions.
I also recognise that it's more innocently used when telling a story.
I can see that aspect of it, I typically use it as an equivalent to "In my experience ..." or to convey a result that is derived empirically rather than reasoned do by first principles. I consider such things more 'as a personal preference' rather than having any sort of definitive reasoning behind them.
Could you explain what features or aspects made it quicker to get up and running with? I love Python and have never worked with a language that I felt let me get features out so quickly. Do you feel you've sacrificed readability as well? I've heard Perl is notorious for having a million ways to do everything, making reading it hard.
I'm not the OP, but I've had a similar experience and agree with him about Perl.
For me...
* perl is a bit more intuitive, even though I've done about as much python as perl at this point.
* It's the best language for dealing with regular expressions in my view. You don't have to create a regex object and muck about with all of that.
* You can create lambdas/closures with fewer restrictions than Python (this is a big one)
* CPAN is pretty good. Python comes with a lot of libraries, so this isn't as much of an edge as it used to be.
* It is more widely available on other servers, even older ones, which is important for me because I'll sometimes have to do work on a machine without Python already installed. I can work with older perl and I've never been on a machine without it installed.
* The whitespace issue really is annoying to me. With braces you can move stuff in and out of conditionals, etc, easier than with Python, even with editor support.
As for readability, I try to write reasonably well, even if in a hurry. I know the language and its syntax. I understand the purpose and meaning of the sigils, so it doesn't look like noise to me anymore than reasonably written python. In Python, for instance, I've seen list comprehensions that are pretty frustrating to puzzle through. Perl with strict and warnings and written without a specific aim to be clever isn't hard to read.
perl is more connected to things flowing through it. In python I was often fighting with the subprocess module to get things plumbed but in perl it was trivial to open a process to a pipe and then put a process on the output of that pipe. Much of the code I've written here does analysis for bad actors (robots and such) and perls regular expressions have been easier to get right sooner. (although the naming of results in Python is quite useful).
When I was at Google I started using Python to create a CMS of sorts for my toy website (robotics.mcmanis.com) which got to the point of being able to push some stuff but more complex stuff was a pain. So it sat there. Then rebuilding that with perl and the template toolkit it was a bit easier and I was much happier with the result. I still don't have a lot of time for it (like none for the last few months) but I got the framework for putting up a new "article" down to a pretty smooth process and managing all the internal links worked well.
Perhaps it is that I programmed in C for so long that my synapses are more attuned to reading code with braces. But I find I can look at perl and intuit its function much more quickly than I can do the same for Python.
I will look at Xslate. My simple system basically combined a markdown (with some enhancements) "base" document, with custom image tags and source tags. The current source to HTML mechanism used vim to do the syntax coloring, then dump out the html with ToHTML and then processed by the perl code to pull out the actual code. Given that I've been moving code over to github my plan for the future is just to pull gists into the HTML pages.
To the extent that I can simplify steps with Xslate we'll see. It still takes too long to go from 'thought' to 'page' (and my 'schematic description' -> SVG (or PNG) schematic work is still incomplete)
It was my first exposure to dynamic programming languages (unless you consider BASIC one). I started out on BASIC on an Amiga 500 then C on my first DOS 386 computer (I just wanted to learn to make games). I came across Perl in my final year of high-school when at a co-op placement with a local web development shop. The school taught Pascal and a little-known language called, Turing. Scalars were super-cool by that point.
It's amazing to see how far things have come and that Perl continues to get better despite the downward trend in its popularity in recent years.
Two main aspects of Perl that have always drawn me time and time again back to it are (1) the get-it-done mentality (there's more than one way to do it, and what really matters is completing the job) and (2) the huge repository of modules that is CPAN.
Evaluating other environments along those lines yielded interesting frustrations. In my opinion, the real contender is node.js, thanks to its minimalist approach on many things, and NPM.
Note: I'll admit that Node forces you to be as async as possible, but it's for a good cause so I can turn a blind eye on it. :)
Yes! Many thanks to Larry Wall for having invented a tool that stands the test of time; I am wishing him well, I read he had health related problems in recent years;
Was introduced to Perl in a programming languages course in college in 1996/1997. Brought it to my first job, where it gained fame there for being the language that took a 12 hour process and ran it in less than a minute. (They had originally been trying to parse a huge log file with Visual Basic, I believe it was. Perl was made for, well, extraction and reporting...)
Been programming in it full time ever since.
Thanks, Larry Wall, Randall Schwartz, Brian Foy, Nat Torkington, Tom Christiansen, Damian Conway, etc. etc.
Count me in as another person introduced to O'Reilly via "Programming Perl." Was "Perl Best Practices" the first such "Best Practices" book?
Well, perhaps one can treat my comment as good part fondness/nostalgia.
Although, I clicked through the pop-up link, to find a fairly brief and limited set of points in a short, single critique of the 4th edition.
I don't know... It's been a while, but I still remember "Programming Perl" as providing not just the what but a good dose of "why" and context.
A lot of people who "don't like Perl" don't seem to understand that, where it's coming from, both philosophically and systematically (if that is a word and I can use it here).
"Programming Perl" is not, in my opinion, a beginner text. Randal took care of that contemporaneously with "Learning Perl". But it was, and -- current shortcomings aside -- perhaps still is, a good post-beginner text.
It also remains "timeless" for me, in that it was a good, engaging read. In my opinion, more texts should -- if clever enough to -- dialog with the reader rather than spewing at them.
Anyway, I don't mean to put myself in the position of defending Larry et al.'s tomb in this post-post-modern world. I'm hardly qualified to begin such a task.
But even if it's not currently the best reference, or even recommended as such, I think it may remain a decent example of how to write one.
> I think it may remain a decent example of how to write one.
No contest. I'm just worried that, with many people mentioning the "good old books" (which by now are simply bad), without mentioning the current good ones, more newbies will try to get those old books and learn from them and get themselves and others in a lot of trouble that way.
That's why i comment to explain and point out alternatives.
I think I ended up with a (legitimate) ebook of the 4th edition, but I haven't tried it.
Newcomers should understand that Perl is beget of its *NIX heritage. With some understanding of this, it stops being "line noise".
Perl was the language I encountered that "thought the way I do". For those considering, I think this remains a very relevant factor in its continued existence. For what that's worth.
"Programming Perl" was the first computer "textbook" I ever read with a sense of humor. Before that, it had been all dry C books and the like. That's why I liked it so much. Yes, "Learning Perl" would definitely be better. At the time, I wanted both the tutorial AND the reference book, so that's what I got.
"Intermediate Perl" is still awesome for the next level stuff, particularly with all the references and transformations, et. al.
For those wondering about startups using Perl for a large part of their codebase, DuckDuckGo is certainly one. There maybe others too but mostly it's for server side scripting.
Favorite Perl story (despite it being the first language I used to program the web back in college).
I once had to work on a an ASP (MSFT Active Server Pages circa 2001?) website that was written with ActivePerl [1]. Their technologist chose it, then left the company, and they had a hard time finding someone to work on it.
Also, the Programming Perl book was my first O'Reily book that I read/used, checkout out from campus library.
I think that Learning Perl and Programming Perl were the books that put O'Reilly on the map. Lerning Perl was the best intro to programming book of it's generation for sure.
That's an interesting article but seems to be missing the actual why of it. He still likes perl because... culture? Some people are still writing software in perl or cobol, sure - and some of that is good software that solves real problems. But the reason we think of the average programmer in one of these obsolete languages as "some sort of second-class technology citizen" is that, well, they are. Compared to the rest of us they spend more time working around language deficiencies, inadequate tooling and all the rest of it, and less time making interesting things.
Right now I'm a huge Scala fan. I've had that experience of feeling that I never want to program in any other language again (and every other language I've gone to, even those I used to like, feels clumsy and tedious by comparison). But I hope that in 25 years' time I'll have moved on to something even better. Language design isn't done, and languages are getting better all the time.
Interesting. What does Python make harder? In Perl I find myself missing list comprehensions, shared-by-default threading, a well-integrated object system, and a comprehensive, integrated, popular web framework. (Also a standard way of doing event-driven programming, but that's a fair criticism of Python too). And while I'm sure the tooling functionality is there, everything just seems less obvious and standard (e.g. where's the virtualenv equivalent?)
In Python I miss a switch statement, anonymous functions longer than a single line, and an object system with the power of Moose. I don't think shared-by-default threading is a good idea, and Python's GIL makes it close to pointless.
I also miss a web framework like Django or Rails in Perl. I never liked Catalyst, but have not spent much time with it.
I cannot judge if the tooling is less obvious, but think the tools are better, especially in regard to testing. There is a virtualenv equivalent called local::lib, but I recommend the bundler equivalent called carton ;-)
If you like Django/Rails I'd suggest you check out Perl's Mojolicious - very modern Perl web framework. There's also Dancer - both seem much easier to use & set up than Catalyst
Indeed. Perl does have Jifty and Gantry which do have out of the box support for the M part of MVC, but for whatever reasons they never became as popular as Django/Rails.
With perl I always include the M inside my application class/module.
And I use only VC from the web framework.
That way, i get thin controllers only for url mapping which in that case will access my application class/module instance.
Thats where the real code will be, in my application and not-in-the-web-framework.
With this environment its easy to switch and test other web frameworks avaliable because i will only need to create the thin controllers and re-use my templates. Plus, when i need a cronjob, i use my application without the VC.
In the end the real deal is: dont tie your application with webframeworks. Always use the M inside the application and from the web framework use VC only with thin controllers.
Put the real code inside the aplication. Make the framework use the application. Dont make the framework your application.
You haven't found any of the major Perl web frameworks? You haven't seen Moose for OO? perlbrew? (Don't get me started on list comprehension, extra stuff to learn because Python lack real maps with real lambdas.) And so on...
Do you always have opinions on stuff you have no clue about?!
Start with getting the Modern Perl book and read it (free pdf). Ask (/search) on Perlmonks.
> You really prefer Python threading to anything?!
Sure. When I just want "run this task in the background, I don't particularly care about throughput but don't block entirely". There's a niche where a proper task queue is too heavy and shared variables are a perfectly adequate communication mechanism.
> Don't get me started on list comprehension, extra stuff to learn because Python lack real maps with real lambdas.
They're a nicer abstraction for many purposes. Look at their Haskell origin, or Scala for/yield.
For stuff so trivial that even the GIL is no problem, most any utility should work... (You don't seem to know that Perls are usually not compiled with threading support?) It just isn't interesting to talk about.
I argued that list comprehension's use cases are generally solved better with "real" lambdas + map (==> less to learn). To note that most every feature have some use case they are extra good for is not relevant.
But again -- why do you discuss subjects you obviously don't know? Ask instead.
You don't seem to know that Perls are usually not compiled with threading support?
I've heard this a few times now, and find it interesting. I guess people that compile their own do it without threading support, but I would guess the majority of Perl interpreters out there were bundled from some third party (usually the distro), and those almost always have threading enabled.
Also, that's a good thing. I've made quite heavy use of threads over the years and find Perl's abstraction of OS threads is actually quite nice to use, as long as you play to their strengths. I.e. pre-create your threads, and thread them like pthreads with easier IPC. If you want "green" threads, use any of the numerous packages that provide it.
> You really prefer Python threading to anything?!
The Python 'process' and 'queue' modules rock (yes, multiple single threaded processes still counts as multithreading). I've had apps on the front page of HN / Smashing Mag using them, happily taking advantage of a multicore server.
I swear half the people who bitch about the GIL have never used either of these modules (not you, people in general).
Using multiple single-threaded processes still counts as parallelism, sure, but please don't set a precedent for using the term "multithreading" to mean something other than "using multiple threads". Nobody who works professionally on these sorts of problems would understand "multithreading" in the way that you're using it. (The term is overloaded enough as it is, given that it glosses over the distinction between user-space and OS threads...)
I understand your point, but there are people who'd argue non-OS 'threads' aren't actually threads either - if ps -eLF doesn't show more than 1 LWPs for your PID you're not considered multithreaded.
I answered a comment re threading, not different multi process implementations.
(All the popular scripting languages have bad threading support and try to do everything with multiple processes, afaik. It should be possible to add good support, but I guess it isn't really worth it?)
As long as multi-processes can't share variables, nevermind complex data structures made of variables, they don't apply to the problem multi-threading solves.
shrug The queue module takes complex data structures, provides them to processes, which when finished doing whatever they do, send them back to other queues and in turn more processes.
It works, complex data structures are being shared. There's no nightmarish locking issues. Not sure what else you want.
Are you entirely sure you're not discounting the solution because It's Not What Java Does?
I'm sorry if that wasn't clear, sharing doesn't only mean "making the data available" but also means high performance and direct access. Quite simply though: If you can't imagine different use profiles that make certain multi-processing paradigms better suited than others, then you shouldn't be having this discussion and should be getting more experience outside of what you're doing right now.
I'm just pointing what's solved the problem for me, and how it can be useful for others. I'm aware there's a performance overhead.
> If you can't imagine different use profiles that make certain multi-processing paradigms better suited than others, then you shouldn't be having this discussion and should be getting more experience
Conversely, there's also a huge gain in architectural simplicity which I hope you are aware of. Though you have neither acknowledged nor disproven that yet - based on your last comment, I think this is because you are an asshole. That's not an ad hominem attack, but rather an assessment of your personality after conversing with you here.
I have tried discussing with you technically, and not acknowledging other's points, then responding with "if you can't imagine my points, I can't tell you" is not how a rational, polite adult with a technical viewpoint converses with others.
I'm not saying i can't tell you, i'm saying i don't have the patience. I could throw the book at you and the library besides, but you showed quite clearly that you lack the experience to know which problems multi-threading solves. This means that both of our time is better used if you went and got the experience. I don't want you to shut up, i want you to go and learn something.
On the other hand, yes, i am an asshole. That's why i'll suggest you try and build a minecraft clone with a multi-process/single-thread solution
PS:
> Conversely, there's also a huge gain in architectural simplicity which I hope you are aware of. Though you have neither acknowledged nor disproven that yet
I absolutely said so. I expressed quite clearly that different multi-processing solutions apply to different categories of problems, which of course means that there are problems which simple, plain multi-process solutions excel at, for example webservers.
By no means would I try and build a high bandwidth graphics pipeline that runs between processes. That's a very specific problem requiring a very specific solution. However it wouldn't be correct to abandon multiple process single thread for the (much more common, particularly on HN) situation of a web app that's running on a server with multiple logical cores in non-evented programming language.
> I expressed quite clearly that different multi-processing solutions apply to different categories of problems, which of course means that there are problems which simple, plain multi-process solutions excel at, for example webservers.
> it wouldn't be correct to abandon multiple process single thread
I never said that should be done and in fact mentioned that as a solution/problem pair, see the bit about webservers in the PS of my previous comment. :)
(A web app is just a specialized webserver.)
> When? Please quote.
I did so in a much more concise form here:
> different use profiles that make certain multi-processing paradigms better suited than others
I guess the issue is the full version of the quote:
"If you can't imagine different use profiles that make certain multi-processing paradigms better suited than others, then you shouldn't be having this discussion"
That was the first time you've proposed the topic! I didn't imagine it because you hadn't actually brought up the subject. I asked you specifically what you needed. And already you've told me not to speak to you about it.
How about: "well in games which need single copies of large in-memory assets a multi-process setup wouldn't work due to copy latency"?
Seriously. You're not very good at discussing things with people.
Perhaps you were a Perl person - who, in general, doesn't create high performance games - avoiding Python for typical Perl task because of lack of multiprocessing?
I'm just showing that you (and others) can solve the multicore issue quite easily with a couple of well known modules.
And you tell me not to talk to you because I didn't anticipate you wanted to talk about /video gaming/?
There's a stereotype of early 2000's Perl people: misanthopes who discuss LARTing, hitting users with 'cluesticks' etc. You're reenforcing it.
I was hoping to get you to be creative and come up with your own problem/solution pairs. :)
Anyhow, rather than having you both take my word for it, and at the same time try to prove how bad i am at argumenting (i really am terrible!), i'd prefer to see you actually try a minecraft clone in multiple processes, just in case i'm wrong.
Also, oh god, all that stuff you edited into the reply before that one about LARTing and whatever, you're misinterpreting so much and putting so many words into my mouth, it's not funny anymore. You should try to reread my posts with a conscious effort to not make them sound like a german drill seargant yelling at you. ;)
>>> I was hoping to get you to be creative and come up with your own problem/solution pairs.
>> You wanted me to come up with a scenario like gaming graphics pipelines in a discussion of Perl, a language primarily used for Unix scripting tasks?
> I just told you that i exactly did not want you do to that: "I was hoping to get you to be creative and come up with your own problem/solution pairs."
I run into many Scala fans amongst Java developers. It's the current shiny thing in that technology area. Good old Java (of a similar age to Perl) is usually what they're making their living doing...
Actually Perl 5 is older then Java by about a year (yes, Perl had OO support before Java even left the lab). But Perl itself is much older then Java, by several years.
Sucks to be them; I'm fortunate enough to do Scala professionally. I think "shiny" is unnecessarily dismissive; the productivity and safety advantages are real enough.
The Perl culture is very much "Wild West" meets the race to space.
It's a language for people who are comfortable enough around theory that they don't need syntax to force them to use it.
At the same time, it's highly evolutionary -- it supports the fastest, dirtiest, hackinest method of getting to the goal -- and thus has prototyping built in to production.
I often write Perl scripts twice. The first is a tape-up job to "git 'er done" and the second is a more elegant and architected approached.
This method matches the configuration of most jobs. The client doesn't (fully) know what they want. Last-minute, world-bending exceptions arise. Well-intentioned schemes gang aft agley.
With this prototyping-production, I'm able to get something up and working, and can fix it later if the client has foresight.
Theory is great. I am the first to defend theory. But if it doesn't correspond to application, there's another word for it: arbitrary.
(You may note the difference between two predominant value systems illustrated in that sentence.)
I was used to take a problem of a certain size, sit down and think for a while. Then code C for maybe 3 to 10 days.
When I did a similar problem in Perl, the time to think for a problem of that size was longer than the time to throw a solution at the wall! You could design using code, then refactor/rewrite if it got too bad.
I love Perl, it's the only language (afaik) that let you do the same thing in a hundred different ways, and this provides infinite fun when you program since you can discover or think something new every single time. And that's why we have perl poetry, perl golf, and fantastic obfuscated codes. Happy 26!
no less can I say;
require strict, close attention
while you ... write haiku
I used to be a Perl developer a very long time ago. Writing CGI based web apps was fun, and felt much 'tighter' than today's world of PHP, Ruby, JS, etc. That said though, I don't miss it. :)
Perhaps my favourite memory of the Perl scene was the announcement of Parrot - an April Fools joke that detailed a project to built a bridge between Perl and Python - that then got built. Brilliant.
I'm a relatively new programmer. Been programming for around 4 years. I tried Perl, but felt like the world had moved on, so I never really committed to it.
With PHP, Python, Ruby and Javascript... space seems tight for another scripting language. Languages like Lua have something special. What's special about Perl?
Edit: I don't want to be hateful. The more the merrier obviously.
The original killer feature of Perl was regexs - these existed before, but Perl's implementation destroyed all others, and 'PCRE' (Perl compatible regular expressions) became the default - most modern languages use PCREs for their regexs.
There was some bad stuff that happened with this too - people used regexs for ghetto, half-assed versions of tree structures like HTML and XML - but for the task of chewing through Unix config files, up until around 2005 Perl was unbeatable because of the awesome regex support (and because it's history meant, at the time, perl was installed on all Unix boxes).
I first looked at perl last week and also shared your sentiment. At first when I saw perl I was aghast. The "ugly" $%@ syntax seemed pointless and unreadable. Then I decided to take a look at a non-beginner book, Intermediate Perl http://it-ebooks.info/book/879/. I was surprised and excited 50 pages in because I realized that Perl had a wealth of tricks , and that that "ugly" $%@ syntax actually had some cool repercussions. The other thing I noticed was that Perl's flexibility led to the ability to write code that was closer to how I would structure the command grammatically, for instance, "print x if x>5." I'm looking forward to learning perl further.
Let me point out http://perl-tutorial.org because most books you'll find by simply googling are terribly outdated and teach, plainly put, how to write shitty perl. Modern Perl and Ovid's Beginning Perl (not the older Beginning Perl) are excellent books to learn from.
Also a note about the sigil: Get a decent syntax highlighting set up for your editor and you'll quickly realize how nice it is to have functions, variables and different variable types colored differently.
Unfortunately -- and this is one of the many "banana peels" in Perl 5 -- even a simple statement like
print x if x > 5
is problematic in p5 for a whole bunch of reasons:
(1) At a bare minimum, what you really need to say is:
print "$x\n" if $x > 5;
That extra "\n" is a definite turn-off to a lot of people when the get their very first look at Perl. Really, the default these days should be more "say"-like. Of course, "say" is there as of 5.10 if you know where to look for it, and you go out of your way to enable it:
use feature 'say';
say $x if $x > 5;
(2) In "modern", better practice, production-quality Perl you pretty much have to either hedge every comparison op with a check for defined-ness:
use feature 'say';
say $x if defined $x && $x > 5;
in order to head off an unsightly warning about $x not being initialized:
Use of uninitialized value $x in numeric gt (>) at print-if.pl line 5.
or add even more boilerplate to suppress the warning:
use feature 'say';
{
no warnings 'uninitialized';
print $x if $x > 5;
}
or be very attentive about how $x can mutate once it's gotten passed whatever validations you're imposing on it before it enters your scope -- via e.g. Params::Validate, Method::Signatures, provided you know these tools exist and are up to speed and hip as to how to use them effectively.
(Yes, I know that in some contexts, the warning on 'uninitialized' can be very useful. But my point is, most of the time, and especially for novices, it's more of a misfeature).
(3) We shouldn't gloss over the fact that the magical pseudo-grammatical construction the "infix" if syntax provides is itself problematic in many ways.
In the current example, it simply isn't clear -- until you've become very comfortable with the language! -- if the original statement
say $x if $x > 5;
is or is not equivalent to the very similar construction
$foo = $x if $x > 5;
say $foo
This is because it is by no means obvious as to which of the more "active" parts of the original expression -- either the "verb" (print) or the conditional (if) -- takes precedence.
And unfortunately, it's not only possible, but terribly easy to "whip up" fare more volatile constructions like this in Perl 5. Various on this theme -- gotchas about print, conditionals, and complex "if/unless" constructions -- were of course given ample treatment in Perl Better Practices, to the point where (I believe) that Damian pretty much eschews "trailing" if/unless constructions altogether.
(4) Lastly, it's sad to say that for all the complains of Python having too many safety belts and what not, it completely nails the hidden complexity management issues embedded in such a simple construct like Perl's "print-if" idiom.
In Python, basically the only sensible way to achieve the original desired result is to do this:
if x > 5:
print x
Perfectly clear, completely unambiguous, and basically impossible to screw up.
This is because it is by no means obvious as to which of the more "active" parts of the original expression
Isn't it? If someone told you, really you to do just that, would you actually have a problem carrying out that command given a way to print something, a container, and a value to check against the container contents?
Ya know, it'd be nicer if Perl 5 just had more sensible semantics to this whole "undef" business. For one thing, it's inherently confusing to conflate the semantics of "none of the above" with "not yet scoped". These are two entirely different states of being, yet this is exactly what Perl 5 does.
Really, something like None (as in Python), or Nil as in Perl 6 works a whole lot better. And whatever your magical "none of the above" symbol is called, it really should be == to anything else besides itself. Don't know about you, but
$x = undef;
print "boo!\n" if $x == 0;
# boo!
smells way too much like PHP for my tastes.
Granted, Perl 5 was truly revolutionary in its time, and provided way better semantics for this particular corner case than any of its contemporaries. But it's 2013 and sadly, we know a whole lot better now.
The problem here is that's just one way (in linguistics: "voice") in which the statement can be parsed. Another way is to look at it mathematically:
print <expr>
where
expr := x if x > 5
which of course has an entirely different meaning.
What compounds the difficulty is that in general it's really difficult to anticipate all of these syntactical corner cases through a careful, a priori study of the man pages, or any of the available introductory literature. The only time-effective way (for most people) to get up to speed in a new language is through practice. Supplemented of course through book & occasional man page study. But really the way most people learn is programming is "by doing."
Which, sadly for Perl 5, means "by shooting yourself in the foot", in the prolonged early learning phase, for most people.
Statement Modifiers
Any simple statement may optionally be followed by a SINGLE modifier, just before the terminating semicolon (or block ending). The possible modifiers are:
if EXPR
unless EXPR
while EXPR
until EXPR
when EXPR
for LIST
foreach LIST
There are rules for how loosely and tightly different operators bind. Read the docs, and your questions will be answered. Ignoring the documentation does not make for a good argument.
The point is that in any well designed product you shouldn't have to study the docs (all that much) in order to start being productive. And there should be as few "gotchas" as humanely possible please. Did I say pretty please?
This has been observed with countless other technologies -- JavaScript, MySQL, MongoDB, etc. Long-time Perl hackers tend to forget their first experiences with the languages (which for many with languages with far worse track records on the consistency / simplicity scale). But newer users have (rightfully) come to expect much better.
And interestingly: the very use case that started this whole thread
statement IF
isn't in your excerpt, above. Which means that new users are most likely to encounter it "experimentally", i.e. while debugging someone else's convoluted while/unless/last/goto loop.
Of course, it's not that hard to "figure out." Implicitly, it refers to the issue of precedence, which is presumably detailed, uh, somewhere else. Which means a new user to the language has to either spend more pillow time reading, or more hair-pulling time watching their programs blow up unexpectantly before they "get the hang of it."
Which has a lot to do with why newer programmers just aren't turning to Perl as much, these days.
I urge you to read the first full sentence under the heading in the documentation I posted.
The point is that in any well designed product you shouldn't have to study the docs (all that much) in order to start being productive
And I don't think you need to in order to assume the correct functioning of
print $x if $x;
As much as you may find it compelling to point towards it's possible interpretation as
print( $x if $x );
I find that interpretation nonsensical, and anyone making any effort to learn how the language works or if not that, at least think about what it could mean and what it probably means will not be surprised. Perl tries to Do The Right Thing (DTRT) whenever possible, and with this principle in play, I think the meaning of this statement is very obvious.
Even if we extend the statement to be somewhat more ambiguous, a bit of thinking about the problem makes it obvious what the right thing to do is, and it is indeed what Perl does:
print $x, $y if $x;
# OR
print $x, $y if $y
You can either interpret that as Perl does, or as:
print( ($x), ($y if $x) );
# OR
print( ($x), ($y if $y) );
Do you ever really want something like that? Is that useful to you, given that there are a few other ways of achieving that which are much less cumbersome ($y||$y)?
The point is that in any well designed product you shouldn't have to study the docs (all that much) in order to start being productive. And there should be as few "gotchas" as humanely possible please. Did I say pretty please?
It's almost comical that you are making this argument. One of Perl's strong points is that it's really easy for someone to pick up and start using, because it tries to DTRT, making it very easy for the beginner.
Long-time Perl hackers tend to forget their first experiences with the languages (which for many with languages with far worse track records on the consistency / simplicity scale). But newer users have (rightfully) come to expect much better.
When I mention Perl, I still hear people immediately jump out with "Oh, I remember I used Perl back in the day and it was real easy to whip up a little program to do what I wanted."
I think what you are running into is that you have experience and expectations with other languages, and when Perl doesn't match those expectations, you blame Perl, rather than meeting it at it's own level. I suspect you don't do this as much with languages that appear radically different, such as Haskell and Lisp. If so, is that Perl's fault for following a different path, or yours for failing to use it appropriately?
Personally i find all of these forms weird. In a one-liner you wouldn't care, and in a full program the inputs would be validated earlier and separately with useful error messages.
for my $item ( @items ) {
# Weed out the things we don't want to process
next unless $item;
next unless $item->{foo} < 3;
next if $item->{bar} < 2 and $item->{baz} =~ /quux/i;
# Yep, these are good for processing
$item->{othername} //= "$item->{foo} - $item->{baz}";
process( $item );
}
Could that be done using maps and greps, and even be faster? Sure. Would it be harder to reason about and add documentation to? Probably.
Additionally, I use them for parameter verification in subs:
sub foo {
my ($cowbell,%attrs) = @_;
die "Needs moar cowbell!" unless $cowbell;
die "Invalid color!" unless $attrs{color}//'' =~ /\A(bronze|silver)\Z/i;
# blah
}
P.S. That's not to say I don't love a good map and grep combo, I do. After a certain point of craziness I convert to a loop and document a bit. I tried to add enough items to the loop that it would be a cumbersome map and grep.
Not knowing where uninitialized things can occur and prefer to put check for defined in every "if" is not the attitude to programming I'd support. Most of the parts of the code should operate on expected content. Undefinedness is very convenient but it is typically handled on the points where it matters, e.g. when you can not find the element in the hash, for example.
Rookie mistake missing those $. I think that python is different. One of the advantages of Perl for me is that it's more forgiving.This can suck sometimes especially if your trying to keep your code error proof. I've programmed for 3 years now. Its heavily impacted my thoughts. Often when giving directions I'll find myself self slipping into python pseudocode, "if you see the store turn right" or "while your on this road look for_." These are of course minor phrasing changes but not what I would have said before I knew python. Perl is refreshing because it seems to conform to how I think, not force me to think like it.
Slight correction: the "missing" $ were from the original post, and as I understood from the context at the time, were meant as pseudo-code.
Now, as to the fact that sigils basically don't bring all that much to Perl, are weird and distracting to newcomers and at the end of the day create as many problems as they solve... let's not go there, for now.
What platform are you on? I can't remember the last time I tried to install a module on a modern Linux distribution and had problems with it. Docs might be weaker than I'd like in some cases, mostly because of not enough examples (the curse of most documentation, IMHO).
I don't develop on Windows or Mac, since I work on server-side software, so I might just be blissfully ignorant of a serious problem.
Linux. I think the most recent example (by which I mean about two years ago; I don't use Perl much) was trying to get the XML Signature modules to build. I gave up in the end.
The documentation for those was poor. I remember the documentation for Moose being poor, as well as the documentation for Catalyst being especially bad.
My experience is that the Perl community documents better than any other scripting language community. Most everything is perldoc (which gets installed as man pages when install a cpan package) with clear examples right up front where you can see them.
And that's not even talking about the built-in documentation. Even in 1994-5 when I first learned Perl, I learned it completely from the Perl man pages and not from a book. The man pages are comprehensive, easy to read, and organized well for reference.
Ruby, Python, PHP and Node really need to get their act together and follow Perl's lead in this area.
Its true. Perl feels like a very powerful base language, moving to Python felt like you were taking a bit away (I know in reality you can probably achieve much the same things). Python on the other hand doesn't require you to implement your own basic functions (max, min , trim / strip ) as they are included already. Python stops me from shooting myself in the foot as often, by not allowing me to do stuff that is too clever too early.
I do miss being able to reference / deference variables explicitly though. Other great things are, CPAN, regular expression support (that never feels as nice in Python), one liners for doing stuff quickly on the command line. I even quite like the sigils, as an easy way to recognize the types of variable you are dealing with (though it is confusing at first). Working with strings feels a lot more natural in Perl than Python.
I'm not trying to dump on perl. I love C and C++ and those get dumped on all the time and I hate it. But anything I could do in Perl I instead do in Ruby. It's not as fast, but if fast matters I'm not supposed to use a scripting language.
But anything I could do in Perl I instead do in Ruby. It's not as fast, but if fast matters I'm not supposed to use a scripting language.
Perl can actually be very fast; it depends on what you're doing and how you write it. A lot of developers don't realize that Perl isn't really a scripting language; it's a compiled language that has a compiler that's so fast it can be run every time you run the program. The compiler produces bytecode, and the bytecode runs on a virtual machine, just like Java and C#.
The key to writing fast Perl code is to use programming constructs that compile down to single bytecode operations, because those operations are implemented in the VM using well-tuned C code. For example, using grep and map with array variables is much faster than using a for loop and explicitly indexing through the array. With the former, the enumeration is handled in C code, while in the latter it's handled in Perl code.
Note: that's probably not 100% accurate, but it's the general idea. You can actually have perl output the bytecode it generates so you can take a look at it, and figure out places where changing how your code is structured will produce more efficient bytecode.
Perl has a minimal std library, to teach people to use CPAN I guess. But even Perl has util modules for trivial help functions in the std install (at least those which aren't one line of code to define).
The strongest argument for Perl today is CPAN and CPAN Testers, still the gold standard.
But all the scripting languages are really similar, there is no reason to learn another if you already know one.
Edit: You might want to check out the Modern Perl book, free online. Perl evolves quite fast.
Django was the reason I switched. I gave Catalyst a go, but the ability to swap out almost every component left me wondering what the framework actually was. The documentation was significantly easier (for a newbie to web frameworks) to get something going. And the Django admin gave me a large chunk of what I wanted for very little effort.
Yeah, Django has a really well planned ramp up for a newbie. Especially compared to Catalyst among the Perl frameworks. The ORM was a bit of pain (had to do jump through hoops just to get multiple column indexes, iirc?). But in the end, after a few months of work it doesn't make so much difference in total time.
Perl was my #1 language 1996-2004 and my answer for the period would be.. CPAN. It's easy to find great libraries for almost any language with traction nowadays, but back in, say, 2000, library availability and packaging was piss poor in languages like Python or Ruby. CPAN was full of great stuff, all reasonably well documented, and, the kicker, a lot of it had tests too.
Old Unix sys admins made Perl special. Before Perl, they had to chain a bunch of sed, awk, grep, etc commands together or try to solve their problem in C. Both approaches were doable, but neither were ideal for the task. Perl was perfect for Unix scripting and sys admin tasks. From there, the rest is history.
One of Perl's strengths, actually, was (is?) how well it was supported on many different types of systems. Today's world is largely Linux/Windows/Mac, but that was far less true in the 90s.
I started using Perl on VMS, where there was no sed, (g)awk was new, no grep ("search" did not handle regular expressions, "find" did but arrived very late); and the command language, while sane, was very slow. Perl's system integration on VMS was excellent.
When I started working at AOL in 2002, I was given a list of commands and jobs to run manually on a Stratus VOS mainframe: http://en.wikipedia.org/wiki/Stratus_VOS It was tedious and lame (not necessarily Stratus' fault). But then I discovered that someone had ported Perl to VOS! And I was able to script my daily routine away.
With PHP, Python, Ruby and Javascript... space seems tight for another scripting language.
That's an ironic statement, since Perl came first and was absolutely dominant in the domains which PHP, Python, Ruby, and Javascript now occupy. When they were young, it would have been reasonable to say that space seems tight for another scripting language because we had Perl.
Languages like Lua have something special. What's special about Perl?
What's special about Lua? That's a four-word question that could require a huge response. Lua's a nice little embeddable scripting language, but that's a niche that Perl has occupied too. It's got fantastic support for both being embedded (callable from other languages) and embedding (able to call other languages). You might say that Lua's better because it's smaller and cleaner and simpler, but that's only true until you run into Lua not being powerful enough for something you want to do. If you used Perl as your embedded scripting language instead, you probably wouldn't have that problem. (Other problems, maybe, but not a lack of power.)
- Why not just write ',' instead of '=>'? Is there an actual reason for this other syntax to exist and to be used?
- Why does the array have to be explicitly dereferenced? Isn't it obvious from context?
- Why count on the mapping from boolean to int being false = 0, true = 1? Pretty much everything other language that has such a mapping does false = 0, true != 0.
In one line, a vivid reminder of why I find perl so awful.
This is obviously written to be clever/cute, not readable. If you just wanted the max of something, you could just write: $x > $y ? $x : $y; (This is the ternary operator borrowed from C, which still is a little confusing.) You could also just use an if / else statement, or write your own min/max functions. Or you can use min() and max() functions imported from List::Util module which can return the min/max from an entire list: http://timmurphy.org/2012/02/01/min-and-max-functions-in-per...
Why count on the mapping from boolean to int being false = 0, true = 1? Pretty much everything other language that has such a mapping does false = 0, true != 0.
I can't wrap my mind around this complaint. "Why should you count on Perl treating booleans the way Perl treats booleans? Other languages don't treat booleans the way Perl treats booleans, so obviously you shouldn't rely on Perl treating booleans the way Perl treats booleans."
It's almost as if there were some democratic notion of boolean semantics where every language you know gets one vote.
Why not just write ',' instead of '=>'? Is there an actual reason for this other syntax to exist and to be used?
It's a trick so it's easier to remember because while both sections look similar, the operators between them are actually doing different things.
i.e. => is a fatarrow (comma), while <= is less-than-or-equal. Replacing> with , results in
[ $x , $y ]->[ $x <= $y ];
Which is, arguably, less easy to remember.
Why does the array have to be explicitly dereferenced? Isn't it obvious from context?
Probably because the first set or brackets is an array reference creation and the second is an array reference subscript? There may be rules that need to be followed for the language to be parseable?
Why count on the mapping from boolean to int being false = 0, true = 1? Pretty much everything other language that has such a mapping does false = 0, true != 0.
Perl's comparison operators return numerical outputs for true/false, as that's how Perl handles true/false. What value would you expect for true, if there isn't a dedicated type?
In one line, a vivid reminder of why I find perl so awful
Eh, not my preferred syntax either. I do find that it's possible cool though.
It’s a highly cryptic way to find the maximum of the two. The first part creates an array (=> is just a syntactic sugar for a comma here) and the second part takes the 0th or 1st item from this array, <= being just regular numeric comparison.
I recently turned into a Perl user. Though I must say, documentation about Perl with CGI, and pre-made scripts are a let down. I browsed many O-Reilly books on Perl, CGI is one of the least explanative topics. Some modules have very obscure explanation on CPAN, I don't mean any offense.
If not for Perl Monks, my enthusiasm might have been lost midway.
As a Perl to Python convert, I miss Perl Monks.
Google for anything Python / Django related, and you end up on Stack Overflow. But the attitude of many of the moderators is over the top, and they are definitely loosing something by not encouraging discussions like they do on Perl Monks. You will get your code to work, but you will be far less likely to come out with greater insight or understanding.
(classic) CGI requires a full application start-up every time a request comes in, and so is very slow. If you have to use CGI, use FCGI (fast cgi) to solve that problem.
However, in recent years PSGI has started to become the standand in the community. As far as I know, it is modeled after Python's WSGI. All of the "major" perl web frameworks support it, the three big ones I can think of are Mojolicious[1], Dancer[2], and Catalyst[3].
Dancer2 is also great for creating a web service, of sorts. Need something to send out JSON chunks with a URL front-end? Very simple to set up and get going. I've been translating some code I wrote for web pages into little engines for Dancer2 to run for other groups inside the company to extract information out for their own applications. It's perfect for that.
My favorite perl story: Had been working on parsing through huge flat text files with it, had over 40 lines going and just could not get it to work correctly. I took a step back, rethought what I was trying to do, and wrote a one liner awk that just worked.
Side note: I have noticed that in bioinformatics, perl is largely being replaced with python in tool usage.
> I have noticed that in bioinformatics, perl is largely being replaced with python in tool usage.
Which has honestly little to do with the language and more with the fact that the bioinformatics-related Perl books are the worst programming teaching books i have ever seen. (Honestly, a lot of the flak on perl goes back to old and outdated books.)
I would also venture that much of the transitions are feedback loops. So person A makes a new shiny in python for no reasons relating to superiority of language for job x, but because person A is good with it. Well, if what he makes is good, people start using it. Then it breaks, and they have to fix it, or maybe get an idea to fork it. Suddenly, person A's software just encouraged 20 people to hop into python for no real concrete reason. On the bio side, bio-python is just much more intuitive imho, vs bio-perl.
Maybe that explains why some (all actually) of the really bad code have seen has been from Bioinfomaticians. I have seen terrible code in both Perl and Python though.
I haven't been a regular perl programmer for coming up on 10 years now (switched to python), but I still miss the easy regexes, and I'll pull it out when I have to do awk/sed like things.
I also think that things like Modern Perl[1] are helping to move the community away from the "line-noise" style of Perl that it was (in)famous for back in the day.
My main job currently involves maintaining and developing a huge code base in Perl including three websites (soon to expand to much more). Perl just works. I thoroughly enjoy coding in it. I've not spent too much time optimizing and testing code though. mod_perl is pretty fast in itself (using Apache).
That being said Perl certainly lacks the in-built features which would make meta programming a quick and easy job. Yes, I still have to start using Moose. Perhaps in 2014!
Happy 26th Birthday Perl! Without you, I wouldn't have a job!