[31605] in Perl-Users-Digest
Perl-Users Digest, Issue: 2864 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Mar 10 16:14:25 2010
Date: Wed, 10 Mar 2010 13:14:12 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Wed, 10 Mar 2010 Volume: 11 Number: 2864
Today's topics:
Re: to RG - Lisp lunacy and Perl psychosis <ben@morrow.me.uk>
Re: to RG - Lisp lunacy and Perl psychosis <psilord@merlin.cs.wisc.edu>
Re: to RG - Lisp lunacy and Perl psychosis <rNOSPAMon@flownet.com>
Re: to RG - Lisp lunacy and Perl psychosis <cartercc@gmail.com>
Re: to RG - Lisp lunacy and Perl psychosis sln@netherlands.com
Re: to RG - Lisp lunacy and Perl psychosis <jurgenex@hotmail.com>
Re: to RG - Lisp lunacy and Perl psychosis <jurgenex@hotmail.com>
Re: to RG - Lisp lunacy and Perl psychosis <john@castleamber.com>
Re: to RG - Lisp lunacy and Perl psychosis <cartercc@gmail.com>
Re: to RG - Lisp lunacy and Perl psychosis <jurgenex@hotmail.com>
Re: to RG - Lisp lunacy and Perl psychosis <john@castleamber.com>
Re: to RG - Lisp lunacy and Perl psychosis <rNOSPAMon@flownet.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 10 Mar 2010 16:17:11 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: to RG - Lisp lunacy and Perl psychosis
Message-Id: <79tk67-rp51.ln1@osiris.mauzo.dyndns.org>
[F'ups to clpmisc.]
Quoth ccc31807 <cartercc@gmail.com>:
> On February 27, in a thread on c.l.l, RG had this to say about Perl:
> <quote>
> >> But Perl is just an
> >> abomination through-and-through. I do not deny that many people find it
> >> a productive tool, and about ten years ago having developed a certain
> >> level of respect for some of those people I determined to learn Perl
> >> just to see what those people got out of it. So I picked up a Perl
> >> book, but I could not get past the first few chapters without recoiling
> >> in revulsion. It was just horrible.
> </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>
Good God, that's unreadable. I've no idea what $sec{$k} is, so I'm going
to call it $seck; you would need to find a more sensible name.
my $seck = $sec{$k};
my $xlist = $seck->{xlist};
my $id1 = $seck->{id1};
my $fack = $fac{$id1};
if ($xlist !~ /\d/) {
$fack->{location} = $seck->{site};
}
elsif ($xlist eq $seck->{crs_id}) {
$fack->{location} = $seck->{site};
}
else {
$fack->{location} = $xlist;
}
> 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)))
This is intentionally obfustecated code, so it's not a fair comparison.
Still, I find it perfectly easy to read, and I'm not really that
familiar with Lisp (I've never used it in anger, though I have writtena
little Haskell).
> 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.
I think you're missing the point. Perl is unpleasant in ways which have
little to do with the surface syntax. For instance, would you like to
explain to me why
STDIN->blocking(1);
works the way it does (and when it can and cannot be relied upon), or
why this
BEGIN {
package Baz;
$INC{"Baz.pm"} = $0; # this is unimportant, it's just to
# avoid the need for a separate file
sub foo { warn "Baz" }
}
{
package Foo;
use aliased Baz => Bar;
}
{
package Foo::Bar;
sub foo { warn "Foo::Bar" }
}
Foo::Bar->foo;
doesn't do what you might expect, or what the difference is between
use IO::Handle;
print STDOUT "x";
ungetc STDIN 65;
and between
print STDOUT "x";
STDOUT->print("x");
and what IO::Handle (and all subclasses) have to go through to make the
results mostly make sense (I could go on...)?
Perl is a useful language, and once you know which sharp corners to
avoid it can be very pleasant to use, but denying that there are aspects
of it which are deeply ugly will get you nowhere.
Also, flamebait language-comparison xposts involving Lisp are one of Xah
Lee's trademarks. You might want to look into not imitating him/her/it.
Ben
------------------------------
Date: 10 Mar 2010 16:23:37 GMT
From: Peter Keller <psilord@merlin.cs.wisc.edu>
Subject: Re: to RG - Lisp lunacy and Perl psychosis
Message-Id: <4b97c789$0$9898$80265adb@spool.cs.wisc.edu>
In comp.lang.lisp ccc31807 <cartercc@gmail.com> wrote:
> 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
------------------------------
Date: Wed, 10 Mar 2010 09:45:20 -0800
From: Ron Garret <rNOSPAMon@flownet.com>
Subject: Re: to RG - Lisp lunacy and Perl psychosis
Message-Id: <rNOSPAMon-4A26E0.09452010032010@news.albasani.net>
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.
In article
<19c5b00d-c1e0-4016-9f72-37229cbf42b9@g19g2000yqe.googlegroups.com>,
ccc31807 <cartercc@gmail.com> wrote:
> On February 27, in a thread on c.l.l, RG had this to say about Perl:
> <quote>
> >> But Perl is just an
> >> abomination through-and-through. I do not deny that many people find it
> >> a productive tool, and about ten years ago having developed a certain
> >> level of respect for some of those people I determined to learn Perl
> >> just to see what those people got out of it. So I picked up a Perl
> >> book, but I could not get past the first few chapters without recoiling
> >> in revulsion. It was just horrible.
> </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
------------------------------
Date: Wed, 10 Mar 2010 10:02:01 -0800 (PST)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: to RG - Lisp lunacy and Perl psychosis
Message-Id: <6c65fa79-cc92-4446-b197-edafc1d118f3@e7g2000yqf.googlegroups.com>
On Mar 10, 11:03=A0am, Tamas K Papp <tkp...@gmail.com> wrote:
> > Not my intent to start a flame war. Please reread my post.
>
> Yeah, sure. =A0Cross-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.
> >> 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.
>
> 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.
------------------------------
Date: Wed, 10 Mar 2010 10:20:30 -0800
From: sln@netherlands.com
Subject: Re: to RG - Lisp lunacy and Perl psychosis
Message-Id: <giofp51gr7v0tdlcqlo2osr4k8t11elhli@4ax.com>
On Wed, 10 Mar 2010 09:45:20 -0800, Ron Garret <rNOSPAMon@flownet.com> wrote:
>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
------------------------------
Date: Wed, 10 Mar 2010 10:37:43 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: to RG - Lisp lunacy and Perl psychosis
Message-Id: <a4ofp5p0026pmis1a5cc4t8dg9cst9ugfv@4ax.com>
Ron Garret <rNOSPAMon@flownet.com> wrote:
>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.
>> 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.
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
------------------------------
Date: Wed, 10 Mar 2010 10:48:50 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: to RG - Lisp lunacy and Perl psychosis
Message-Id: <89qfp59frihbbqi64i8dh7f5cfenu60tjk@4ax.com>
ccc31807 <cartercc@gmail.com> wrote:
>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
------------------------------
Date: Wed, 10 Mar 2010 13:20:18 -0600
From: John Bokma <john@castleamber.com>
Subject: Re: to RG - Lisp lunacy and Perl psychosis
Message-Id: <87mxygugp9.fsf@castleamber.com>
Jürgen Exner <jurgenex@hotmail.com> writes:
> Wasn't it the Inuit language, that has over 50 different words for
> snow?
http://en.wikipedia.org/wiki/Eskimo_words_for_snow
--
John Bokma j3b
Hacking & Hiking in Mexico - http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development
------------------------------
Date: Wed, 10 Mar 2010 12:20:07 -0800 (PST)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: to RG - Lisp lunacy and Perl psychosis
Message-Id: <24204029-6dde-46fa-b61b-5a903472479d@g10g2000yqh.googlegroups.com>
On Mar 10, 1:48=A0pm, J=FCrgen Exner <jurge...@hotmail.com> wrote:
> 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, ... ) =3D split;
$fac{$id} =3D {
id =3D> $id,
site =3D> $site,
location =3D> $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
------------------------------
Date: Wed, 10 Mar 2010 12:39:43 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: to RG - Lisp lunacy and Perl psychosis
Message-Id: <o40gp5dr46a55eb16quqjonjmgmra86j9e@4ax.com>
ccc31807 <cartercc@gmail.com> wrote:
>On Mar 10, 1:48 pm, Jürgen Exner <jurge...@hotmail.com> wrote:
>> 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
------------------------------
Date: Wed, 10 Mar 2010 14:54:15 -0600
From: John Bokma <john@castleamber.com>
Subject: Re: to RG - Lisp lunacy and Perl psychosis
Message-Id: <87iq93vqx4.fsf@castleamber.com>
Jürgen Exner <jurgenex@hotmail.com> writes:
> ccc31807 <cartercc@gmail.com> wrote:
>>On Mar 10, 1:48 pm, Jürgen Exner <jurge...@hotmail.com> wrote:
>>> 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.
--
John Bokma j3b
Hacking & Hiking in Mexico - http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development
------------------------------
Date: Wed, 10 Mar 2010 12:56:16 -0800
From: Ron Garret <rNOSPAMon@flownet.com>
Subject: Re: to RG - Lisp lunacy and Perl psychosis
Message-Id: <rNOSPAMon-1B22CB.12561610032010@news.albasani.net>
In article <a4ofp5p0026pmis1a5cc4t8dg9cst9ugfv@4ax.com>,
J?rgen Exner <jurgenex@hotmail.com> wrote:
> Ron Garret <rNOSPAMon@flownet.com> wrote:
> >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 does that have to do with what I asked?
> > 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).
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.
> > What is /\d/?
>
> 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?
> >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.
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.
> >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?
Why would I want to distinguish between types at all?
> >It distinguishes between strings and regular expressions,
>
> Well, those are very different animals. Strings are data while REs are
> code.
Potato, potahto. Strings are code when you feed them to EVAL.
> >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.
Let me be more precise: that you can't look up unless you know the
secret incantation.
> >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.'
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
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 2864
***************************************
