The Problem with Perl

[William Goedicke]

Dear Y'all -

As a preferatory note let me say that I've been writing perl for a
decade or so now and, I love perl. It allows me to concentrate my
sporadic programming efforts on a single tool because of its breadth
of functionality.

I've got some friends whose programming activity is not at all like
the sporadic hacks that I engage in. They're extremely expert
programmers with advanced programming degrees from MIT who are
developing things like tank simulations for the DoD in lisp and other
more arcane languages. With the one caveat that it may be OK for a
piker like me who doesn't need to code anything major, they speak of
perl with utter contempt.

The point of this message is that I'd like to open a discussion that
identifies exactly what it is about Perl as a language that offends
the literati of programming and, respecting that there may be some
valid points there, how we can code to avoid the problems these issues
may lead to.

My best understanding of what they think the problem is that Perl is
"context sensitive". That is it behaves differently when data
changes, if lists slip in where scalars were intended the results may
be wildly different than expected. This wouldn't be true in strongly
typed languages like C or lisp.

Do others have knowledge of such (and possibly other) criticisms and,
what do you think we should do to avoid the associated pitfalls.

- Billy

============================================================
William Goedicke (e-mail address removed)
Cell 617-510-7244 http://www.goedsole.com:8080
============================================================

Lest we forget:

"ff0000" (html for bright red) turns out to be as good
an indicator of spam as any pornographic term.

- Paul Graham

 

[A. Sinan Unur]

As a preferatory note let me say that I've been writing perl for a
decade or so now and, I love perl. It allows me to concentrate my
sporadic programming efforts on a single tool because of its breadth
of functionality.

Good for you.

The point of this message is that I'd like to open a discussion that
identifies exactly what it is about Perl as a language that offends
the literati of programming

Oh, please no.

perldoc -q compare

Sinan

 

[D. Marxsen]

....

Do others have knowledge of such (and possibly other) criticisms and,
what do you think we should do to avoid the associated pitfalls.

To me a programming project leader said, perl were "write only language".

I don't take that comment too serious, as ...

.... he is a Python fan ...

.... Perl allows a lot of shortcuts which make it almost unreadable - but you
can omit these and write wonderful speaking code.
Speaking of me, my code looks a bit like Pascal - I don't use these fancy
$_, $. etc. pp. but use the English module any time.
Then, Perl is as readable as many other languages.


Just my two cents ...

Detlef


PS:
This topic may offend those who expect pure programming talk in this NG ...
but it may also be interesting to learn new arguments for defending Perl
against criticisms.

 

[William Goedicke]

Dear Sinan -

Sinan> Oh, please no.

Sinan> perldoc -q compare

I was hoping for considerably more depth than the perldoc answer,
semantic theory sort of stuff.

- Billy

============================================================
William Goedicke (e-mail address removed)
Cell 617-510-7244 http://www.goedsole.com:8080
============================================================

Lest we forget:

Happy isn't something you are; it's something you do.

- William Goedicke

 

[Ian Wilson]

Dear Y'all -

As a preferatory note let me say that I've been writing perl for a
decade or so now and, I love perl. It allows me to concentrate my
sporadic programming efforts on a single tool because of its breadth
of functionality.

I've got some friends whose programming activity is not at all like
the sporadic hacks that I engage in. They're extremely expert
programmers with advanced programming degrees from MIT who are
developing things like tank simulations for the DoD in lisp and other
more arcane languages. With the one caveat that it may be OK for a
piker like me who doesn't need to code anything major, they speak of
perl with utter contempt.

Then I suspect they are unlikely to ever change their minds, no matter what.

The point of this message is that I'd like to open a discussion that
identifies exactly what it is about Perl as a language that offends
the literati of programming

False premise, if at least one person qualifies as literati of
programming and is not offended by Perl. Could it be that your friends'
views are not unanimous amongst the "literati?"

I may be wrong, but "literati" means well-read. Have your friends a good
understanding of Wall's goals and design decisions for Perl? If asked,
can they articulate the criteria Wall and others described for their
design of Perl 5?

and, respecting that there may be some
valid points there, how we can code to avoid the problems these issues
may lead to.

I feel more relevant questions might be: Who? Should they?

My best understanding of what they think the problem is that Perl is
"context sensitive". That is it behaves differently when data
changes, if lists slip in where scalars were intended the results may
be wildly different than expected. This wouldn't be true in strongly
typed languages like C or lisp.

I'm no C programmer but I though bad things (tm) could happen if you
passed a scalar to a function expecting a pointer to an array?

I guess, since I am ignorant of it, that Lisp treats everything as
lists, including zero and single-length lists. I wonder how Lisp behaves
"if x slips in where y were intended" for all x and y. E.g. strings,
integers; references, pointers; constants, functions.

Do others have knowledge of such (and possibly other) criticisms and,
what do you think we should do to avoid the associated pitfalls.

Little, therefore nothing.

 

[William Goedicke]

Dear Detlef et al -

Detlef> ... Perl allows a lot of shortcuts which make it almost
Detlef> unreadable

Perl is indeed heavily idiomatic but, if that's only a concern from a
readibility standpoint then I don't see how any other languages would
be exempt from the same criticism: python's indentation, lisp's
parentheses, C's preprocessor constructions. All are hindrances to
readibility for those who aren't familiar with the language.

One could argue that idioms are also problematic if they have
side-effects which aren't clearly expressed in the syntax. Perl makes
particularly heavy use of this and there are innumerable examples of
pieces of code which do more than you would reasonably expect and, which
wouldn't be recognized except by those who've (carefully) read the right
chapter in the right O'Reily book. (Having said that I've certainly
dismissed those who haven't as beneath interest on many occasions

Detlef> PS: This topic may offend those who expect pure
Detlef> programming talk in this NG ...

Hopefully members of the group will respect discussions like this as
"programming talk". It's not *all* about fixing bad hash reference
syntax.

- Billy

============================================================
William Goedicke (e-mail address removed)
Cell 617-510-7244 http://www.goedsole.com:8080
============================================================

Lest we forget:

"ff0000" (html for bright red) turns out to be as good
an indicator of spam as any pornographic term.

- Paul Graham

 

[Arndt Jonasson]

I'm no C programmer but I though bad things (tm) could happen if you
passed a scalar to a function expecting a pointer to an array?

Yes. If you use correct prototypes when compiling, and ask for warnings,
the compiler will warn. At runtime, you will probably get a core dump.

I guess, since I am ignorant of it, that Lisp treats everything as
lists, including zero and single-length lists. I wonder how Lisp
behaves "if x slips in where y were intended" for all x and
y. E.g. strings, integers; references, pointers; constants, functions.

Not everything is a list in Lisp. There are at least atoms (symbols)
too, and usually numbers separate from atoms.
Variables have no opinion at all about the kind of value that will be
put into them, but a value has a definite type. What the built-in functions
do with the different kinds of values depend on how sensible it is to
return a value. Taking the length of a number usually gives an error.
Some Lisp compilers can generate better code if told that a certain variable
will only hold values of a certain type.

 

[Charlton Wilbur]

WG> I've got some friends whose programming activity is not at all
WG> like the sporadic hacks that I engage in. They're extremely
WG> expert programmers with advanced programming degrees from MIT
WG> who are developing things like tank simulations for the DoD in
WG> lisp and other more arcane languages. With the one caveat
WG> that it may be OK for a piker like me who doesn't need to code
WG> anything major, they speak of perl with utter contempt.

Being an expert does not prevent people from holding poorly-informed
opinions. In fact, being an expert seems to be conducive to holding
poorly-informed opinions, because an expert can spend a considerable
amount of time learning about a narrow field and have only the vaguest
impression of what's going on outside that field.

WG> Do others have knowledge of such (and possibly other)
WG> criticisms and, what do you think we should do to avoid the
WG> associated pitfalls.

Stop worrying about what other people think. If Perl works well for
what you need done, use it. If it doesn't, use something else.

Charlton

 

[ioneabu]

My best understanding of what they think the problem is that Perl is
"context sensitive". That is it behaves differently when data
changes, if lists slip in where scalars were intended the results may
be wildly different than expected. This wouldn't be true in strongly
typed languages like C or lisp.

Regarding C and C++, two words: memory leaks.

I am certain that a strict protocol could be developed within a Perl
project to ensure the same degree of rigor found in projects done in
any language.

I think Perl 6 may resemble Java in a few ways.

wana

 

[William Goedicke]

Dear Charlton -

Charlton> Stop worrying about what other people think.

You misunderstood. I'm not worrying; I'm learning.

- Billy

============================================================
William Goedicke (e-mail address removed)
Cell 617-510-7244 http://www.goedsole.com:8080
============================================================

Lest we forget:

The devil's in the details

 

[Rhugga]

One thing that has always irritated me about perl is its poor
implementation of function arguments lists and the way datatypes are
defined and handled. Being a former C developer this drives me mad. If
you define a function that takes an int for example:

foo (int x) {
// do something
}

Thus function calls like these should produce errors: (an error would
be the function doesn't exist, because in a sense it doesnt)

foo("some string");
foo();
foo(99.99);

In C/C++ the function foo(int x) and foo(char *) are 2 completely
different functions, the names may seem similiar to the human reader,
but deep down inside the nitty gritty these are basically 2 different
functions.

foo("some string");
foo();
foo(99.99);

To me this makes perl a very sloppy language and I certainly wouldnt
use it to process any mission critical data, just leaves to much to
chance and also in certain situations creates a very difficult
debugging effort. In the past we have seen things go pear-shaped
because of this issue when running very high-troughput type stuff.
Basically your stuck with a massive debug effort with nothing really to
go on. You end up bloating your code with print statements that output
debug info and sort it out that way.

 

[phaylon]

Thus function calls like these should produce errors: (an error would be
the function doesn't exist, because in a sense it doesnt)

Hm, I just made myself a little helper module, where I do:

sub {
my($a, $b, $c) = param '_-:%', @_;
# ...
}

This says the parameters are a scalar which must be there (_), one which
can be undefined (-) and the rest is a hash, which will be referenced in
$c. Possibilities are d (digit), a (arrayref), h (guess what), and so it
goes on. I've done this, because prototypes aren't that restricting, and
to experiment with a bit "off-road-coding".

The pro against checking the arguments at compile time is that the given
arguments may vary, which I would miss if it wouldn't be there.

You end up bloating your code with print statements that output debug
info and sort it out that way.

If your language doesn't "care" of something that does not mean that you
also have to ignore it.

g,phay

 

[xhoster]

One thing that has always irritated me about perl is its poor
implementation of function arguments lists and the way datatypes are
defined and handled. Being a former C developer this drives me mad. If
you define a function that takes an int for example:

foo (int x) {
// do something
}

Thus function calls like these should produce errors: (an error would
be the function doesn't exist, because in a sense it doesnt)

foo("some string");
foo();
foo(99.99);

In C/C++ the function foo(int x) and foo(char *) are 2 completely
different functions, the names may seem similiar to the human reader,
but deep down inside the nitty gritty these are basically 2 different
functions.

foo("some string");
foo();
foo(99.99);

To me this makes perl a very sloppy language and I certainly wouldnt
use it to process any mission critical data, just leaves to much to
chance and also in certain situations creates a very difficult
debugging effort. In the past we have seen things go pear-shaped
because of this issue when running very high-troughput type stuff.

Why would the throughput matter? If your input is garbage, it doesn't
matter how much of it there is.

Basically your stuck with a massive debug effort with nothing really to
go on.

You mean other than the warnings that tell you that you used a non-numeric
string as if it were a number at line 1087?

Xho

 

[xhoster]

My best understanding of what they think the problem is that Perl is
"context sensitive". That is it behaves differently when data
changes,

Well duh. What good would a program be that didn't?

if lists slip in where scalars were intended the results may
be wildly different than expected. This wouldn't be true in strongly
typed languages like C or lisp.

I don't think it is generally true in Perl, either. It is the code,
not the data, that determines list or scalar context.

Do others have knowledge of such (and possibly other) criticisms and,
what do you think we should do to avoid the associated pitfalls.

Pay attention to what you are coding!

The biggest problem I run into in Perl is its time and memory usage in
certain areas. After that, most of the problems are political. Vendors
and consultants don't talk up Perl because it doesn't help them sell stuff.

Xho

 

[Anno Siegel]

[Perl as a programming language]

My best understanding of what they think the problem is that Perl is
"context sensitive".

In what sense? "Context sensitive" is a term that applies to grammars
(and, by extension, to parsers).

Perl can't be parsed as a context-free grammar? You bet it can't. Neither
can Fortran, or, AFAIK, C. I don't know about C for sure, but I'd be
surprised. This property of a grammar has little to do with the practical
usability of the programming language.

Perl also has the concept of (list/scalar/void-) context pertaining to
various parts of the source, but describing this as being "context
sensitive" is abuse of terminology.

That is it behaves differently when data
changes,

So? C and Lisp programs don't do that?

if lists slip in where scalars were intended the results may
be wildly different than expected. This wouldn't be true in strongly
typed languages like C or lisp.

Lisp is a typed language? I never noticed.

This critique of Perl contains so many ill-conceived notions, it is hard
to take it serious.

Anno

 

[Tad McClellan]

Sinan> perldoc -q compare

I was hoping for considerably more depth than the perldoc answer,
semantic theory sort of stuff.

Like why Larry designed Perl the way he did?

http://www.wall.org/~larry/natural.html

 

[Eric Bohlman]

(e-mail address removed)-berlin.de (Anno Siegel) wrote in

Perl can't be parsed as a context-free grammar? You bet it can't.
Neither can Fortran, or, AFAIK, C. I don't know about C for sure, but
I'd be surprised. This property of a grammar has little to do with

It can't. C requires that functions be called with the same number of
parameters they're declared with, and that can't be expressed in a CFG.

 

[Charlton Wilbur]

Charlton> Stop worrying about what other people think.

WG> You misunderstood. I'm not worrying; I'm learning.

Well, if you want to learn, ask the people who disparage Perl why they
do so. Odds are you'll find, if you can dig below the surface, that
it's most likely based on inaccurate information, experience with a
disastrous Perl project, or adherence to some orthodox One True Way to
Program.

Perl does have weaknesses. In particular, it is flexible enough that
in the hands of poor programmers it can be disastrous for large
products. This is an intentionally chosen tradeoff, however: if the
language enforces a certain discipline on its programmers, then
programmers who are capable of imposing different discipline on
themselves find the language frustrating to use (though programmers
who would otherwise have no discipline benefit greatly). A bad
programmer using Perl can create more disasters for other people to
clean up than a bad programmer using just about any other language,
because Perl is so flexible and forgiving -- and I've left jobs before
because I knew that if I stayed I'd get to deal with cleaning up Perl
messes; but I don't ascribe that to the language, but to the
programmer using it.

Perl is also not aesthetically pure. It's not a purely functional
language, it's not a purely object-oriented language; it's not a
purely minimalist close-to-the-machine language. It has aspects of
all of them, though. It wasn't designed from the start with a single
vision; it grew in bits and pieces. This lack of purity -- hybrid
vigor, one might say -- is one of its greatest strengths, because
there are many ways to solve any particular problem. But when you
compare it to the purebred Scheme and Eiffel and Smalltalk --
languages that academics are likely to have used disproportionately
more than the hoi polloi -- it looks like a mongrel.

All that said, if you want to understand why your colleages disparage
Perl, ask them. Odds are that the people who disparage Perl, aside
from the odd troll, are not hanging out in comp.lang.perl.misc just
waiting for an opportunity to explain themselves.

Charlton

 

[Eric Bohlman]

Perl does have weaknesses. In particular, it is flexible enough that
in the hands of poor programmers it can be disastrous for large
products. This is an intentionally chosen tradeoff, however: if the
language enforces a certain discipline on its programmers, then
programmers who are capable of imposing different discipline on
themselves find the language frustrating to use (though programmers
who would otherwise have no discipline benefit greatly). A bad

This is a really important point. Perl shouldn't be thought of as an
"undisciplined language"; it should be thought of as a "bring your own
discipline (BYOD) language." Larry's philosophy is that programming
discipline is a human issue, not a technical one, and therefore needs to be
enforced by human (social) means, not through technical characteristics of
tools.

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
Charlton Wilbur

Perl does have weaknesses. In particular, it is flexible enough that
in the hands of poor programmers it can be disastrous for large
products. This is an intentionally chosen tradeoff, however

There is very little "intentionally chosen" in Perl; design-wise Perl
is a hodge-podge of backward-compatibility hacks and incremental
development mess. (It still has some advantages over competition in
other respects - but only for some people; people who cann't fight
their vomit reflex are not in a reasonable state for good coding.)

Compare with what you write below:

all of them, though. It wasn't designed from the start with a single
vision; it grew in bits and pieces.

Hope this helps.
Ilya