Prev: The correct choice for implementation (was: A simple web clientlibrary)
Next: Solved Re: Emacs speedbar doesn't show .lisp and .asd files
From: Ben Morrow on 10 Mar 2010 11:17
[F'ups to clpmisc.]

Quoth ccc31807 <cartercc(a)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

From: Ron Garret on 10 Mar 2010 12:45
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(a)g19g2000yqe.googlegroups.com>,
ccc31807 <cartercc(a)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
From: ccc31807 on 10 Mar 2010 13:02
On Mar 10, 11:03 am, Tamas K Papp <tkp...(a)gmail.com> wrote:
> > 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 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.
From: J�rgen Exner on 10 Mar 2010 13:37
Ron Garret <rNOSPAMon(a)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
From: J�rgen Exner on 10 Mar 2010 13:48
ccc31807 <cartercc(a)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
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11 12
Prev: The correct choice for implementation (was: A simple web clientlibrary)
Next: Solved Re: Emacs speedbar doesn't show .lisp and .asd files