
Archaic Perl - fogus
http://perliscope.blogspot.com/2009/08/archaic-perl.html
======
bendotc
This article isn't terribly interesting, really. Yes, you can write clean,
understandable code in Perl and most widely used languages. Yes, you can write
awful code in any language. The real test of messiness, ugliness, readability
and comprehensibility is in the cases in the middle. How easy is it to write
readable code? How hard is it to write bad code? And this one might be a
little controversial, but how does the culture around the language value
readable, clean code?

Put another way, when I'm actually working on a project in the language,
what's the likelihood that someone who I'm working with or who worked on the
project before me has really messed up the code base in ways I'm going to be
dealing with for years? And how hard am I going to have to work to not be that
guy?

Finally, the article uses an example of parsing LaTeX with Perl vs. Python,
and uses a regular expression. Now, I don't know if LaTeX can, in general, be
parsed with regular expressions, but writing a parser aside, it's no surprise
that Perl wins when dealing with regular expressions. That's a fine thing, and
definitely something Perl's got going for it (or possibly against it,
depending on how you feel about regular expressions), but Perl just about grew
out of being a regexp DSL -- it's not really a fair fight. Put a full Perl TeX
parser up against one written in Prolog, and I bet Prolog would win, but it
doesn't mean I'd use Prolog over Perl for most things.

~~~
berntb
>>when I'm actually working on a project in the language, what's the
likelihood that someone who I'm working with or who worked on the project
before me has really messed up the code base

Well, the quality of Perl code is very diverse, since a lot of system
administrators are mangling the language... :-)

Perl's general community seems to be very good (newbies went with PHP for
quite a while). You can arguably see the CPAN as a result of that. (It is
common to say -- "Perl is irrelevant, the killer app is CPAN!".)

Another advantage is that Perl doesn't have so many embarrassing fanboys as
certain other environments...

(I believe the hype level regarding the scripting languages comes from them
being so similar that they compete for the same niche.)

Since Moose seems to standardize a solution to the OO syntax ugliness, the
main Perl problem is IMHO the parameter passing to functions/methods. There
are advantages and disadvantages to most everything.

Edit: Small syntax/word choices. Removed ":-)" on comment that other
environments have too many fanboys, language wars are such a time waste.

------
rbranson
Perl still sucks, and I wrote Perl5 code for years. It's more about the
inconsistency in the way the language is implemented. Having to explicitly
scope variables, the disaster than is OOP, the riddling of special cases and
context-sensitivity, by-ref vs. by-val, etc etc etc. Having to memorize all of
these various cases sucks. The only upside to Perl is the CPAN. Other than
that, there's no reason to waste your time when there are fantastic languages
like Python and Ruby out there.

Steve Yegge says it best: "Within about 3 days, I was more comfortable with
Ruby than seven years had made me with Perl. I was still accidentally sticking
"my" in front of variable declarations, typing "sub" instead of "def", little
things like that. But I was already starting to think in Ruby, and suddenly I
had all this extra space in my brain. You have to learn Perl by memorizing,
but you learn Ruby by understanding."

~~~
zby
Perl is pretty big language and build of not very orthogonal parts. I've read
somewhere an interview with Larry Wall where he said he was not planning to
make the language very clean and orthogonal from the start - but instead he
wanted to watch the way people use the language and then cut off the unused
parts (the actual analogy was with building pavements along the paths that
people made in the grass instead of planning up front how they are going to
commute). I think that cut off phase never came. After some 10 years of
programming in Perl, there are still areas that I don't know really well - I
just don't use them, and when reading other peoples code I still sometimes
need to lookup something. I can see why this can be annoying. But eventually
the size of the libraries that you need to memorize when programming is still
much bigger than the language itself, so it does not matter that much.

My prediction is that other languages will not build their CPAN equivalents
soon. It looks so easy to copy, especially if you believe you have a better
language, but what people don't see is the complex network of things that
enable CPAN existence. It's not just code repository it is a complex
ecosystem.

------
camtarn
Whenever I have to use Perl, I get to a point when I want a nested data
structure. Then I remember that I have to use a completely different syntax to
do so, and my head explodes. Who thought explicit and non-automatic references
were a good idea?

Nowadays I use Ruby if I have a choice: most of the best bits of Perl, less of
the worst bits. The language actually feels like it was designed, rather than
accreted over time.

Perhaps Perl 6 will be better, but I'm guessing scripts and apps written in
Perl 5 will be around for a long, long while yet.

------
abyssknight
This was a very refreshing read. I used to write Perl at my last job, and a
little bit where I am now. The language serves a noble purpose, parsing data,
and it does that extremely well and in a very understandable manner. When
others step into the land of Perl, it can be a little daunting, but once you
work out the difference between @ # and $ it all gets a little more clear.
Thanks for this!

~~~
jrockway
I disagree. With no parser combinator library, I find it very difficult to use
Perl for anything but the most trivial parsing tasks.

It is very good for building complex applications, however.

~~~
Ionic_Walrus
what is a "parser combinator library" ?

------
Ionic_Walrus
I have been programming perl and php for many years now - I don't agree with
rbranson here. Its not that perl is _the_ best tool , if it solves your
problem use it , otherwise please stop whinging about it. If you really feel
so strongly about the issue, you are welcome to fix it.

------
tjic
Every half-baked, low-quality, ill-designed language has defenders _somewhere_
on the web.

Why is this news?

In my professional career I've used C, C++, Perl, and Ruby.

I come with no preexisting biases.

...but after having written several programs in Perl until they became
unmaintainable (despite my good coding style), and then rewritten them in Ruby
in something like 1/10th to 1/20th the lines... I've got no particular
interest in spending time reading about how Perl is wonderful.

I've been there.

I gathered my own data.

See Paul's thoughts on blub programmers and blub languages.

<http://www.paulgraham.com/avg.html>

~~~
kscaldef
> ...but after having written several programs in Perl until they became
> unmaintainable (despite my good coding style), and then rewritten them in
> Ruby in something like 1/10th to 1/20th the lines... I've got no particular
> interest in spending time reading about how Perl is wonderful.

I agree with another poster. I'd love to see the data that you gathered.

I've worked fairly extensively with both Perl and Ruby, and I have a hard time
imagining anything which is 10-20x shorter in Ruby than in Perl. I also have
to question the maintainability assertion. Ruby and Perl are similar enough
that I'm pretty sure I can take a "maintainable" program in either one and
port it to the other with minimal changes and no noticable change in
maintainability.

~~~
tjic
> Ruby and Perl are similar enough that I'm pretty sure I can take a
> "maintainable" program in either one and port it to the other with minimal
> changes

Without intending to flame, I can't imagine that you'd say this if you've used
some of the more powerful techniques in Ruby.

If you've used techniques X,Y, and Z in Perl, you can find them in Ruby. ...
but unless you think in a Lisp-like way, you won't even realize that
techniques G' and E''' exist in Ruby, but not in Perl.

~~~
kscaldef
Some content would be nice, rather than the implication that I'm just an
ignorant blub-er.

So, once again, how about some of that data you say you collected to back up
what you're saying? Which "more powerful techniques" are you talking about?

------
acg
Perl is very influenced by the Unix command line. I can remember years ago
(when other mini computer operating systems around and everyone was mad on
pascal) my college lecturers disdain for the design C and Unix.

If the same thing happens again terseness, power and flexibility win against
ridged ideas of how programs/command-lines should be written.

Perl exploded with the web, however before the web it was widely used. It
might not be the web programming language of choice but it it's still great at
manipulating information, processing large files and general administration.

------
spudlyo
I consider shell script programming archaic, yet I still see it as a job
requirement for UNIX SA jobs. Once I learned Perl I never had the urge to
write another bourne shell or ksh script ever again. I still need to read and
debug them from time to time though.

~~~
jrg
It's painful to watch Unix SAs who don't understand shell scripts (which are,
after all, a way of automating repetitive command-line tasks), because it is
such an essential part of understanding the OS and how it works.

I think it is important to know when to use a quick shell script, and when to
solve the problem with some Perl (or even some C.) Sometimes it is quicker to
throw together a shell script, with a bit of sed, awk, or some simple for
loops, automating the command line you just manually ran a moment ago;
sometimes it's best to solve the problem by switching to some Perl.

