Larry Wall on why he wrote Perl(linuxjournal.com)
linuxjournal.com
Larry Wall on why he wrote Perl
http://www.linuxjournal.com/article/2070
68 comments
I'm designing a mini-configuration-language as I go along while writing a large application.
I am amazed how powerful and useful to my purpose I can make this language. Yet I would be the first to admit this the language has some fundamental flaws that would prevent it from becoming more general purpose.
So I feel like I can appreciate from the outside the effectiveness of languages which are designed to incrementally scratch itches. You can come up with a program with a fiercely loyal user base because if you've managed to roll the proper set of things that "just work". I imagine that this is the secret of both Perl and Matlab.
The only thing is I personally hate both these programs, somewhat irrationally I'll admit.
But I think it show the weakness of "grow like a weed to touch the necessary bases" school of language design. It ultimately fails for those outside the immediate target audience because they have assimilate the entire accretion process to really get the language. For a lot of situations, that feels an impudent, almost obscene demand for someone who likely comes to the language wanting to do something simple.
So I feel like that explains the rise and fall Perl. It rose with the Unix community and the web grew together and fell as more and more people felt need for a coherent general purpose language not tied to all things Unixy.
I am amazed how powerful and useful to my purpose I can make this language. Yet I would be the first to admit this the language has some fundamental flaws that would prevent it from becoming more general purpose.
So I feel like I can appreciate from the outside the effectiveness of languages which are designed to incrementally scratch itches. You can come up with a program with a fiercely loyal user base because if you've managed to roll the proper set of things that "just work". I imagine that this is the secret of both Perl and Matlab.
The only thing is I personally hate both these programs, somewhat irrationally I'll admit.
But I think it show the weakness of "grow like a weed to touch the necessary bases" school of language design. It ultimately fails for those outside the immediate target audience because they have assimilate the entire accretion process to really get the language. For a lot of situations, that feels an impudent, almost obscene demand for someone who likely comes to the language wanting to do something simple.
So I feel like that explains the rise and fall Perl. It rose with the Unix community and the web grew together and fell as more and more people felt need for a coherent general purpose language not tied to all things Unixy.
> I'm designing a mini-configuration-language as I go along while writing a large application.
Why not just use Lua or Javascript?
Why not just use Lua or Javascript?
Essentially I want a system where the configuration files are generally transparently editable by non-programmers. Most of the information is simple configuration information.
Lua, Javascript, VBA and other such languages might be called "configuration languages" but they're really object-automation languages. They allow a user to write standard-imperative-programming macros which address the underlying objects of a given system. They don't provide simple, clean facilities for just assigning default values to objects.
And what I have my configuration doing aside from assign default value is more-or-less filtering into and put, specifying tree-transformation commands for various inputs and output using one big, recursive loop and a bit of if-else logic. Basically, I'm producing a system which can take multiple web API sources and have them look like a single source. I began using XSLT but when I started having to also transform json, having my own transform system looked just as easy as transforming json to XSLT and then further adapting XSLT for my purposes.
I could use json or XML for my underlying data storage format but it is too verbose for easy human readability so instead I use simple ini format with just a bit of syntax added and it works quite well.
Lua, Javascript, VBA and other such languages might be called "configuration languages" but they're really object-automation languages. They allow a user to write standard-imperative-programming macros which address the underlying objects of a given system. They don't provide simple, clean facilities for just assigning default values to objects.
And what I have my configuration doing aside from assign default value is more-or-less filtering into and put, specifying tree-transformation commands for various inputs and output using one big, recursive loop and a bit of if-else logic. Basically, I'm producing a system which can take multiple web API sources and have them look like a single source. I began using XSLT but when I started having to also transform json, having my own transform system looked just as easy as transforming json to XSLT and then further adapting XSLT for my purposes.
I could use json or XML for my underlying data storage format but it is too verbose for easy human readability so instead I use simple ini format with just a bit of syntax added and it works quite well.
I remember unpacking PERL from usenet and compiling it on my Xenix box!
Really back then it was amazing. At the time I was writing everything in C and having the flexibility without the pain of C that PERL provided was such a great gift. I wrote literally 100,000's of lines of PERL (one project alone was 25k LOC) and enjoyed it all the way up until maybe 1993!
CPAN is hard to beat, having modules that work, etc. But I won't defend PERL because the reality is I almost never use it anymore. Not because there is something wrong with it, just because more often I run into problem sets that either require me to return to C (Think 45,000 QPS under 4 ms response time) and/or web stuff my dev team is more comfortable with on PhP.
PERL transformed my life and my thinking. It taught me that "Just because you CAN do something a particular way doesn't mean that you SHOULD do it that way.".. I took this much further then PERL and learned to apply it to all my projects and started writing in the "right language for the problem set". Instead of trying to fit every problem to the handful of languages I could program at that time.
Now I write in so many languages and utilize so many platforms and systems that the concept is just part of who I am when I am presented with a new problem to solve. For that I owe Larry a lifetime of beers whenever he wants one I'll be there to buy it for him! :-)
Really back then it was amazing. At the time I was writing everything in C and having the flexibility without the pain of C that PERL provided was such a great gift. I wrote literally 100,000's of lines of PERL (one project alone was 25k LOC) and enjoyed it all the way up until maybe 1993!
CPAN is hard to beat, having modules that work, etc. But I won't defend PERL because the reality is I almost never use it anymore. Not because there is something wrong with it, just because more often I run into problem sets that either require me to return to C (Think 45,000 QPS under 4 ms response time) and/or web stuff my dev team is more comfortable with on PhP.
PERL transformed my life and my thinking. It taught me that "Just because you CAN do something a particular way doesn't mean that you SHOULD do it that way.".. I took this much further then PERL and learned to apply it to all my projects and started writing in the "right language for the problem set". Instead of trying to fit every problem to the handful of languages I could program at that time.
Now I write in so many languages and utilize so many platforms and systems that the concept is just part of who I am when I am presented with a new problem to solve. For that I owe Larry a lifetime of beers whenever he wants one I'll be there to buy it for him! :-)
The language is named Perl, not PERL. See http://perldoc.perl.org/perlfaq1.html#Whats-the-difference-b... for proof.
Thank you. I didn't want to be the person to say it.
PERL and MAC (vs. Mac) are equal parts annoying, but at least PERL doesn't mean something different.
Please don't start me on what it's named..
If I remember correctly when he posted it to usenet it was:
From the Original comp.sources.unix SHAR file:
If I remember correctly when he posted it to usenet it was:
P = Practical
E = Extraction
and
R = Reporting
L = Language
From the Original comp.sources.unix SHAR file:
X.TH PERL 1 LOCAL
X.SH NAME
Xperl - Practical Extraction and Report Language
X.SH SYNOPSIS
X.B perl [options] filename args
I have discussed this very topic with Larry Wall. His criteria for a name were: short, unique, and whimsical.
He wanted it to be short because he was going to type it a lot. He wanted it unique so that he could use grep to locate all Usenet discussion on it in all newsgroups. (Yes, he was pulling the Kibo trick.) And what sold him on whimsical was the presence of the 2 different possible acronyms: Practical Extraction and Reporting Language, Perfectly Eclectic Rubbish Lister. He therefore included both in the documentation from day 1.
Larry himself is not particularly dogmatic on the capitalization. But as you can see in the link you posted to his original Usenet post he did not think of it as an acronym. He was at that point capitalizing it Perl or perl depending on where it appeared in the sentence.
However long ago the capitalization of the language became a litmus test for whether you had exposure to the community. See http://www.perlmonks.org/?node_id=510594 for evidence of that.
He wanted it to be short because he was going to type it a lot. He wanted it unique so that he could use grep to locate all Usenet discussion on it in all newsgroups. (Yes, he was pulling the Kibo trick.) And what sold him on whimsical was the presence of the 2 different possible acronyms: Practical Extraction and Reporting Language, Perfectly Eclectic Rubbish Lister. He therefore included both in the documentation from day 1.
Larry himself is not particularly dogmatic on the capitalization. But as you can see in the link you posted to his original Usenet post he did not think of it as an acronym. He was at that point capitalizing it Perl or perl depending on where it appeared in the sentence.
However long ago the capitalization of the language became a litmus test for whether you had exposure to the community. See http://www.perlmonks.org/?node_id=510594 for evidence of that.
$ perldoc perl | tail -n 14
Perl actually stands for Pathologically Eclectic Rubbish Lister, but
don't tell anyone I said that.
NOTES
The Perl motto is "There's more than one way to do it." Divining how
many more is left as an exercise to the reader.
The three principal virtues of a programmer are Laziness, Impatience,
and Hubris. See the Camel Book for why.
perl v5.14.2 2012-07-12 PERL(1)It's a backronym. In the beginning it didn't stand for anything. Backronyms were tacked on later. Perl for the language and perl for the interpreter.
Not completely true!
In conversation with Larry Wall I found out that the existence of two reasonable backronyms was part of why he chose to call it Perl. Therefore the backronyms were known before the name itself was finalized.
In conversation with Larry Wall I found out that the existence of two reasonable backronyms was part of why he chose to call it Perl. Therefore the backronyms were known before the name itself was finalized.
Really? I have never heard that before. I have heard that it was going to be "Pearl" but there was something else out there with that name and so it ended up "Perl".
Interesting...
Interesting...
My source is conversation with Larry Wall at lunch at OSCON in, I believe, 2006.
And yes, I've heard the Pearl claim before. As well as the claim that the original acronym was going to be Practical Extraction And Reporting Language.
All of the claims that I have heard fit together if you assume that the actual sequence of events was this. Larry wanted to name it pearl for whatever combination of reasons. Came up with a nice acronym for it. Decided not to name it pearl for whatever combinations of reasons. Was playing around and came up with the Perfectly Eclectic Rubbish Lister. Preferred that over pearl for various reasons (not in use, greppable, likes puns, etc). And therefore named the language perl. Therefore the language name is not an acronym, but both popular backronyms predate the actual language name.
I was not present. But this is my best guess as to what did happen.
And yes, I've heard the Pearl claim before. As well as the claim that the original acronym was going to be Practical Extraction And Reporting Language.
All of the claims that I have heard fit together if you assume that the actual sequence of events was this. Larry wanted to name it pearl for whatever combination of reasons. Came up with a nice acronym for it. Decided not to name it pearl for whatever combinations of reasons. Was playing around and came up with the Perfectly Eclectic Rubbish Lister. Preferred that over pearl for various reasons (not in use, greppable, likes puns, etc). And therefore named the language perl. Therefore the language name is not an acronym, but both popular backronyms predate the actual language name.
I was not present. But this is my best guess as to what did happen.
And I remember that day because it took me a couple days to get it to compile on Xenix and my wife was pissed because all I did during the winter break was play with Perl programming. :-)
My left brain wants to call Larry Wall to task for using a simplistic pop-psych brain-lateralization analogy when the truth of the brain is vastly more complicated but my right brain is like "Eh, he's from the Pacific Northwest, up there they believe in whatever makes them happy."
+1. My first reaction was similar too.
-- I am non-american so the Pacific Northwest connotation is weaker.but got the drift.
Your (silly) views on the Northwest aside, he also grew up in Los Angeles.
https://en.wikipedia.org/wiki/Larry_Wall
https://en.wikipedia.org/wiki/Larry_Wall
I stopped reading at the word "art".
And then I started reading again. Larry took it in a different direction that I presumed and it's certainly an interesting claim to make.
I'm just not really sure if I buy it... It sounds to me like dropping someone in a Home Depot surrounded by various tools and materials and saying "Go ahead build a dog house anyway you like." "Art!"
I greatly enjoy the creativity involved in programming and I can appreciate the aspects that set Perl apart from other languages at its inception. But I get a lot more satisfaction out of simplicity and elegance in my language than the ability to put a condition on either side or whether scalars, arrays, and hashes have unique identifiers in the variable name.
Maybe I got into it at the wrong time, but Perl has never felt like art to me...
And then I started reading again. Larry took it in a different direction that I presumed and it's certainly an interesting claim to make.
I'm just not really sure if I buy it... It sounds to me like dropping someone in a Home Depot surrounded by various tools and materials and saying "Go ahead build a dog house anyway you like." "Art!"
I greatly enjoy the creativity involved in programming and I can appreciate the aspects that set Perl apart from other languages at its inception. But I get a lot more satisfaction out of simplicity and elegance in my language than the ability to put a condition on either side or whether scalars, arrays, and hashes have unique identifiers in the variable name.
Maybe I got into it at the wrong time, but Perl has never felt like art to me...
A Perl script can almost morph into its own unique language, one that exists only during the runtime of that script and then flashes out of existence like a Boltzmann brain.
To me, there's no disputing that writing Perl is like making art. The problem I have is deciding whether this is even a remotely good design decision for production code.
To me, there's no disputing that writing Perl is like making art. The problem I have is deciding whether this is even a remotely good design decision for production code.
Let people call it art, if that is what keeps them developing and maintaining it.
Again, when you post an old article, put the date in parens. In this case, (1997).
Parens are optional
As always, TIMTOWTDI.
Tim owes you what?
It's funny, because for me this is it's greatest weakness. I prefer not to wonder if I'm making the wrong decision every line.
On the other hand, Perl programmers don't have to lose sleep worrying about whether what they're doing is sufficiently 'Perlesque', in notable contrast to similar languages I could mention.
It's doubtful anyone loses sleep over such things.
Which programming language do you use where one can't worry about this?
When they first built the University of California
at Irvine they just put the buildings in. They did not
put any sidewalks, they just planted grass.
The next year, they came back and put the sidewalks
where the trails were in the grass. Perl is just that
kind of language. It is not designed from first
principles. Perl is those sidewalks in the grass.
-Larry WallI don't know if it's true in this case or not, but I'm pretty sure this same story about sidewalks has been told about every university in North America.
At <http://ask.metafilter.com/62599/Where-the-sidewalk-ends>; there are reports of it at Columbia (by Eisenhower), Tufts, Long Beach State, University of South Florida, Iowa State and/or Iowa, and CMU. I certainly heard it about my alma mater (none of the above).
At <http://books.google.com/books?id=C_FFMePR204C&lpg=PA184&...; they claim this was done at Disneyland.
At <http://ask.metafilter.com/62599/Where-the-sidewalk-ends>; there are reports of it at Columbia (by Eisenhower), Tufts, Long Beach State, University of South Florida, Iowa State and/or Iowa, and CMU. I certainly heard it about my alma mater (none of the above).
At <http://books.google.com/books?id=C_FFMePR204C&lpg=PA184&...; they claim this was done at Disneyland.
That's a very strong anecdote. I've never seen that quote from Wall.
This is such a great piece of writing. Tongue in chic at every turn, but it really washes over me when he talks about the art. It makes me remember that computer science is less about computers than astronomy is about telescopes.
Written in 1997 - interesting, but don't click this thinking you'll get a recent defense of PERL.
Perl 5 is still what a large portion on what the community uses, so it's not out of date. Then again, very little of the text refers to anything technical. It's a discussion of the cultural differences between Perl and other communities.
Part of me wants to say something snarky about Perl to contradict or joke about things Larry said in this article, but Guido Van Rossum's keynote at PyCon 2012 really resonated with me. He basically said that Perl/Python/Ruby are all very similar and we should all just get along.
Fair warning for those interested in learning Perl...it will ruin you as a programmer. Before I learned Perl I was a pretty decent C++ guy, built most of the guts of an OS in Java as a fun project to learn the language, could hack out a little x86, MIPS, x68k and z80 and a couple specialty asms and knew a smattering of a half-dozen other serious languages.
Perl absolutely ruined me. Right after learning Perl for some text processing I was doing, I also made a career change into a technology adviser and analyst for a large R&D firm. 6 months into that new job I happened to have a need to process some data. They had Java and Perl on the machine as a leftover from the previous owner of the box (C++ environments were still fairly expensive back then, security wouldn't let me install Linux or Cygwin, and anything else wouldn't pass muster).
I didn't want to fool around with Java's file I/O mess, so I just picked Perl. I got shit done, a lot of shit. I got 5 awards from the firm in 3 years and a nomination for a lifetime achievement award and all I was doing was hacking up some one-off Perl scripts to crunch some data! I was much more familiar with C++ and Java, and I simply hadn't thought about how much I was accomplishing and with such little effort.
Over the next few years I quietly left behind all of the other languages and got into a serious Perl groove. Solving issues in a few days that were stumping teams of a dozen for months. I am not a particularly talented programmer. I built little web apps to scratch department itches that came up during meetings ("why isn't there an acronym database?", "I wish we had a meta-search engine that search Yahoo, Altavista and Lycos at the same time!", "I wish I could scan these documents quickly for all of the chemicals in our chemical warehouse", etc. etc.) Then I started solving harder problems. My Perl prototype code was often passed off to a team where it was rewritten in a "real" language, but since I was the one who solved the tricky problem, it was my solution that ended up being rewritten in C++ or Java.
Then came a time I needed to write something in Java based on a deliverable requirement. You know what? I couldn't do it. I don't mean technically, I mean mentally. everything seemed like a huge pain in the ass. The delta from thought to code seemed so drawn out that by the time I had put my thought down into code I had often forgotten what the hell I was coding in the first place. Simple exercises involving half a dozen lines of code and minimal thought turned into half hour long dives into the standard library docs...yes I said it, the Perl solution might be longer than the Java one, but the time to just code it out was an order of magnitude faster. I ended up in groove with Perl I simply couldn't achieve even after years of working in other languages. I finished the Java project and swore off "real" languages for good after that. I had simply been broken by Perl and ruined for good.
Perl just simply came together like how my brain worked. I could dump out ideas and it just worked...and I got shit done. With a little careful planning I could even tackle larger projects, a couple that approached a 100k lines of Perl (and had the annoying habit of running faster than the later Java rewrites, which eventually had to be rewritten in hand optimized multi-threaded C++ with in-line ASM to beat the original 5 year old Perl in performance)
It was the difference between typing text with a keyboard and handwriting all caps, backwards in a mirror, while translating each word from English to Russian via a English-French dictionary then French-Russian dictionary in the dark by candlelight.
All that being said the long Perl 5->6 winter had me reaching outside of Perl for a while into Python and it was "ok". I liked how my code was automatically readable and simple. The standard libraries are badass. But it just didn't have the there there that Perl has. The automagic flow from synapse to working code. I'm happy to see the community starting to pick back up but sadly I'm hopelessly locked in 2001 Perl and many of the idioms from that time. It would simply take too much of a time investment to get entirely up-to-speed with where Perl is today. I'd probably be better spending the time on something more marketable with better and more modern library support.
Here's the real kicker, I ended up using Perl to get really good at my non-programming (but still technical) job that it would probably take me years of dedicated effort to get back up to speed with where modern development is at all. I'm old enough now that I'd simply be much more comfortable managing modern developers than being one.
So yeah, that's how Perl might ruin you.
Perl absolutely ruined me. Right after learning Perl for some text processing I was doing, I also made a career change into a technology adviser and analyst for a large R&D firm. 6 months into that new job I happened to have a need to process some data. They had Java and Perl on the machine as a leftover from the previous owner of the box (C++ environments were still fairly expensive back then, security wouldn't let me install Linux or Cygwin, and anything else wouldn't pass muster).
I didn't want to fool around with Java's file I/O mess, so I just picked Perl. I got shit done, a lot of shit. I got 5 awards from the firm in 3 years and a nomination for a lifetime achievement award and all I was doing was hacking up some one-off Perl scripts to crunch some data! I was much more familiar with C++ and Java, and I simply hadn't thought about how much I was accomplishing and with such little effort.
Over the next few years I quietly left behind all of the other languages and got into a serious Perl groove. Solving issues in a few days that were stumping teams of a dozen for months. I am not a particularly talented programmer. I built little web apps to scratch department itches that came up during meetings ("why isn't there an acronym database?", "I wish we had a meta-search engine that search Yahoo, Altavista and Lycos at the same time!", "I wish I could scan these documents quickly for all of the chemicals in our chemical warehouse", etc. etc.) Then I started solving harder problems. My Perl prototype code was often passed off to a team where it was rewritten in a "real" language, but since I was the one who solved the tricky problem, it was my solution that ended up being rewritten in C++ or Java.
Then came a time I needed to write something in Java based on a deliverable requirement. You know what? I couldn't do it. I don't mean technically, I mean mentally. everything seemed like a huge pain in the ass. The delta from thought to code seemed so drawn out that by the time I had put my thought down into code I had often forgotten what the hell I was coding in the first place. Simple exercises involving half a dozen lines of code and minimal thought turned into half hour long dives into the standard library docs...yes I said it, the Perl solution might be longer than the Java one, but the time to just code it out was an order of magnitude faster. I ended up in groove with Perl I simply couldn't achieve even after years of working in other languages. I finished the Java project and swore off "real" languages for good after that. I had simply been broken by Perl and ruined for good.
Perl just simply came together like how my brain worked. I could dump out ideas and it just worked...and I got shit done. With a little careful planning I could even tackle larger projects, a couple that approached a 100k lines of Perl (and had the annoying habit of running faster than the later Java rewrites, which eventually had to be rewritten in hand optimized multi-threaded C++ with in-line ASM to beat the original 5 year old Perl in performance)
It was the difference between typing text with a keyboard and handwriting all caps, backwards in a mirror, while translating each word from English to Russian via a English-French dictionary then French-Russian dictionary in the dark by candlelight.
All that being said the long Perl 5->6 winter had me reaching outside of Perl for a while into Python and it was "ok". I liked how my code was automatically readable and simple. The standard libraries are badass. But it just didn't have the there there that Perl has. The automagic flow from synapse to working code. I'm happy to see the community starting to pick back up but sadly I'm hopelessly locked in 2001 Perl and many of the idioms from that time. It would simply take too much of a time investment to get entirely up-to-speed with where Perl is today. I'd probably be better spending the time on something more marketable with better and more modern library support.
Here's the real kicker, I ended up using Perl to get really good at my non-programming (but still technical) job that it would probably take me years of dedicated effort to get back up to speed with where modern development is at all. I'm old enough now that I'd simply be much more comfortable managing modern developers than being one.
So yeah, that's how Perl might ruin you.
It was the difference between typing text with a keyboard and handwriting all caps, backwards in a mirror, while translating each word from English to Russian via a English-French dictionary then French-Russian dictionary in the dark by candlelight.
There's a module for that.
There's a module for that.
Perl's source pre-processing filters are something I still miss.
Likewise, and thank you for the story. I too came to Perl from C and ML and only later encountered Java. From 2008 I was completely blocked, barely wrote any code at all because I couldn't have Fun anymore.
It was not until I recently made myself learn Ruby and Erlang that I rediscovered the joy of programming.
It was not until I recently made myself learn Ruby and Erlang that I rediscovered the joy of programming.
I've been wanting to learn Perl for the past 2 years. I still don't have time, but in 5-6 months I'll be able to finish what I'm doing and start Perl (as a hobby, not a full-time endeavor!).
Some languages have a "magic" book or article, that you'll never learn anything deeply before reading it. For me and JavaScript, it was Douglas Crockford's "JavaScript: The Good Parts". It literally opened my mind when I read it last week and my Node.js code (which is in CoffeeScript BTW) would never be the same (hopefully it'll be an order of magnitude better).
Is there a magic book on Perl? And is there any point starting with Perl 6 (considering I don't want to write mission critical programs with Perl just yet, and don't mind to be an early adopter at all if the product will see the light of the day in the next 2-3 years)?
Thanks a lot.
Some languages have a "magic" book or article, that you'll never learn anything deeply before reading it. For me and JavaScript, it was Douglas Crockford's "JavaScript: The Good Parts". It literally opened my mind when I read it last week and my Node.js code (which is in CoffeeScript BTW) would never be the same (hopefully it'll be an order of magnitude better).
Is there a magic book on Perl? And is there any point starting with Perl 6 (considering I don't want to write mission critical programs with Perl just yet, and don't mind to be an early adopter at all if the product will see the light of the day in the next 2-3 years)?
Thanks a lot.
My weird suggestion: start at the beginning of Perl's great 5.x renaissance, Perl 5.6. Any book that explains that version's features, learn all of it. You will learn probably the most comprehensibly compatible version of the language you'll ever need, and you'll strengthen your basics before learning all the new goodies introduced in later Perls.
I'm the type of person that wants to write Perl once and use it almost anywhere. Lots of useful language features in later versions simply aren't supported on systems that didn't upgrade their stock Perl version (for example, Centos 5 ships with I think Perl 5.8.x, and the current stable is 5.16.x).
And if you're thinking "Oh, i'll just upgrade perl on that five year old legacy server," kill yourself now and spare the agony.
I'm the type of person that wants to write Perl once and use it almost anywhere. Lots of useful language features in later versions simply aren't supported on systems that didn't upgrade their stock Perl version (for example, Centos 5 ships with I think Perl 5.8.x, and the current stable is 5.16.x).
And if you're thinking "Oh, i'll just upgrade perl on that five year old legacy server," kill yourself now and spare the agony.
Crockford's book was a direct inspiration for my Modern Perl:
http://onyxneon.com/books/modern_perl/index.html
http://onyxneon.com/books/modern_perl/index.html
That sounds great. Thank you!
And as you already have an ePub version, I would like to suggest selling it (or giving it away free, as you already do) in the iBookStore as well. iPad is an amazing device for reading technical books, and I spend few hours every day reading ePub books in iBooks.app (I read Crockford's book and 3 other O'Reilly books just in the past 2 months).
Right now there are many Perl books in the iBookStore, but they're mostly cookbooks (step-by-step tutorial), not a no-bullshit introduction to the language as your book is! I'm sure many many more would discover or benefit from your book if it was available there as well :)
And as you already have an ePub version, I would like to suggest selling it (or giving it away free, as you already do) in the iBookStore as well. iPad is an amazing device for reading technical books, and I spend few hours every day reading ePub books in iBooks.app (I read Crockford's book and 3 other O'Reilly books just in the past 2 months).
Right now there are many Perl books in the iBookStore, but they're mostly cookbooks (step-by-step tutorial), not a no-bullshit introduction to the language as your book is! I'm sure many many more would discover or benefit from your book if it was available there as well :)
Very nice post, which rings true. I had similar difficulties learning my second language after a couple of years just using Perl. I must've made a serious effort at over a dozen languages over a period of several months, and while I can get by in most of these, it was only when I got into Scheme/Racket recently that I felt like I'd found another language that I could really connect with.
Luckily, I'm not a full-time programmer, so I'm in the enviable position of being able to pick and choose which languages I use, but I imagine things are much more frustrating for coders who don't have a choice.
Luckily, I'm not a full-time programmer, so I'm in the enviable position of being able to pick and choose which languages I use, but I imagine things are much more frustrating for coders who don't have a choice.
Perl was my first language. After burning all sorts of fingers off using it (my workflow was edit/FTP/test in browser on a 14.4 modem), I was looking forward to the limited type checking C offered.
But, yes, it is wonderfully pragmatic. I've been a fan of loose languages ever sense, and managed to stay out of trouble even as a teenage hacker lacking taste. One exception: I ran a database off of a CSV-style file. With no locking mechanisms. Corruption ensued.
But, yes, it is wonderfully pragmatic. I've been a fan of loose languages ever sense, and managed to stay out of trouble even as a teenage hacker lacking taste. One exception: I ran a database off of a CSV-style file. With no locking mechanisms. Corruption ensued.
Thanks for sharing your experience with Perl. +1
I've never been biased towards one language or another. I always recommend using the right tool for the job. With that said, I built Crowdtilt using Perl and the main reason was because we needed to move fast. Now, that I am here I don't even want to use another language, but I will if I have to :).
I've never been biased towards one language or another. I always recommend using the right tool for the job. With that said, I built Crowdtilt using Perl and the main reason was because we needed to move fast. Now, that I am here I don't even want to use another language, but I will if I have to :).
You could say that about a lot of languages. Though I must say, it sounds like your company had some pretty awful programmers.
On the topic of dimensions of programmers.
We can further subdivide the Artists into those who enjoy getting their revenge by being more than properly miserable, and those who prefer to get their revenge by being less than properly miserable. Artists of the first sort will prefer to work in a more formal medium, one that inflicts extra pain on the Artist, such as composing sonnets, dancing ballet, or programming C++. Artists of the second sort tend to be much more fun-loving, free-wheeling and undisciplined, whether the verb in question is composing, dancing, programming, or slinging. (Especially slinging. There's nobody quite so joyful as a B.S. artist. I should know...)
There is, of course, a third category of Artist, the one who oscillates between the two extremes.
We can further subdivide the Artists into those who enjoy getting their revenge by being more than properly miserable, and those who prefer to get their revenge by being less than properly miserable. Artists of the first sort will prefer to work in a more formal medium, one that inflicts extra pain on the Artist, such as composing sonnets, dancing ballet, or programming C++. Artists of the second sort tend to be much more fun-loving, free-wheeling and undisciplined, whether the verb in question is composing, dancing, programming, or slinging. (Especially slinging. There's nobody quite so joyful as a B.S. artist. I should know...)
There is, of course, a third category of Artist, the one who oscillates between the two extremes.
To know Perl is to understand Larry Wall. If you don't get him, you won't get it.
Larry's writing always reminded me of the college guys I knew who smoked tremendous amounts of hash.
Art being an activity of free will and constraints free is a common misconception I am surprised to see shared by Larry Wall.
If you write music for piano or play piano you are moving in a highly constrained environment. The extreme example is Chinese calligraphy, probably the most constrained form of art, and at the same time the one where the artistic expression of the self is the most salient.
So no, please don't oppose art and discipline, it's a mistake.
If you write music for piano or play piano you are moving in a highly constrained environment. The extreme example is Chinese calligraphy, probably the most constrained form of art, and at the same time the one where the artistic expression of the self is the most salient.
So no, please don't oppose art and discipline, it's a mistake.
Even further, John Cage and his ideology of chance. Non-determinism only worked under heavy constraint, and it worked amazingly.
This guy's apparent jokey lunacy is what always kept me away from Perl. The camel book--my god, if I want a laugh I'll buy Al Franken's latest.
Like http://www.thepoliticalguide.com/Profiles/Senate/Minnesota/A...
Lots of chuckles there. But you don't have to buy them, they are free.
Lots of chuckles there. But you don't have to buy them, they are free.
His jokey lunacy is what I like. It takes a bit of intelligence to have a sense of humor
perl came out early enough before the flood
it was pretty much the CGI language by default
it would crop up in a project and glue everything together
at that point in the project when nobody cares anyway
it was on my iBook in 2001 when PHP and Python were not
it flew out of my keyboard rewriting a lost dot-com era PHP game
the $a and $b global variables are accumulators to paint with
Programming and its teaching has always felt like a culture of passionate people who refused students the passion of discovering and learning but rather decreed their own rules, learned from their own mistakes. It isn't a particular fault of programmers or educators - this is natural inclination of all of us to deny others the painful experience of learning from mistakes. But it's no fun. It's no fun, damnit, and I want nothing to do with things that are no fun.
I would never have developed the mastery of vim that I have now had someone told me "hey, this is what you need to do. This is how you should do it. Here's a semester long course on how to effectively edit text." Everything I learned, I learned on my own, out of necessity. I now consider myself a proficient user of vim, but that would never have happened without the thousands of sequential js pressed before I discovered text objects out of a hunch that "dang it, this is slow and silly. there has to be a better way."
I want to fall in love with something, and write the stupidest possible code, and then learn why it was stupid, and be embarrassed by its stupidity 6 months down the road.
This is why Perl appealed to me. Because it allows for messy, playful, immediate gratification, tweaking fun. Perhaps I haven't the attention span to be a proper programmer.
I'd be embarrassed to admit this to most of my friends.