Live data from Hacker News

Perl is 26 Today

modernperlbooks.com

41–50 of 194 posts

Re: Perl is 26 Today

#41

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.

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.

Re: Perl is 26 Today

#42

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.

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.

Re: Perl is 26 Today

#43
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.

Ahh...memories.

[1] http://www.activestate.com/activeperl

Re: Perl is 26 Today

#44

Still the best all-purpose language. Trend languages like Ruby and Haskell are flashes in the pan.

Not sure I want to do BlackScholes and MC or solving SAT problems or data structures in perl..

But text processing , hell yeah. perl -pei ftw!

The legacy is perl REs

Re: Perl is 26 Today

#45
post #9
post #2

I am a Perl user and I do like it very much (warts and all). This article reminded me of another self-deprecatory Perl article: http://ebb.org/bkuhn/blog/2012/12/18/perl-cobol.html And yes, as the article says, Here's to 26 more! :-)

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 res…

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.)

Re: Perl is 26 Today

#46
Perl is the ultimate hacker's language.

It was for the 90s and 00s what Microsoft BASIC was to the 1980s.

However, I think it's also coming back. Most of the "inefficiencies" it got tagged with were relics of the server model at the time, like CGI.

Now many are seeing that mastery of a general-purpose language is better than knowledge of specialized methods in a specialized language.

The first is flexible; the latter is not.

Re: Perl is 26 Today

#47
So apparently Perl shares a birthday with Alfred Bester.

I'm a bit disappointed that while this submission - history and nostalgia - hung on to the front page, the link to MJD's far meatier post about building a big software system in Perl fell off fast - perhaps it was the sexy title he chose: (Moonpig: a billing system that doesn't suck)[http://blog.plover.com/2013/12/17/]

Re: Perl is 26 Today

#48
post #42

Earlier quoted context omitted.

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 integ…

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.

Re: Perl is 26 Today

#49
post #26
post #23

Earlier quoted context omitted.

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.…

You really prefer Python threading to anything?! 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 Pe…

> 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.

Re: Perl is 26 Today

#50

Earlier quoted context omitted.

(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]…

I will look into these, thanks! I knew about FCGI, but didn't knew about PSGI. Much appreciated.

I probably should have included this link too: the PSGI spec itself (https://metacpan.org/pod/release/MIYAGAWA/PSGI-1.102/PSGI.po...)
Post reply on HN