to RG - Lisp lunacy and Perl psychosis

C

ccc31807

On February 27, in a thread on c.l.l, RG had this to say about Perl:
</quote>
I wanted to reply but also wanted to take some time to think about my
reply.

Yesterday, I wrote a typical data munging script using Perl. I was
using two hashes, %sec and %fac, and needed to populate the 'location'
value in %fac with the value in %sec depending on the state of the
'xlist' key in %sec. The code looks horrible, but I think any
journeyman programmer can follow the logic even if he doesn't
understand Perl or the data structures. This is the code, and I might
add that it's working code:

<code>
if ($sec{$k}{'xlist'} !~ /\d/)
{ $fac{$sec{$k}{'id1'}}{'location'} = $sec{$k}{'site'}; }
elsif ($sec{$k}{'xlist'} eq $sec{$k}{'crs_id'})
{ $fac{$sec{$k}{'id1'}}{'location'} = $sec{$k}{'site'}; }
else
{ $fac{$sec{$k}{'id1'}}{'location'} = $sec{$sec{$k}{'xlist'}}
{'site'}; }
</code>

In David Lamkins' book 'Successful Common Lisp' in chapter 4, we find
the following. This also looks horrible, and I don't think a
journeyman programmer can follow this logic unless he knew something
about Lisp.

<quote>
The following piece of code illustrates how you can use the same name
for different purposes. Take a minute to read this, and see how many
separate uses you can count for the name FUNNY.

(defun funny (funny)
"funny..."
(if (zerop funny)
:funny
(list
(cons funny
(let ((funny funny))
(setq funny (1- funny))
(funny funny)))
funny)))

Here are the five roles played by this one name:

1. function name
2. function argument
3. a word in the documentation string
4. a constant in the keyword package
5. a new lexical variable
</quote>

Perl uses sigils ($, !, %, &) to signify a token's usage. Lisp uses
positional notation for the same thing. It's not that one's bad and
one's not -- it's just cosmetic. It's as if one language is wearing a
pinstripe suit with wing tips and the other is wearing a blue blazer
with penny loafers. Underneath, the logic is the same in both
languages, and once you get past the peculiarities of the language you
use the same logic. (I'm not arguing that the power of the languages
is the same, in several respects Lisp is more powerful than Perl, but
that the process of thinking through a problem is the same.)

Here's the point: to call one language horrible and an abomination
because you don't understand it, and ignoring the horribleness and the
abominable in another language because you do understand it, doesn't
make any sense. The cover doesn't make the book the clothes don't make
the man, and the appearance doesn't make the language. Instead, a
language should be judged on the work that it permits, and in this
respect (based on surveys like TIOBE and advertised positions) Perl
seems to be a lot more useful (and perhaps a lot less horrible) than
CL.

One language isn't better or worse that the other, they are just
different, and the expression of RG's opinion is simply a value
judgment, which others may or may not share.

CC.
 
T

Tamas K Papp

(defun funny (funny)
"funny..."
(if (zerop funny)
:funny
(list
(cons funny
(let ((funny funny))
(setq funny (1- funny))
(funny funny)))
funny)))

Here are the five roles played by this one name:

1. function name
2. function argument
3. a word in the documentation string 4. a constant in the keyword
package
5. a new lexical variable

You mean that you can use something as a variable name, and then use
the same letters as part of a string? Gosh, Common Lisp must be Pure
Madness!

But more seriously, you completely misunderstand Common Lisp when you
write "roles played by this ONE NAME" (my emphasis). It is _not_ one
name.

Your post actually highlights some similarities between Perl and CL:
both have various namespaces, once you see through the thin layer of
syntax for accessing these. So your feeble attempt at starting a
flamewar is pretty... funny.

Tamas
 
C

ccc31807

So your feeble attempt at starting a flamewar is pretty... funny.

Not my intent to start a flame war. Please reread my post.
Here's the point: to call one language horrible and an abomination
because you don't understand it, and ignoring the horribleness and the
abominable in another language because you do understand it, doesn't
make any sense.

CC
 
T

Tamas K Papp

Not my intent to start a flame war. Please reread my post.

Yeah, sure. Cross-posting something like this usually promotes peace
and happiness.

You failed to show anything horrible or abominable in CL. All you
demonstrated was your confusion (but that was done pretty well,
congrats).

Cheers,

Tamas
 
P

Peter Keller

In comp.lang.lisp ccc31807 said:
Perl uses sigils ($, !, %, &) to signify a token's usage.

That's not entirely true.

Example:

# BEGIN CODE
#! /usr/bin/perl

$foo = 12;
$foo{'key'} = 34;
$foo[9] = 55;

print "$foo $foo{'key'} $foo[9]\n";
exit 0;
# END CODE

C has similar problems between type names and functions:

/* Begin Code */
#include <stdio.h>
#include <stdlib.h>

struct XXX
{
int foo;
};

void XXX(void)
{
printf("Hello world\n");
}

int main(void)
{
struct XXX fg;

XXX();

return 0;
}
/* End Code */

Nearly all languages have different namespaces for their semantic ideas:
functions, types, variables, etc, etc, etc. Symbols often intersect
in representation: the symbol 'foo' in one namespace is identical to
the symbol 'foo' in another namespace. They rarely, but sometimes do
depending on the language, intersect in meaning.

An example is calling a higher order function in scheme versus lisp.
In scheme you simply call it, in lisp, you use funcall.

Later,
-pete
 
R

Ron Garret

Most of what I have to say about this has already been said by other
people, but since this post is addressed specifically to me I'll respond
nonetheless.

ccc31807 said:
On February 27, in a thread on c.l.l, RG had this to say about Perl:

</quote>
I wanted to reply but also wanted to take some time to think about my
reply.

Yesterday, I wrote a typical data munging script using Perl. I was
using two hashes, %sec and %fac, and needed to populate the 'location'
value in %fac with the value in %sec depending on the state of the
'xlist' key in %sec. The code looks horrible, but I think any
journeyman programmer can follow the logic even if he doesn't
understand Perl or the data structures. This is the code, and I might
add that it's working code:

<code>
if ($sec{$k}{'xlist'} !~ /\d/)
{ $fac{$sec{$k}{'id1'}}{'location'} = $sec{$k}{'site'}; }
elsif ($sec{$k}{'xlist'} eq $sec{$k}{'crs_id'})
{ $fac{$sec{$k}{'id1'}}{'location'} = $sec{$k}{'site'}; }
else
{ $fac{$sec{$k}{'id1'}}{'location'} = $sec{$sec{$k}{'xlist'}}
{'site'}; }
</code>

In David Lamkins' book 'Successful Common Lisp' in chapter 4, we find
the following. This also looks horrible, and I don't think a
journeyman programmer can follow this logic unless he knew something
about Lisp.

<quote>
The following piece of code illustrates how you can use the same name
for different purposes. Take a minute to read this, and see how many
separate uses you can count for the name FUNNY.

(defun funny (funny)
"funny..."
(if (zerop funny)
:funny
(list
(cons funny
(let ((funny funny))
(setq funny (1- funny))
(funny funny)))
funny)))

Here are the five roles played by this one name:

1. function name
2. function argument
3. a word in the documentation string
4. a constant in the keyword package
5. a new lexical variable
</quote>

Perl uses sigils ($, !, %, &) to signify a token's usage. Lisp uses
positional notation for the same thing. It's not that one's bad and
one's not -- it's just cosmetic. It's as if one language is wearing a
pinstripe suit with wing tips and the other is wearing a blue blazer
with penny loafers. Underneath, the logic is the same in both
languages, and once you get past the peculiarities of the language you
use the same logic. (I'm not arguing that the power of the languages
is the same, in several respects Lisp is more powerful than Perl, but
that the process of thinking through a problem is the same.)

Here's the point: to call one language horrible and an abomination
because you don't understand it, and ignoring the horribleness and the
abominable in another language because you do understand it, doesn't
make any sense. The cover doesn't make the book the clothes don't make
the man, and the appearance doesn't make the language. Instead, a
language should be judged on the work that it permits, and in this
respect (based on surveys like TIOBE and advertised positions) Perl
seems to be a lot more useful (and perhaps a lot less horrible) than
CL.

One language isn't better or worse that the other, they are just
different, and the expression of RG's opinion is simply a value
judgment, which others may or may not share.

Certainly my opinion is only my opinion. But in my opinion it is not
true that "one language isn't better or worse than the other."
Brainf*ck, Whitespace, and Unlambda, for example, were specifically
designed to be bad languages, and they are. Perl was not specifically
designed to be a bad language, but it is (IMHO of course) for many of
the same reasons that the aforementioned languages are bad.

You write:
I think any
journeyman programmer can follow the logic even if he doesn't
understand Perl or the data structures

Maybe I don't qualify as a journeyman I can't follow that Perl code, and
for exactly the same reason that I can't follow Brainf*ck code: too much
punctuation. What does !~ mean? What do the curly braces denote? What
is /\d/? And if I don't know the answers, how do I look them up? (Yes,
I tried Perldoc. It didn't help.)

The Lisp code, by contrast, has only three items of punctuation that I
have to understand: parentheses, double quotes, and the colon. All the
rest is English words. Some of those words might be mysterious (like
CONS) but at least I can plug those into a search engine to obtain
additional clues. And the double quotes mean exactly what they mean in
common usage, so that leaves only two punctuation marks to deal with.

Also, others have mentioned this but it's worth reiterating: you've
taken actual working Perl code and compared it to a Lisp example
specifically designed to be pathological. That doesn't exactly make it
a fair fight. You can write obfuscated code in any language.
Perl uses sigils ($, !, %, &) to signify a token's usage.

No, Perl uses sigils to indicate a variable's data type, not a token's
usage. Except that it doesn't. It distinguishes between scalars,
lists, and hash tables, but not between integers, floats, and strings.
It distinguishes between strings and regular expressions, but not
between strings and code. It has all kinds of weird punctuationy things
that you can't look up, like $@ and !~ and <>. It fails silently where
it should produce errors. It violates universally accepted conventions
about what, for example, double quotes mean. For example, this:

print "The widget costs $12.75.";

The actual behavior of that code snippet is not justifiable under any
sane language semantics.

I could go on and on. But life is short. If you really want to
continue this discussion (and if you do you really ought to consider
getting yourself a life instead) I'd suggest starting with a pair of
examples that do more or less the same thing so we can compare apples
and apples.

rg
 
C

ccc31807

Yeah, sure.  Cross-posting something like this usually promotes peace
and happiness.

You still haven't read my post, or if you did you haven't comprehended
it. There's nothing in it that works against peace and happiness. I
actually wanted to increase peace and happiness insofar as in my power
to do so.
You failed to show anything horrible or abominable in CL.

That's right. There isn't anything horrible or abominable in either of
the two languages. It certainly wasn't my intention to create that
impression, just to opposite in fact.

Somehow, you think that I've said exactly the opposite of what I
meant. Either I wasn't clear in my writing, or you weren't clear in
your reading. I'll try one more time.

<emphasis>Calling a language horrible because you don't understand it
is a mindless prejudice.</emphasis>
A
Do you understand that? I contrasted a bit of working Perl code (which
appears to be abominable) to a deliberately obfuscated bit of Lisp
code to make that point. I really don't understand why you think I
have insulted CL, when I undertook to say that insult based on
ignorance is pointless.

CC.
 
S

sln

It has all kinds of weird punctuationy things
that you can't look up, like $@ and !~ and <>. It fails silently where
it should produce errors. It violates universally accepted conventions
about what, for example, double quotes mean. For example, this:

print "The widget costs $12.75.";

The actual behavior of that code snippet is not justifiable under any
sane language semantics.

q{$12} =~ /((((((((((((...))))))))))))/;
print "The widget costs $12.75.";
--
The widget costs $12.75.

Works for me.

-sln
 
J

Jürgen Exner

Ron Garret said:
Maybe I don't qualify as a journeyman I can't follow that Perl code, and
for exactly the same reason that I can't follow Brainf*ck code: too much
punctuation. What does !~ mean?

perldoc perlop:
Binary "!=" returns true if the left argument is numerically not equal
to the right argument.
What do the curly braces denote?

Depends on where they are used. Some common uses include enclosure of
code block (perldoc perlsyn) and indexing of hashes (perldoc perldata).
What is /\d/?

perldoc perlre:
In addition, Perl defines the following:
\d Match a digit character
And if I don't know the answers, how do I look them up? (Yes,
I tried Perldoc. It didn't help.)

It's all there. Granted, in particular perlop is hopelessly overloaded
and therefore information is hard to find, but you are very welcome to
improve it.
The Lisp code, by contrast, has only three items of punctuation that I
have to understand: parentheses, double quotes, and the colon. All the
rest is English words. Some of those words might be mysterious (like
CONS) but at least I can plug those into a search engine to obtain
additional clues. And the double quotes mean exactly what they mean in
common usage, so that leaves only two punctuation marks to deal with.

In other words: you have a very limited vocabulary. Sure, that makes it
much easier to learn the vocabulary, there are just much fewer words to
learn. But at the same time you are paying for this advantage with
lenghty sentences (=code) to express the same content (=algorithm).
Wasn't it the Inuit language, that has over 50 different words for snow?
To express the same differentiation in other languages you need half a
sentence for what Inuit can do in a single word.
Also, others have mentioned this but it's worth reiterating: you've
taken actual working Perl code and compared it to a Lisp example
specifically designed to be pathological. That doesn't exactly make it
a fair fight. You can write obfuscated code in any language.

That Perl code clearly qualifies as obfuscuted, no sane programmer would
write code like that. Ben already demonstrated how equivalent, actual,
readable Perl code would look like.
No, Perl uses sigils to indicate a variable's data type, not a token's
usage.
Correct.

Except that it doesn't. It distinguishes between scalars,
lists, and hash tables, but not between integers, floats, and strings.

Why would you want to distinguish between them on such a low level? A
scalar is all those simultaneously and you can use whichever version you
need at any given moment. No awkward conversion from int to string only
because you want to print that value, no need for special conversion
from text (just read from a file or user input) to floating point to do
some calculations. Seems very convenient to me.
It distinguishes between strings and regular expressions,

Well, those are very different animals. Strings are data while REs are
code.
but not between strings and code.

Perl most certainly does clearly differentiate between strings (=data)
and code, although you can breach the border using eval() or in REs.
It has all kinds of weird punctuationy things
that you can't look up, like $@ and !~ and <>.

Yes, you can. See perldoc perlvar, perldoc perlop, perldoc perlop.
It fails silently where
it should produce errors. It violates universally accepted conventions
about what, for example, double quotes mean. For example, this:

print "The widget costs $12.75.";
The actual behavior of that code snippet is not justifiable under any
sane language semantics.

If you don't want variables ($12) to be interpolated, then don't use
quotes that interpolate variables:

print 'The widget costs $12.75.'

jue
 
J

Jürgen Exner

ccc31807 said:
I contrasted a bit of working Perl code (which
appears to be abominable)

That code is abominable and obfuscated, but of course you can write
abominable and obfuscated code in any programming language.

jue
 
C

ccc31807

That code is abominable and obfuscated, but of course you can write
abominable and obfuscated code in any programming language.

That code is hard read, but it's not obfuscated. The variable 'names'
represent scalar values, in this case, an 'integer' used as a key. The
convoluation comes from Perl's awkward syntax for multi-level data
structures, in this particular case, a hash element that consists of
an anonymous hash, thus
$sec{$k}{'xlist'}
in a foreach loop (which I omitted) like this
foreach my $key (keys %sec) { ...$sec{$key}{'xlist'}... }
and
$fac{$sec{$key}{'id1'}}{'location'}
simply references the $sec{$key}{'id1'} element in
$fac{KEY}{'location'}

This isn't harder than C pointers.

And yes, I could have aliased the hash references to more readable
variable names, but I wrote the code, I'm reading the code, and I'm
maintaining the code ... why should I have to think of a redundant
variable name when I have the hash assignments a few lines above this?

my %fac;
while (<SOME_DATA_SOURCE>)
{
chomp;
my ($id, $site, $location, ... ) = split;
$fac{$id} = {
id => $id,
site => $site,
location => $location,
...
};
}

The script is a short one, about 40 lines of code excluding comments,
use statements, etc., and wouldn't give a Perl programmer any problem.

CC
 
J

Jürgen Exner

ccc31807 said:
That code is abominable and obfuscated, but of course you can write
abominable and obfuscated code in any programming language.
[...]
$fac{$sec{$key}{'id1'}}{'location'}

Thank you for confirming my point.
This isn't harder than C pointers.

Saying something isn't harder than C pointers is like saying a desease
isn't worse than the Bubonic plague: it gives very little comfort to
people suffering from it.
Actually C pointers are probably among the worst concepts ever invented
in computer science.

jue
 
J

John Bokma

Jürgen Exner said:
ccc31807 said:
That code is abominable and obfuscated, but of course you can write
abominable and obfuscated code in any programming language.
[...]
$fac{$sec{$key}{'id1'}}{'location'}

Thank you for confirming my point.
This isn't harder than C pointers.

Saying something isn't harder than C pointers is like saying a desease
isn't worse than the Bubonic plague: it gives very little comfort to
people suffering from it.
Actually C pointers are probably among the worst concepts ever invented
in computer science.

They are not "invented" they are somewhat a 1:1 mapping to
assembly. I've never had problems with C pointers but that's most likely
also because I had programmed in Z80 assembly [1] (and some motorola
processors) for a few years before programming in C.

I do agree, however, that it would've been nice if C had references like
Perl, and (harder to get to) pointers as they are now. That, and a
better standard library.

Disclaimer: haven't programmed in C for a while.

[1] including hacking a subset of Forth :-D.
 
R

Ron Garret

J?rgen Exner said:
perldoc perlop:
Binary "!=" returns true if the left argument is numerically not equal
to the right argument.

What does that have to do with what I asked?
Depends on where they are used. Some common uses include enclosure of
code block (perldoc perlsyn) and indexing of hashes (perldoc perldata).

Yes, that is exactly the problem. Perl is not content with assigning
semantics meaning to every single symbol on the keyboard, it *overloads*
those symbols, so even if you *could* look them up you *still* wouldn't
know what they meant without first deciphering the context.
perldoc perlre:

And how is one supposed to know that "perlre" is the right thing to look
up here?

BTW, these are all rhetorical questions.

It's all there. Granted, in particular perlop is hopelessly overloaded
and therefore information is hard to find, but you are very welcome to
improve it.

And why on earth would I want to do that? No, seriously, what's the
payoff? That is not a rhetorical question. What will I be able to do
if I invest effort into learning and/or improving Perl that I cannot do
just as easily and just as well in, say, Python?
In other words: you have a very limited vocabulary.

No. A limited grammar and a limited vocabulary are not the same thing.
I can generate new symbols whenever I need them. I can even composulate
fragulards of existentialized symboloids to imposulate novelish
intentionalitizing and you even stand a fighting chance of figuring out
what I mean.
Sure, that makes it
much easier to learn the vocabulary, there are just much fewer words to
learn. But at the same time you are paying for this advantage with
lenghty sentences (=code) to express the same content (=algorithm).
http://rondam.blogspot.com/2008/02/z-shrtr-bttr.html

Wasn't it the Inuit language, that has over 50 different words for snow?

No, that's a myth.
Why would you want to distinguish between them on such a low level?

Why would I want to distinguish between types at all?
Well, those are very different animals. Strings are data while REs are
code.

Potato, potahto. Strings are code when you feed them to EVAL.
Yes, you can. See perldoc perlvar, perldoc perlop, perldoc perlop.

Let me be more precise: that you can't look up unless you know the
secret incantation.
If you don't want variables ($12) to be interpolated, then don't use
quotes that interpolate variables:

print 'The widget costs $12.75.'

Yes, I know that. But what kind of brain damaged language allows
numbers to be the names of variables in the first place? (That's
another rhetorical question BTW.)

rg
 
J

Jürgen Exner

John Bokma said:
Jürgen Exner said:
ccc31807 said:
That code is abominable and obfuscated, but of course you can write
abominable and obfuscated code in any programming language. [...]
$fac{$sec{$key}{'id1'}}{'location'}

Thank you for confirming my point.
This isn't harder than C pointers.

Saying something isn't harder than C pointers is like saying a desease
isn't worse than the Bubonic plague: it gives very little comfort to
people suffering from it.
Actually C pointers are probably among the worst concepts ever invented
in computer science.

They are not "invented" they are somewhat a 1:1 mapping to
assembly.

Exactly. You can hardly do worse than that ;-)

But in all fairness, when C was developed in the early 70s it was a
major step forward and Kerningham and Ritchie could not possibly have
known as much as we do today. For its time it was a great concept and
implementation. It's just that it is way outdated 40 years later.
I've never had problems with C pointers but that's most likely
also because I had programmed in Z80 assembly [1] (and some motorola
processors) for a few years before programming in C.

Well, not much Z80 but quite a bit 6502 here in this corner.
I do agree, however, that it would've been nice if C had references like
Perl, and (harder to get to) pointers as they are now.

Or even Pascal or Modula or Haskell or pick pretty much any more modern
language. However you cannot blame a 40 year old language for reflecting
the thinking of 40 years ago.

jue
 
J

Jürgen Exner

Ron Garret said:
What does that have to do with what I asked?

Sorry, my bad:
Binary "!~" is just like "=~" except the return value is negated in
the logical sense.
Yes, that is exactly the problem. Perl is not content with assigning
semantics meaning to every single symbol on the keyboard, it *overloads*
those symbols, so even if you *could* look them up you *still* wouldn't
know what they meant without first deciphering the context.

You mean like lead and lead in English? Or + and + in C which, gasp, can
be used for char, short, byte, int, long, float, pointers, and a myriad
of others?
And how is one supposed to know that "perlre" is the right thing to look
up here?

Because you were looking at a function who's first argument is a regular
expression and therefore checking out the documentation about regular
expressions as mentioned at the root level of the documentation in
"perldoc perl" seems like a good idea?
BTW, these are all rhetorical questions.



And why on earth would I want to do that? No, seriously, what's the
payoff? That is not a rhetorical question. What will I be able to do
if I invest effort into learning and/or improving Perl that I cannot do
just as easily and just as well in, say, Python?

True, for you it would be a major drawback because you couldn't rant
about it any longer.

[...]
Why would I want to distinguish between types at all?

So are you suggesting that e.g. C's distinction between short, byte,
char, int, long, unsigned, double, ultra-special-extra-big .... would be
even better?
Typing is an aid to the programmer to avoid errors by inadvertently
using incompatible data types. However if the programming language
automatically converts between different data types according to context
and I can use them safely without ever thinking about a conversion, then
that is as big a step forward as not having to manually deal with memory
allocation and garbage collection of dynamic data structures.
Potato, potahto. Strings are code when you feed them to EVAL.

I think I did mention eval(). And yes I also mentioned that eval() (as
well as RE when used with /e which is just an eval in disguise) breaks
the paradigm. But still this is only one very specific place which you
normally would not use in every-day code. Actually people are strongly
advised not to use eval for strings unless they know exactly why they
need to do it.
Let me be more precise: that you can't look up unless you know the
secret incantation.

Where's the problem? Any item with a $ up front is a variable, so you
will probably find it in perldoc perlvar. The other two take arguments
and do some computation. So chances are good you will find them either
as functions (perldoc -f .....; no luck there) or in perldoc perlop as
suggested by the root of the perldoc tree.
Yes, I know that. But what kind of brain damaged language allows
numbers to be the names of variables in the first place? (That's
another rhetorical question BTW.)

A language that wants something better than \12 as a variable name for
captured content from the 12th RE group?

jue
 
C

ccc31807

Most of what I have to say about this has already been said by other
people, but since this post is addressed specifically to me I'll respond
nonetheless.

Thank you. This is the thoughtful, mature response that I hoped for,
rather than the rant that I feared.
Maybe I don't qualify as a journeyman I can't follow that Perl code, and

You don't give yourself enough credit:
if (CONDITION 1) assign A to VAR
else if (CONDITION 2) assign B to VAR
else assign C to VAR
What
is /\d/?

from perlre:
\d Match a digit character
that you can't look up, like $@ and !~ and <>.

from perlvar:
$@ The Perl syntax error message from the last eval() operator.

from perlop:
The null filehandle <> is special: it can be used to emulate the
behavior of sed and awk. Input from <> comes either from standard
input, or from each file listed on the command line.

Binary ``!~'' is just like ``=~'' except the return value is negated
in the logical sense.
print "The widget costs $12.75.";

Variable interpolation allows you to avoid stuff like this:
print "The widget costs $" + var ".";
If you don't want variable interpolation, use single quotes:
'The widget costs $12.75.'
If you want to use double quotes, escape $:
"The widget costs \$12.75."
The actual behavior of that code snippet is not justifiable under any sane language semantics.

Please see my justification above.
 If you really want to
continue this discussion

I really don't want to continue this discussion. I've said all I
intended to say, which was to respond to your remark that I quoted in
the original post. I respect your right to have an opinion, but I
don't respect your screed because it seemed to me to be based on
prejudice and ignorance.

My job entails querying databases and munging the data, and Perl is
well suited for this task -- after a bit of experience you can write
an assignment statement like:
$fac{$sec{$k}{'id1'}}{'location'} =
$sec{$sec{$k}{'xlist'}}{'site'};
without pausing to work out the fact that you are assigning the value
of a key to an anonymous hash held as a reference by the second hash
key to a key of an anonymous hash held as a reference by a key to the
first hash. Perl is a fat, ugly, old bitch but she makes some jobs
easy. You can justifiably criticize her appearance, and you can say
that you were unable to live with her, but you can't say that she IS
'horrible' and 'abominable' based on her appearance or the fact that
you can't live with her. She actually has a very sweet disposition
once you get to know her.

Ron, this isn't meant to insult you, or the Lisp community, or the
Perl community for that matter. Thanks for your response.

CC.
 
R

Ron Garret

ccc31807 said:
Thank you. This is the thoughtful, mature response that I hoped for,
rather than the rant that I feared.

I'm not Erik even though I may occasionally agree with some of his
positions.
Perl is a fat, ugly, old bitch but she makes some jobs
easy. You can justifiably criticize her appearance, and you can say
that you were unable to live with her, but you can't say that she IS
'horrible' and 'abominable' based on her appearance or the fact that
you can't live with her. She actually has a very sweet disposition
once you get to know her.

I don't know why you think "fat, ugly, old bitch" is more acceptable as
hyperbole than "horrible" and "abominable" but to me they are equivalent
sentiments. Perl's syntax is IMHO very badly designed. Python
dominates Perl in every conceivable way IMHO. I've had one firsthand
experience with Perl in production that turned out very badly. If
you're productive in Perl, more power to you. But you won't be working
for me.
Ron, this isn't meant to insult you, or the Lisp community, or the
Perl community for that matter. Thanks for your response.

You bet.

rg
 
C

ccc31807

 Python
dominates Perl in every conceivable way IMHO.

I did a project in Python, once, and it turned out well. Python is a
sweet language, and I understand that they are now teaching it as the
first language at both MIT and GaTech.
 I've had one firsthand
experience with Perl in production that turned out very badly.

Was that because Perl was a bad match for the project? Or because the
developers were incompetent in Perl? I've done several major database
projects in Perl, and a great number of minor projects in Perl, and my
experience is that the match of a technology to a task sometimes is a
management decision, and managers sometimes make bad decisions.
 If
you're productive in Perl, more power to you.  But you won't be working
for me.

I won't be working for you anyway. I've reached my level of
incompetence, and I intend to stay there! ;-)

CC
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top