to RG - Lisp lunacy and Perl psychosis
ccc31807
<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.
CC.
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
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
Tamas K Papp
> On Mar 10, 10:46 am, Tamas K Papp <tkp...@gmail.com> wrote:
>> So your feeble attempt at starting a flamewar is pretty... funny.
>
> Not my intent to start a flame war. Please reread my post.
Yeah, sure. Cross-posting something like this usually promotes peace
and happiness.
>> 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. All you
demonstrated was your confusion (but that was done pretty well,
congrats).
Cheers,
Tamas
Ben Morrow
Quoth ccc31807 <cart...@gmail.com>:
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
Peter Keller
> 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
Ron Garret
people, but since this post is addressed specifically to me I'll respond
nonetheless.
In article
<19c5b00d-c1e0-4016...@g19g2000yqe.googlegroups.com>,
ccc31807 <cart...@gmail.com> wrote:
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
ccc31807
> > 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.
s...@netherlands.com
>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�rgen Exner
>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
J�rgen Exner
>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
John Bokma
> 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
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�rgen Exner
>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
John Bokma
> ccc31807 <cart...@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.
Ron Garret
J?rgen Exner <jurg...@hotmail.com> wrote:
> Ron Garret <rNOS...@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
J�rgen Exner
>>>> 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
Tad McClellan
Ron Garret <rNOS...@flownet.com> wrote:
> In article <a4ofp5p0026pmis1a...@4ax.com>,
> J?rgen Exner <jurg...@hotmail.com> wrote:
>
>> Ron Garret <rNOS...@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?
Nothing, but it does go a long way in supporting your point
about punctuation being hard to read correctly. :-)
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
J�rgen Exner
>In article <a4ofp5p0026pmis1a...@4ax.com>,
> J?rgen Exner <jurg...@hotmail.com> wrote:
>
>> Ron Garret <rNOS...@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?
Sorry, my bad:
Binary "!~" is just like "=~" except the return value is negated in
the logical sense.
>> > 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.
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?
>> > What is /\d/?
>>
>> perldoc perlre:
>
>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.
>
>
>> 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?
True, for you it would be a major drawback because you couldn't rant
about it any longer.
[...]
>> >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?
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.
>> >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.
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.
>> >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.
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.
>> >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.)
A language that wants something better than \12 as a variable name for
captured content from the 12th RE group?
jue
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.
> > 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
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.
Ron Garret
<0a7976ea-11f8-4fe2...@u9g2000yqb.googlegroups.com>,
ccc31807 <cart...@gmail.com> wrote:
> On Mar 10, 12:45 pm, Ron Garret <rNOSPA...@flownet.com> wrote:
> > 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.
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
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
Tamas K Papp
> On Mar 10, 11:03 am, Tamas K Papp <tkp...@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
I have read your post and understood it, but I am not really
interested in getting into meta-discussions.
>> >> 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.
So when you said "ignoring the horribleness and the abominable in
another language because you do understand it", what another language
were you referring to? Perl, CL, or something else?
> 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.
When you made a statement about "ignoring the horribleness and the
abominable in another language", I thought you meant Common Lisp. Did
you mean Perl?
Tamas
Ron Garret
<ce68ccd0-22e2-472d...@y11g2000yqh.googlegroups.com>,
ccc31807 <cart...@gmail.com> wrote:
> > 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?
Why must those be the only possibilities? It was because the Perl code,
which had been working fine for months, suddenly started failing
silently and intermittently, and I was told there was no way to do the
equivalent of wrapping the whole script in the equivalent of a
TRY...EXCEPT form in order to catch the error. Whether this was in fact
true or whether the entire engineering team was incompetent I do not
know. But they seemed pretty bright and capable otherwise, so it would
be pretty odd for them all to be mistaken about this.
rg
Ron Garret
Tad McClellan <ta...@seesig.invalid> wrote:
> ["Followup-To:" header set to comp.lang.perl.misc.]
>
> Ron Garret <rNOS...@flownet.com> wrote:
> > In article <a4ofp5p0026pmis1a...@4ax.com>,
> > J?rgen Exner <jurg...@hotmail.com> wrote:
> >
> >> Ron Garret <rNOS...@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?
>
>
> Nothing, but it does go a long way in supporting your point
> about punctuation being hard to read correctly. :-)
Exactly.
rg
Ron Garret
J?rgen Exner <jurg...@hotmail.com> wrote:
> >> > 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.
>
> 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?
Yes. Exactly.
> >> > What is /\d/?
> >>
> >> perldoc perlre:
> >
> >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 how am I supposed to know that if I don't know Perl?
> >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.
Yeah. That would really suck. What would I do for fun?
> [...]
> >> >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?
>
> 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?
No. Of course not. Don't be ridiculous.
> Typing is an aid to the programmer to avoid errors by inadvertently
> using incompatible data types.
Typing *would* be an aid to the programmer if Perl actually prevented
you from using incompatible types. But it doesn't, e.g.:
print "a" + "b";
Defensible results include producing an error or outputting "ab". But
not outputting 0, which is what it actually does.
And while I'm at it:
%x=123;
print %x;
Shouldn't that be an error? It isn't. It prints 123. So does this:
@x=123;
print @x;
This is actually legal perl program:
print $(,$);
There are dozens and dozens of these obscure punctuational shortcuts:
$], $@, %!, $:, $^, %-, $^P, @F, @_, it goes on and on.
I'm sorry, but this makes my skin crawl.
rg
ccc31807
> > 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.
>
> So when you said "ignoring the horribleness and the abominable in
> another language because you do understand it", what another language
> were you referring to? Perl, CL, or something else?
I used the same words that RG used, which were, and I quote: "Perl is
just an ... abomination through-and-through. ... It was just
horrible." I wasn't referring to any particular language, but to the
descriptive lwords used. You might make a credible case that a
particular language is horrible, and support your argument with logic
and specific examples, but RG did not seem to do so. Instead, he
seemed to be making his argument from simple prejudice and ignorance.
I was pretty specific in stating that you can't judge a language
without knowing something of the substance of the language, and quite
frankly, I'm at a loss to see how you missed the main point.
> When you made a statement about "ignoring the horribleness and the
> abominable in another language", I thought you meant Common Lisp. Did
> you mean Perl?
I didn't mean ANY particular language -- I meant the process of
characterizing a language the way RG did based on reading a few
chapters of an anonymous book. In the same way, I took it as fact that
someone who expresses prejudice AGAINST something would also express
prejudice TOWARD something else based on familiarity.
Over the years, I've had some interaction with students and graduates
of business and management departments of colleges and universities.
These departments have IS or MIS majors and programs, and they
typically use Microsoft technologies, such as Windows and Visual
Basic. As a result of their indoctrination, they sometimes believe
that Visual Basic is the highest and best programming language, and
that all other languages are inferior. I have had one experience (not
personal, but vicarious) of a manager taking over a unit of a large
financial services firm and decreeing that from thenceforth all new
development would use Windows, and MS tools, and that all existing
processes would be converted. This notwithstanding the fact that the
cost per transaction of the existing processes (Unix based) was about
twenty percent of the cost of the existing MS units and that the
conversion would entail substantial costs.
WRT Perl, I agree that it's an ugly, convoluted, write once read never
language, but it's popular, and it's popular for a reason. It's
popular despite the fact that it's not taught in school, or in
extension classes, or is on anyone's official list of approved
technologies. Personally, I can tell you that it's a very good match
for my job, better than any language I've had personal experience with
(and I've studied and or learned about a dozen languages in my
career.) I'm also making an effort to learn CL and achieve some
proficiency in CL. My feeling so far is that CL is a more powerful
language than Perl but not as suited to my job.
Here's the point: Don't disparage a language before you know it, and
don't rely on ignorant bias to disparage a language.
CC.
Tad McClellan
Ron Garret <rNOS...@flownet.com> wrote:
> %x=123;
> print %x;
>
> Shouldn't that be an error?
And how are you supposed to know that if you don't know Perl?
(it does generate a warning, and all Real Perl Programmers enable warnings)
perl -we '%x=123; print %x;'
Would you think that printing 123 is reasonable if %x meant an array?
How do you know that it doesn't mean an array if you don't know Perl?
> It isn't. It prints 123. So does this:
>
> @x=123;
> print @x;
How do you know the percent-sign means anything different than at-sign?
Trying to understand a language (machine or human) that you do
not know is futile. You must either give up, or actually learn
the language.
Ben Morrow
Quoth ccc31807 <cart...@gmail.com>:
>
> WRT Perl, I agree that it's an ugly, convoluted, write once read never
> language,
No. No No No. *Your* Perl may be, but don't tarnish the rest of us with
the same brush. It's perfectly possible to write readable Perl; indeed,
IMHO, it's wasier to write readable Perl (with a little effort) than
most other languages.
> Here's the point: Don't disparage a language before you know it, and
> don't rely on ignorant bias to disparage a language.
The point you seem to be missing is that there *are* valid grounds for
calling Perl ugly. Ron Garret seems determined to miss them in favour of
complaining about too much punctuation, but they are there and they will
bite you hard if you stumble across one without knowing it's there. It
helps, in practice if not in theory, that the common convention of
function/Package/FILEHANDLE makes collision between those unlikely.
Ben
Ron Garret
<5a67c5c1-22a1-458e...@z11g2000yqz.googlegroups.com>,
ccc31807 <cart...@gmail.com> wrote:
> WRT Perl, I agree that it's an ugly, convoluted, write once read never
> language, but it's popular, and it's popular for a reason.
Sarah Palin is popular too.
rg
Tamas K Papp
> On Mar 10, 7:19 pm, Tamas K Papp <tkp...@gmail.com> wrote:
>
>> When you made a statement about "ignoring the horribleness and the
>> abominable in another language", I thought you meant Common Lisp. Did
>> you mean Perl?
>
> I didn't mean ANY particular language -- I meant the process of
> characterizing a language the way RG did based on reading a few chapters
> of an anonymous book. In the same way, I took it as fact that someone
That doesn't make sense. If somebody judges a language based on
insufficient information, they will be ignoring horribleness and
abominations in another one? Do I need some kind of hallucinogen to
understand this reasoning?
> Here's the point: Don't disparage a language before you know it, and
> don't rely on ignorant bias to disparage a language.
A truly deep point. I guess people didn't know this before.
I humbly offer the following pieces of advice, equally profound and
relevant to these newsgroups (but slightly more general):
It never rains but it pours.
A watched pot never boils.
Regards,
Tamas
Tim X
> On Wed, 10 Mar 2010 07:01:14 -0800, ccc31807 wrote:
>
>
> Your post actually highlights some similarities between Perl and CL:
I thought that was part of his point. i.e. the differences are largely
just differences of syntactic sugar and that criticising one for being
'horrible' when you don't understand its type of refined sugar while
ignoring aspects of the sugar you are familiar with that could be just
as easily abused or confusing to the uninitiated was illlogical and
meaningless.
> 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.
>
Flamewar? I thought it was a reasonably thought out and argued response.
Unlike RG's original comments on perl, the gist I got from the post was
in fact anti-flamewar i.e. that the differences were really about
differences in familiarity and that claiming one is better than the
other is pretty pointless. If anything, it was the more rational and
balanced assessment compared to RG's original comment.
For the record, I find a lot about perl I don't like, especially with
respect to its syntax and somewhat inconsistent behavior in certain
areas. I much prefer CLs simpler and far more consistent approach. I
disagree with Perl's philosophy of allowing everyone to do it 'their
way' and anyone who has worked with perl on either a project with many
develoers or maintaining code written by many different authors will
know what I'm getting at. However, I've also frequently come across
problems that are much easier to solve with perl than they are with CL.
In fact, I ran into one just recently. I had to do some work with a
system that makes extensive use of Oracle and Oracle stored procedures.
I wanted to use CL for the task. However, after many many hours of
searching and trying out various CL interfaces to Oracle, I had to give
up because I could not find one single CL to Oracle library that would
allow you to work with stored procedures and ref cursors. Plenty, like clsql and Clisps
Oracle DB extension would allow you to do basic SQL queries, but none
would allow you to call a stored procedure and have access to all Oracle
parameter type (IN, OUT and IN OUT) or ref cursors (at least I couldn't
work it out from the docs or source code or experimentation).
After many many days of installing various libs, which in itself was
often painful, going through lots of docs, many of which were outdated,
incomplete or poorly written and even having compiled clisp extensions
etc, I had to give up.
I turned to perl. In less than half a day, I had things working via
Perl's DBI interface using the DBD::Oracle driver. Installation was
rediculously simple - essentially starting the perl CPAN shell and
asking it to install DBI and DBD::Oracle and it came with extensive and
well written comprehensive documentation. In half a day I had all the
tools working ans was able to concentrate on the problem I wanted to
work on rather than tyring to just get an environment that would let me
even start.
I'd prefer to be working with CL, but taht wasn't possible. Arguements
regarding which language is better or more powerful at a theoretical
level become pointless if you cannot use it to solve a real world
problem. This type of issue gets raised in this group frequently and the
general response is to attack the poster and become extremely defensive,
making all sorts of wild claims about CLs power and the ease at which
you can implement a library etc. However, the reality is that for many
problems, CL is not a good choice because it lacks the user base of
other languages such as perl and therefore lacks the extensive
repository of working useful libs that give the productive edge you need
to survive in the commercial world.
If, on the other hand, I want to experiment with some ideas or write
some software for pleasure or do something where I have the luxury of
time etc, I will likely use CL because it is one of the languages I
really enjoy programming in and which frustrates me less. It is
frequently the language I'll turn to if I want to try out something
unusual or a bit left of field where I don't want the preconceptions of
Larry, Gido or Matz getting in my way. However, if I want to get paid
for solving a problem and want to get a reasonable hourly rate, I'm
afraid CL will seldom be my first choice because I cannot rely on basic
library functionality being available and I don't ahve time to write
everyhting from scratch.
We probably need tobe a little less sensitive regarding criticisms of
CL. Sometimes, they are valid and we should listen and learn.
Tim
P.S. If anyone knows of a CL library that will allow me to interact with
an Oracle database AND allow me to call stored procedures, passing data
in both directions and access ref cursors, *PLEASE* let me know - I
would still prefer to use CL for these jobs over perl.
--
tcross (at) rapttech dot com dot au
Alessio Stalla
>
> P.S. If anyone knows of a CL library that will allow me to interact with
> an Oracle database AND allow me to call stored procedures, passing data
> in both directions and access ref cursors, *PLEASE* let me know - I
> would still prefer to use CL for these jobs over perl.
If it's a viable option for you, you could use ABCL on the JVM and use
Oracle's JDBC driver.
Alessio
Tim X
Yes, I was thinking about that as a possible option. Don't know anything
about ABCL and was hoping to stick with a familiar ANSI implementation
such as SBCL or even CLISP. Don't know anything about the
interface/mapping between ABCL and java libs and wsn't sure if I was
going that route whether I would be better off just jumping into clojure
as I've been thinking about finding some project to try it out.
Is there much that would take getting accustomed to in ABCL that may
feel 'foreign' and how ANSI compliant is it?
thanks,
Tim
thanks for the suggestion
Tim
ccc31807
> > WRT Perl, I agree that it's an ugly, convoluted, write once read never
> > language,
>
> No. No No No. *Your* Perl may be, but don't tarnish the rest of us with
> the same brush. It's perfectly possible to write readable Perl; indeed,
> IMHO, it's wasier to write readable Perl (with a little effort) than
> most other languages.
Ben, I like Perl a lot, and I've developed enough proficiency in Perl
to do useful work and earn a living with it. I said this with my
tongue partly in my cheek, and without meaning to give reasons for
avoiding it. People can consider Perl ugly with all the punctuation
characters, just as Larry Wall can consider Lisp ugly with all the
parens (his remark about Lisp looking like oatmeal with finger nail
clippings.)
The OO and reference hacks are also convoluted, with arrays and hashes
only holding scalar values. This caused the convoluted assignment
statements which you objected to, i.e., $hash{$anotherhash{$k}{'key}}
('realkey'}. If you keep your data structures in mind, it's easy to
write these references without thinking, but hard to read them when
the data structures are out of mind.
In the thread on c.l.l. ("another frustrating learner question, CLOS")
I wrote a fairly extended defense of REs, which was the original point
of RG's complaint about Perl. REs are also ugly, convoluted, and write
once read never bits of code, but they can also be beautiful, elegant,
and perfectly lucid bits of code as well, and at the same time, too.
This is one of the mysteries of life which we might as well accept, as
we can do nothing to change it.
CC.
Ben Morrow
don't care about Perl style issues.]
Quoth ccc31807 <cart...@gmail.com>:
> On Mar 10, 11:47 pm, Ben Morrow <b...@morrow.me.uk> wrote:
> > > WRT Perl, I agree that it's an ugly, convoluted, write once read never
> > > language,
> >
> > No. No No No. *Your* Perl may be, but don't tarnish the rest of us with
> > the same brush. It's perfectly possible to write readable Perl; indeed,
> > IMHO, it's wasier to write readable Perl (with a little effort) than
> > most other languages.
>
> Ben, I like Perl a lot, and I've developed enough proficiency in Perl
> to do useful work and earn a living with it. I said this with my
> tongue partly in my cheek,
Please don't do that. There are already far too many people who think
the biggest and only problem with Perl is 'too much punctuation'; don't
encourage more.
> and without meaning to give reasons for
> avoiding it. People can consider Perl ugly with all the punctuation
> characters, just as Larry Wall can consider Lisp ugly with all the
> parens (his remark about Lisp looking like oatmeal with finger nail
> clippings.)
Both of these are *almost entirely irrelevant*. (Larry knows this, of
course, and was almost certainly actually talking about Lisp's lack of
syntactic clues, rather than the specific punctuation used.) Lisp is
beautiful in a way Perl is not at a level where the details of syntax
are unimportant.
> The OO and reference hacks are also convoluted, with arrays and hashes
> only holding scalar values. This caused the convoluted assignment
> statements which you objected to, i.e., $hash{$anotherhash{$k}{'key}}
> ('realkey'}. If you keep your data structures in mind, it's easy to
> write these references without thinking, but hard to read them when
> the data structures are out of mind.
No, nothing in Perl's reference model caused that bit of unreadable
code, only your unwillingness to understand DRY. If you take a language
like JavaScript with a much simpler model (everything is an object,
including arrays, so arrays can hold arrays 'directly'), you still end
up with
if (/\d/.test(sec[k].xlist) {
fac[sec[k].id1].location = sec[k].site;
}
else if (sec[k].xlist == sec[k].site) {
fac[sec[k].id1].location = sec[k].site;
}
else {
fac[sec[k].id1].location = sec[sec[k].xlist].site;
}
which, while it is a litle 'quieter' (though your original had too much
superflous punctuation for my taste) is no easier to read. The awkward
nested deref is still there, as is the repetition of sec[k].id1 and
sec[k].xlist and the .location and .site derefs. Factor those out, the
way I showed you, and suddenly the Perl is perfectly readable too. (I
realise at this point I made a mistake in my original correction. I
blame it on the appalling layout.)
> In the thread on c.l.l. ("another frustrating learner question, CLOS")
> I wrote a fairly extended defense of REs, which was the original point
> of RG's complaint about Perl. REs are also ugly, convoluted, and write
> once read never bits of code, but they can also be beautiful, elegant,
> and perfectly lucid bits of code as well, and at the same time, too.
No. Anything 'write once read never' is not 'perfectly lucid' by
definition. It's possible to write clear regexen--Perl's syntax is
better for this than most others--but it's also possible to make a
horrid mess trying to parse something you shoudl use a proper parser
for. The two do not overlap.
Ben
Tad McClellan
But she's not a "fat, ugly, old bitch". :-)
Alessio Stalla
> Alessio Stalla <alessiosta...@gmail.com> writes:
> > On Mar 11, 8:32 am, Tim X <t...@nospam.dev.null> wrote:
>
> >> P.S. If anyone knows of a CL library that will allow me to interact with
> >> an Oracle database AND allow me to call stored procedures, passing data
> >> in both directions and access ref cursors, *PLEASE* let me know - I
> >> would still prefer to use CL for these jobs over perl.
>
> > If it's a viable option for you, you could use ABCL on the JVM and use
> > Oracle's JDBC driver.
>
> Yes, I was thinking about that as a possible option. Don't know anything
> about ABCL and was hoping to stick with a familiar ANSI implementation
> such as SBCL or even CLISP. Don't know anything about the
> interface/mapping between ABCL and java libs and wsn't sure if I was
> going that route whether I would be better off just jumping into clojure
> as I've been thinking about finding some project to try it out.
The Java access API is derived from ACL's jlinker (http://
www.franz.com/support/documentation/current/doc/jlinker.htm). The
notable differences are:
- ACL's API assumes the JVM is a different process, while ABCL runs in-
process, so it lacks all the functions for managing the connection
with the JVM; and
- ABCL's API has the option to be a bit less verbose, letting ABCL
choose automatically the method to call from the argument types, at
the cost of a runtime performance hit. For example: (jcall (jmethod
"java.lang.Comparable" "compareTo" "java.lang.Object") instance obj)
vs (jcall "compareTo" instance obj). There's also the JSS library
maintained by Alan Ruttenberg which is even less verbose, has more
features and is more efficient (wrt ABCL's abbreviated API).
> Is there much that would take getting accustomed to in ABCL that may
> feel 'foreign' and how ANSI compliant is it?
It is mostly ANSI compliant; it lacks the long form of define-method-
combination and fails 30-something tests from the GCL ANSI test suite
(IIRC 21k+ tests).
Compared to other, more mature implementations with a larger user
base, it lacks a number of things that are usually taken for granted;
for example, the MOP is incomplete, the debugger could be improved in
many ways (e.g. it doesn't show local variable information), the
compiler doesn't use type information very much, etc.
Oh, and it's the only CL implementation I know of where = fixnums are
not always EQ, due to boxing imposed by the JVM.
hth,
Alessio
Martijn Lievaart
> Why must those be the only possibilities? It was because the Perl code,
> which had been working fine for months, suddenly started failing
> silently and intermittently, and I was told there was no way to do the
> equivalent of wrapping the whole script in the equivalent of a
> TRY...EXCEPT form in order to catch the error. Whether this was in fact
> true or whether the entire engineering team was incompetent I do not
> know. But they seemed pretty bright and capable otherwise, so it would
> be pretty odd for them all to be mistaken about this.
If they didn't know about eval { original code here };, they were
incompetent. But there were probably other factors at work you didn't
tell about.
M4
Peter J. Holzer
> Most of what I have to say about this has already been said by other
> nonetheless.
>
><19c5b00d-c1e0-4016...@g19g2000yqe.googlegroups.com>,
> ccc31807 <cart...@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.
[long fullquote deleted - please quote only the parts necessary for
context]
>> 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.
Agreed.
> 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.
I don't think so. It doesn't meet your aesthetic criteria, but it is a
powerful programming language which can be used to write everything from
simple throwaway scripts to large, complex software systems, in a
readable, testable, maintainable way.
It is true that the syntax is rather complex - probably one of the most
complex ones in popular programming languages. This is intentional:
Firstly, because Larry tried to throw all the good bits from lots of
programming languages in (when I first encountered Perl I called it
"the PL/1 of nineties"), and partly because he modelled it after natural
languages, so like natural languages it has a complex, irregular,
context-sensitive syntax with lots of shortcuts. He probably went too
far - Perl syntax could be cleaner and less visually cluttered without
losing expressivity.
Lisp is the opposite - it has an extremely minimalistic syntax, and for my
taste it goes too far in the direction of simplicity and purity. A lisp
program may be easy to read for a lisp compiler, but it isn't easy to
read for me. I need more visual structure.
> 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.)
Well, all of these are described in perldoc, so I don't understand why
reading 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.
That doesn't necessarily make the language easier to learn or read.
On the contrary, I think lisp offers too few visual clues - everything
looks the same to me. (but then I've never used lisp in anger, so in
part this is simply because I'm not used to it)
> 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.
While Carter's code wasn't specifically designed to be pathological it
was pretty bad, too.
But how would the same code look in well-written Lisp? (Ben already
showed well-written Perl).
>> 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.
Right. It doesn't do that but for a completely different reason:
The sigil has (almost) nothing to do with the variable's data type.
Instead it is an article, like in many European languages.
English is a bad example, because it has only one definite article
(the), so let's use Italian:
il - singular male
la - singular female
i - plural male
le - plural female
Gender doesn't have any meaning in Perl, but we can distinguish between
singular ($) and plural. And there are two types of plural - ordered
(lists, arrays: @) and unordered (hashes: %).
So $ denotes singular:
$ x - one x
$ a[2] - one element (with index 2) of the array a
$ h{'k'} - one element (with key 'k') of the hash h
@ denotes an ordered plural:
@ a - the whole array a
@ h{'a', 'c', 'b'} - the elements with keys 'a', 'c', 'b' of hash h, in
that order.
% denotes an unordered plural:
% h - the whole hash h
Note that I have used $ with a scalar variable, an array variable and a
hash variable and I have used @ with both an array variable and a hash
variable. So they clearly don't "indicate the type of the variable".
I have written a space after the sigil to emphasize that it is a "word"
in Perl's grammar and not a part of the variable name. Normally you omit
the space.
(Side note: Sigils are used differently in Perl6)
> It distinguishes between scalars, lists, and hash tables,
Yes, but in a different way than you seem to think. Also, these three
are rather fundamentally different (although awk and JavaScript seem to
think that hashes and arrays are the same thing).
> but not between integers, floats, and strings.
Right. It doesn't do that. Should it? From a performance POV maybe - a
4byte int takes a lot less memory than a perl scalar value. But from a
correctness POV using representative types doesn't buy you much - you
may represent both the area of your living room and the milage of your
car as a floating point number but that doesn't mean that the sum of
both makes any sense. For that you need a much more strict type model.
> It distinguishes between strings and regular expressions,
No, not really. At least not any more than it distinguishes between
numbers and strings. And that distinction is relatively recent.
> but not between strings and code.
Huh? Yes, it does. You can compile a string into code, but you'll have
to do that explicitely.
> It has all kinds of weird punctuationy things that you can't look up,
> like $@ and !~ and <>.
Of course you can look them up. All of them are documented and the Perl
docs aren't that bad (although I agree that they could be better). You
can't use google to search for them, but the same is true for any
keyword or variable name which happens to be a common English word
(although for opposite reasons).
> It fails silently where it should produce errors.
That's debatable. Perl is in the C tradition of returning an error value
instead of throwing an exception, but that is only "silent" if the
Programmer carelessly ignores the return value.
> 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.
"Universally accepted" is rather strong given that most shells, most
templating languages and many scripting languages use a similar
expansion mechanism.
The expansion mechanism in Perl has a few shortcomings, but the fact
that Perl has such a mechanism is a feature, not a bug. Apart from a few
pathological examples like the one above, simply embedding variables or
(very) simple expressions in a string is less cluttered and easier to
read then constructing the string with concatenation operators or
formatting functions. And Perl *does* have simple strings, you know.
hp
Peter J. Holzer
Well, they were wrong, but Perl doesn't throw exceptions silently. When
a Perl program dies, you get a message telling you exactly where and
why.
So when the program "failed silently and intermittently" there was
probably some error in the program logic which caused it to exit
prematurely. Wrapping the whole script in eval{} doesn't help here
because no exception is thrown. You'll have to analyze the logic flow of
the program to find that - I don't think that's any different in lisp
(yes, lisp is (or was) very popular in AI research, but automatically
finding logical errors in programs is still an unsolved problem, AFAIK).
Perl comes with a simple framework for unit tests. And because it comes
with Perl and is so simple to use, it is very common for Perl
programmers to write tests. There are also various ways to trace program
execution (from simple print statements to log4perl to smart comments to
running the whole thing in the debugger).
If your colleagues didn't use the tools they had and just said "it
doesn't work and we don't know why and can't find out" I'd call them
incompetent. But I don't know what they did, so I won't.
In any case I very much doubt that it is much easier to find the bug in
a lisp program which "suddenly started failing silently and
intermittently" than in a Perl program which does the same.
hp
Peter J. Holzer
> 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.
>
> 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,
Now I'm curious: How is Perl's syntax for multi-level data structures
awkward? Which language does it in a less awkward way? I'd like to see
your code snippet translated into a "less awkward" language.
(I do find the dereferencing of array and hash refs awkward, but you
didn't use that here)
hp
Peter J. Holzer
> Jürgen Exner <jurg...@hotmail.com> writes:
>> ccc31807 <cart...@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 started with BASIC (think early 1980's here - line numbers and goto),
then did a little bit of Pascal and assembly (6502 and Z80) before
learning C. Seeing the similarities between assembly and C has been a
real eye opener for me - suddenly I understood Pascal pointers (which
even more restrictive than Perl references).
> 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.
Actually, C pointers are quite ok in theory (for example, you can't make
a pointer into an array point outside of the array (except "just after"
it). The problem is that (almost) all C compilers omit the necessary
run-time checks for performance reasons and because of binary
compatibility constraints (you would need "fat pointers" to implement
them).
> That, and a better standard library.
Yup. That one is very haphazard and seriously dated.
> Disclaimer: haven't programmed in C for a while.
Me, too.
hp
Peter J. Holzer
> John Bokma <jo...@castleamber.com> wrote:
>>J�rgen Exner <jurg...@hotmail.com> writes:
>>> ccc31807 <cart...@gmail.com> wrote:
>>>>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.
>
>
> 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.
That and they had to fit the compiler into 64k of memory. And it had to
finish in a reasonable time on a PDP-11. That somewhat limits what you
can do even if you know how to write a better language in theory.
(I do remember the MFII COBOL compiler on an 8086 - compiling our
program took half an hour)
> For its time it was a great concept and
> implementation. It's just that it is way outdated 40 years later.
Yup.
>>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.
Pascal is older than C. And its pointers are (were?) particularly useless.
Modula-2 was actually quite nice. One can see that Wirth used it to
write real code and not just for teaching :-).
hp
John Bokma
> On 2010-03-10 20:54, John Bokma <jo...@castleamber.com> wrote:
[..]
> I started with BASIC (think early 1980's here - line numbers and
> goto),
ZX Spectrum, 1983 here
> then did a little bit of Pascal and assembly (6502 and Z80) before
More or less same here, Z80, Comal, Pascal, 6800, 6809, 68000 ...
>> 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.
>
> Actually, C pointers are quite ok in theory (for example, you can't make
> a pointer into an array point outside of the array (except "just after"
> it).
How does C prevent this? Or I don't understand what a pointer into an
array is.
--
John Bokma j3b
Hacking & Hiking in Mexico - http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development
Ron Garret
"Peter J. Holzer" <hjp-u...@hjp.at> wrote:
> In any case I very much doubt that it is much easier to find the bug in
> a lisp program which "suddenly started failing silently and
> intermittently" than in a Perl program which does the same.
I assure you, you are quite mistaken. I have a first-hand data point on
that as well:
http://ti.arc.nasa.gov/m/pub/archive/2000-0176.pdf
rg
Ron Garret
Martijn Lievaart <m...@rtij.nl.invlalid> wrote:
I'm sure there were. But it's not that I'm holding out on you, it's
that I never fully understood the details even at the time.
rg
Nick Keighley
> Actually C pointers are probably among the worst concepts ever invented
> in computer science.
now there's a challenge. Who are the other competitors?
- FORTRAN computed goto
- FORTRAN fixed layout
- Algol-60 free layout
- Algol-60 call by name
- Pascal with
- C declaration syntax
- C++ template syntax
- C++ exception specification
- PL/I
Mario S. Mommer
I miss
- FORTRAN common blocks
from that list. And with respect to C++ templates - well, the syntax
isn't really the worst part.
Mario.
Frank Seitz
The classical Perl FILEHANDLE
Frank
--
Dipl.-Inform. Frank Seitz
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
Blog: http://www.fseitz.de/blog
XING-Profil: http://www.xing.com/profile/Frank_Seitz2
John Bokma
Frank Seitz
> Nick Keighley <nick_keigh...@hotmail.com> writes:
>> On 10 Mar, 20:39, Jürgen Exner <jurge...@hotmail.com> wrote:
>>>
>>> Actually C pointers are probably among the worst concepts ever invented
>>> in computer science.
>> now there's a challenge. Who are the other competitors?
>>
>> - FORTRAN computed goto
>> - FORTRAN fixed layout
>> - Algol-60 free layout
>> - Algol-60 call by name
>> - Pascal with
>> - C declaration syntax
>> - C++ template syntax
>> - C++ exception specification
>> - PL/I
>
> PHP
> XHTML
What is wrong with XHTML?
John Bokma
> John Bokma wrote:
>> Nick Keighley <nick_keigh...@hotmail.com> writes:
>>> On 10 Mar, 20:39, Jürgen Exner <jurge...@hotmail.com> wrote:
>>>>
>>>> Actually C pointers are probably among the worst concepts ever invented
>>>> in computer science.
>>> now there's a challenge. Who are the other competitors?
>>>
>>> - FORTRAN computed goto
>>> - FORTRAN fixed layout
>>> - Algol-60 free layout
>>> - Algol-60 call by name
>>> - Pascal with
>>> - C declaration syntax
>>> - C++ template syntax
>>> - C++ exception specification
>>> - PL/I
>>
>> PHP
>> XHTML
>
> What is wrong with XHTML?
People seem to have a hard time to get it right. Thankfully, browsers
are forgiving: they work around not-well-formed XHTML, which is contrary
to what XML stands for.
Maybe XML should've been on that list as well. It has enough warts which
is funny for such a simple language.
bugbear
> 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.
> in computer science.
Was 'C' invented to be a "great" language, or was it
just a compromise - easier (and more portable) than
assembler, but still low level enough that a
compiler of the era
could generate decent code?
These days, it's quite common to see 'C' categorised
as a portable assembly language.
Which may be a Good Thing, of course.
BugBear
Pascal J. Bourguignon
> "Peter J. Holzer" <hjp-u...@hjp.at> writes:
>
>> On 2010-03-10 20:54, John Bokma <jo...@castleamber.com> wrote:
>
> [..]
>
>> I started with BASIC (think early 1980's here - line numbers and
>> goto),
>
> ZX Spectrum, 1983 here
>
>> then did a little bit of Pascal and assembly (6502 and Z80) before
>
> More or less same here, Z80, Comal, Pascal, 6800, 6809, 68000 ...
>
>>> 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.
>>
>> Actually, C pointers are quite ok in theory (for example, you can't make
>> a pointer into an array point outside of the array (except "just after"
>> it).
>
> How does C prevent this? Or I don't understand what a pointer into an
> array is.
Well, since C is weakly-to-not typed, you cannot enforce it at the
variable site, however, it is specified indeed that it is invalid or
undefined to derefer a pointer that doesn't point to allocated memory,
and to compare pointers that don't point to elements of the same array
or one beyond. This can be enforced by heavy pointers and run-time
checks. Of course, since they prefer to have their results fast than
correct, this is rarely enforced.
One way is to define pointers as:
typedef struct {
address arrayBase;
int elementSize;
int elementCount;
int index;
} Pointer;
Pointer NULL={0,0,0,0};
void Pointer_incr(Pointer* p){
if(p.index<p.elementCount){
p.index++;
}else{
error("Trying to increment a pointer out of bounds"); }}
void Pointer_decr(Pointer* p){
if(0<p.index){
p.index--;
}else{
error("Trying to decrement a pointer out of bounds"); }}
int Pointer_minus(Pointer p,Pointer q){
if(p.arrayBase!=q.arrayBase){
error("Incompatible pointers");
}else{
return(p.index-q.index); }}
bool Pointer_equalp(Pointer p,Pointer q){ return(Pointer_minus(p,q)==0); }
bool Pointer_lessp (Pointer p,Pointer q){ return(Pointer_minus(p,q)<0); }
T Pointer_deref(Type T,Pointer p){
if(p.index<p.elementCount){
return(deref(T,p.arrayBase+p.index));
}else{
error("Trying to dereference out of bound pointer."); }}
char a;
char b;
int c[10];
int d[10];
char* p1=&a; /* <=> p1.arraybase=address_of(a);
p1.elementSize=1;
p1.elementCount=1;
p1.index=0; */
char* p2=&b; /* <=> p2.arraybase=address_of(b);
p2.elementSize=1;
p2.elementCount=1;
p2.index=0; */
int* p3=&c; /* <=> p3.arraybase=address_of(c);
p3.elementSize=sizeof(int);
p3.elementCount=10;
p3.index=0; */
int* p4=&(d[9]); /* <=> p4.arraybase=address_of(d);
p4.elementSize=sizeof(int);
p4.elementCount=10;
p4.index=9; */
int* p5=&d; /* <=> p5.arraybase=address_of(d);
p5.elementSize=sizeof(int);
p5.elementCount=10;
p5.index=9; */
char* n=NULL;
p2++; /* <=> Pointer_incr(&p2); */
p3++; /* <=> Pointer_incr(&p3); */
p1==p2; /* <=> Pointer_equalp(p1,p2); <=> error */
p3<p4; /* <=> Pointer_lessp(p3,p4); <=> error */
p4<p5; /* <=> Pointer_lessp(p5,p4); returns false. */
*p4=*p5; /* <=> copies the int from d[0] to d[9]. */
*n=0; /* <=> error (dereferencing NULL) */
--
__Pascal Bourguignon__
Paul Wallich
> Nick Keighley <nick_keigh...@hotmail.com> writes:
>> On 10 Mar, 20:39, Jürgen Exner <jurge...@hotmail.com> wrote:
>>
>>> Actually C pointers are probably among the worst concepts ever invented
>>> in computer science.
>> now there's a challenge. Who are the other competitors?
>>
>> - FORTRAN computed goto
>> - FORTRAN fixed layout
>> - Algol-60 free layout
>> - Algol-60 call by name
>> - Pascal with
>> - C declaration syntax
>> - C++ template syntax
>> - C++ exception specification
>> - PL/I
>
> I miss
>
> - FORTRAN common blocks
But pointers, common blocks and computed goto (don't know the others
well enough) aren't really computer science, are they? They pretty much
predate any principled study of how languages should be put together,
back in a time when getting any compiler at all to run was a big deal.
Complaining about them is sort of like complaining about the irregular
edges of stone tools.
paul
Philip Potter
> "Peter J. Holzer" <hjp-u...@hjp.at> writes:
>> Actually, C pointers are quite ok in theory (for example, you can't make
>> a pointer into an array point outside of the array (except "just after"
>> it).
>
> How does C prevent this? Or I don't understand what a pointer into an
> array is.
C *doesn't* prevent it. If you have a pointer to a member of an array,
which you keep iterating with p++ until it goes well beyond the end, the
behaviour is undefined. That means that *no matter what* the compiler
and resulting program does, it's a valid implementation of the C
Standard. It is certainly not required that a C compiler checks that you
don't do something stupid like this.
http://catb.org/jargon/html/N/nasal-demons.html
Phil
Philip Potter
COME FROM.
Jürgen Exner
>These days, it's quite common to see 'C' categorised
>as a portable assembly language.
Absolutely. I have worked on compilers, which generated C-code as the
target output. And C is working very nicely for that purpose.
jue
Martijn Lievaart
- All of COBOL and especially COBOL74 and earlier.
- Command.com batch language (and to a lesser degree cmd.exe batch
language)
- Java's resource managing techniques (or rather, lack of).
- C++'s automagical creation of copy constructors and assignment operators
Do we have to restrict it to programming languages? Otherwise I know a
few others:
- DOS drive letters
- Unix access control
- ActiveX as used originally, download and execute from any site when
requested.
- Original Mac autorun feature
- Borland technical support
OK, maybe not computer science. Certainly not rocket science :-)
M4
Pascal J. Bourguignon
#include <iostream>
template <int N> struct Factorial {
enum { value = N*Factorial<N-1>::value };
};
template <> struct Factorial<1> {
enum { value = 1 };
};
int main()
const int f15=Factorial<15>::value;
std::cout << f15 << std::endl;
return 0;
}
I lose track of the count of syntactic irregularities...
But you're right, it's not the worst part:
-*- mode: compilation; default-directory: "/tmp/" -*-
Compilation started at Fri Mar 12 20:19:03
SRC="/tmp/f.c++" ; EXE="f" ; g++ -I. -L. -g3 -ggdb3 -o ${EXE} ${SRC} && ./${EXE} && echo status = $?
/tmp/f.c++: In instantiation of 'Factorial<13>':
/tmp/f.c++:4: instantiated from 'Factorial<14>'
/tmp/f.c++:4: instantiated from 'Factorial<15>'
/tmp/f.c++:12: instantiated from here
/tmp/f.c++:4: warning: integer overflow in expression
/tmp/f.c++: In instantiation of 'Factorial<14>':
/tmp/f.c++:4: instantiated from 'Factorial<15>'
/tmp/f.c++:12: instantiated from here
/tmp/f.c++:4: warning: integer overflow in expression
/tmp/f.c++: In instantiation of 'Factorial<15>':
/tmp/f.c++:12: instantiated from here
/tmp/f.c++:4: warning: integer overflow in expression
2004310016
status = 0
Compilation finished at Fri Mar 12 20:19:04
vs.
(defun fact (n) (if (= 1 n) 1 (* n (fact (- n 1)))))
(defmacro factorial (n) (fact n))
(defun main ()
(let ((f15 (factorial 15)))
(print f15)
0))
(main)
1307674368000
0
--
__Pascal Bourguignon__
Peter J. Holzer
> "Peter J. Holzer" <hjp-u...@hjp.at> writes:
>> On 2010-03-10 20:54, John Bokma <jo...@castleamber.com> wrote:
>>> 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.
>>
>> Actually, C pointers are quite ok in theory (for example, you can't make
>> a pointer into an array point outside of the array (except "just after"
>> it).
>
> How does C prevent this? Or I don't understand what a pointer into an
> array is.
>
You removed the next sentence where I wrote that it doesn't. It just
says "that's forbidden", but leaves to compiler complete freedom how to
deal (or not deal) with the situation. Most compilers (for the sake of
efficiency and compatibility with existing ABIs) assume that the
programmer never makes a mistake and produce code which will happily
scribble over neighbour variables. A very few however will produce code
which catches the error and raises an exception.
hp
Peter J. Holzer
Interesting paper.
But I don't think it proves your point.
1) Perl isn't mentioned at all, so you cannot draw any conclusions about
Perl from the paper (neither negative nor positive).
2) The verification tool mentioned doesn't work on Lisp input, but uses
a specialized modelling language called PROMELA. The authors state:
The modeling effort, i.e. obtaining a PROMELA model from the LISP
program, took about 12 man weeks during 6 calendar weeks, while the
verification effort took about one week. The modeling effort
consisted conceptually of an abstraction activity combined with a
translation activity. Abstraction was needed to cut down the program
to one with a reasonably small finite state space, making model
checking tractable. Translation, from LISP to PROMELA, was needed to
obtain a PROMELA model that the SPIN model checker could analyze.
[...]
The translation phase was non-trivial and time consuming due to the
relative expressive power of LISP when compared with PROMELA.
Spending 12 man-weeks hand-translating Lisp to PROMELA doesn't
exactly sound like it's easy - in fact the authors explicitely called
the task "non-trivial".
3) Then the authors built an automated translation tool, but again it
doesn't translate Lisp to PROMELA, it translates (a subset of) Java
to PROMELA. So, again, they had to hand-translate Lisp to Java, which
could then be automatically processed. At least translating Lisp to
Java was very quick (two hours!) but that may be because
Some of us spotted the potential error situation because it
resembled the similar error we had found using SPIN in 1997[...]
and the subsequent
focus on the particular code fragment
The error is a text-book example of a race-condition, btw. It is
discussed in almost identical form in any systems programming class,
and they could have spotted it because of that and not just because
the encountered it before.
4) The RAX team found the error within 24 hours, the JPF team within
48 hours (but they also had identified the code fragment as
suspicious within 12 hours).
In conclusion, there is nothing in the paper which suggests that Lisp in
particularly easy to model. If anything, they seem to suggest that Java
is easy to model, although I suspect that "shrinking down" real world
Java programs to a manageable complexity is still non-trivial, even with
the help of their abstraction tool.
That two independent teams each found the race condition within less
than two days is impressive. That may be a hint that Lisp makes it
relatively easy to spot that kind of error. But without more knowledge
about the specific case and a direct comparison to other programming
languages it isn't conclusive.
hp
RG
"Peter J. Holzer" <hjp-u...@hjp.at> wrote:
> On 2010-03-12 05:04, Ron Garret <rNOS...@flownet.com> wrote:
> > In article <slrnhpisqf.i4...@hrunkner.hjp.at>,
> > "Peter J. Holzer" <hjp-u...@hjp.at> wrote:
> >
> >> In any case I very much doubt that it is much easier to find the bug in
> >> a lisp program which "suddenly started failing silently and
> >> intermittently" than in a Perl program which does the same.
> >
> > I assure you, you are quite mistaken. I have a first-hand data point on
> > that as well:
> >
> > http://ti.arc.nasa.gov/m/pub/archive/2000-0176.pdf
>
> Interesting paper.
>
> But I don't think it proves your point.
>
> 1) Perl isn't mentioned at all
So? I was responding to a claim you made about Lisp.
> so you cannot draw any conclusions about
> Perl from the paper (neither negative nor positive).
Not from that paper in isolation. But I cited that paper within a
conversational context. Do I need to review it for you?
> 2) The verification tool mentioned doesn't work on Lisp input, but uses
> a specialized modelling language called PROMELA.
That is completely beside the point. The relevant part of the paper is
section 2.3. It has nothing to do with Promela.
I didn't say it was conclusive, I said it was a data point.
But FWIW, there are sound theoretical reasons to believe that Lisp
programs are easier to debug than Perl programs, mainly because Lisp has
a REPL and Perl (normally) does not.
But I really don't feel like arguing about this. If you think it's
easier to debug Perl than Lisp then go for it.
rg
Peter J. Holzer
> In article <slrnhpt9hi.i...@hrunkner.hjp.at>,
> "Peter J. Holzer" <hjp-u...@hjp.at> wrote:
>> On 2010-03-12 05:04, Ron Garret <rNOS...@flownet.com> wrote:
>> > In article <slrnhpisqf.i4...@hrunkner.hjp.at>,
>> > "Peter J. Holzer" <hjp-u...@hjp.at> wrote:
>> >> In any case I very much doubt that it is much easier to find the bug in
>> >> a lisp program which "suddenly started failing silently and
>> >> intermittently" than in a Perl program which does the same.
>> >
>> > I assure you, you are quite mistaken. I have a first-hand data point on
>> > that as well:
>> >
>> > http://ti.arc.nasa.gov/m/pub/archive/2000-0176.pdf
>>
>> Interesting paper.
>>
>> But I don't think it proves your point.
>>
>> 1) Perl isn't mentioned at all
>
> So? I was responding to a claim you made about Lisp.
I made a claim about the relative merits of Lisp *and* Perl.
>> so you cannot draw any conclusions about
>> Perl from the paper (neither negative nor positive).
>
> Not from that paper in isolation. But I cited that paper within a
> conversational context. Do I need to review it for you?
I could use the same condescending tone you use, but I won't.
>> 2) The verification tool mentioned doesn't work on Lisp input, but uses
>> a specialized modelling language called PROMELA.
>
> That is completely beside the point. The relevant part of the paper is
> section 2.3. It has nothing to do with Promela.
You didn't say what the relevant part of the paper was. You should
expect that when you cite a paper as support of your claims that one
assumes that the topic of the paper has something to do with your claim.
However, I noticed section 2.3:
>> 4) The RAX team found the error within 24 hours, the JPF team within
>> 48 hours (but they also had identified the code fragment as
>> suspicious within 12 hours).
[...]
>> That two independent teams each found the race condition within less
>> than two days is impressive. That may be a hint that Lisp makes it
>> relatively easy to spot that kind of error. But without more knowledge
>> about the specific case and a direct comparison to other programming
>> languages it isn't conclusive.
>
> I didn't say it was conclusive, I said it was a data point.
But without knowing more about the case and a comparison to other
languages you really can't say whether finding the bug within a day was
fast or slow. I've found similar bugs in C programs within 5 minutes, so
I could claim that C is much easier to debug than Lisp (omitting the
important facts that the C programs where rather short (a few hundred
lines) and were written by students in a systems programming course
(so I expected race conditions and was specifically looking for them)).
> But FWIW, there are sound theoretical reasons to believe that Lisp
> programs are easier to debug than Perl programs, mainly because Lisp has
> a REPL and Perl (normally) does not.
A REPL[1] doesn't help you much finding race conditions or bugs that cause
the program to "start failing silently and intermittently". So it is
moot for the two cases you mentioned. It can be very helpful in other
cases, though.
> But I really don't feel like arguing about this. If you think it's
> easier to debug Perl than Lisp then go for it.
I didn't say that Perl is easier to debug than Perl. I said I doubt that
Lisp is much easier to debug than Perl. There is a slight difference
which you should be able to spot.
hp
[1] The Perl module Devel::REPL is on the first page of Google results
when you search for "REPL".
RG
"Peter J. Holzer" <hjp-u...@hjp.at> wrote:
> I could use the same condescending tone you use, but I won't.
But then of course you do:
> I didn't say that Perl is easier to debug than Perl. I said I doubt that
> Lisp is much easier to debug than Perl. There is a slight difference
> which you should be able to spot.
Frustration can drive even the best among us to snarkiness.
Look, I understand what you were saying the first time you said it. But
I disagree with you: I think Lisp is easier to debug than Perl. I have
two data points and one theoretical argument to support my position, but
no hard proof. I might be wrong. But all the evidence I have at my
disposal indicates to me that I am not.
BTW, I disagree with this too:
> A REPL[1] doesn't help you much finding race conditions or bugs that cause
> the program to "start failing silently and intermittently".
A REPL can be very useful in debugging such problems. Having a REPL
aboard DS1 was invaluable in finding and fixing the RAX bug. And
there's another data point in the NASA lore to support this point of
view: there was a similar problem with the Pathfinder Rover that was
found and fixed using a virtually identical process. In this case the
software was written in C, but there was nonetheless a REPL because the
C code was running under vxWorks, which provides a shell that, while not
a full REPL, provides much of the same functionality.
If you have some actual evidence or theoretical arguments to support
your position let's hear them. All I've heard from you so far is
unsupported assertions and arguments of the form, "You haven't proven X,
therefore X is not true." If that's all you've got we'll just have to
agree to disagree.
rg
Nick Keighley
> But FWIW, there are sound theoretical reasons to believe that Lisp
> programs are easier to debug than Perl programs, mainly because Lisp has
> a REPL and Perl (normally) does not.
why would the presence of a REPL theoretically make debugging
something easier? Whose theory? Ive debugged small Perl and Scheme
programs.
Xah Lee
On Mar 10, 9:17 am, Ben Morrow <b...@morrow.me.uk> wrote:
> 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.
being a professional programer today, typically you know more than
just one language. Practical questions, discussions, involving more
than one language is natural, and in fact happens more and more often
in online forums over the past 15 years i've seen. Partly due to, of
course, the tremendous birth of languages in the past decade.
In the 1980s or 1990s, you don't typically use more than one lang in a
project. Today, probably majority of projects requires you to use more
than one well known general purpose language. In those times,
discussion of more than one language is usually academic comparison.
Today, honest post as “i know this in X but how you do in Y” is a
common need.
The reason they become flame wars is mostly not about the message
content. More about tech geeker's sensitivity, with the carried over
old school netiquette that any person mentioning lang x in group y
must be of no good intentions.
If you look at online forums today, in fact most comp lang forums have
no problem in mentioning or discussion different languages in context.
The problem occur more frequently in free-for-all type of forums where
the know-it-all tech geekers reside (the in-group argot is “hacker”),
each thinking they are justice kings and queens, take opportunities to
ridicule, flame, any post that mention other lang or any thing that
doesn't seem to be protective of their lang. This is comp.lang.*
newsgroups, with good as well as mostly bad aspects. Of course, the
free-for-all nature is precisely the reason most tech geekers stay in
newsgroups. A good percentage of them, if not majority, are old
timers.
Most newsgroup tech geekers consider cross-posting wrong. I consider
such taboo in this convention being a major contribution to the
redundant creation of new languages, flaws, and foster the hostile
faction nature of programing language groups we see.
It is sad to say, comp.lang.lisp today is 90% machine generated spam.
You see that each time this is brought up in the past 3 years, the
regulars are too busy boasting about how they've set up some tech geek
system so that spam don't reach their eyes, and sternly sputter about
web browser using idiots, with, profuse suggestions from their
infinite knowledge about what newsgroup reading software people should
be using.
To the comp.lang.python people, i think perhaps it is fruitful now to
think about de-coupling the newsgroup from the mailing list... am not
very involved in the comp.lang.python or python community in recent
years, but my thought is that, i got the feeling that most practical
posts happen in the mailing list and the newsgroup ones tend to be
more free flow of thoughts... so perhaps de-couple them is good,
because python is main stream now and mailing list is sustainable
large, is good for more practical, concrete questions and answers, and
philosophical free thoughts still have a place to go, in newsgroups.
further readings:
• Proliferation of Computing Languages
xahlee.org/UnixResource_dir/writ/new_langs.html
• Tech Geekers vs Spammers
xahlee.org/UnixResource_dir/writ/tech_geekers_vs_spammers.html
• Cross-posting & Language Factions
xahlee.org/Netiquette_dir/cross-post.html
Xah
∑ http://xahlee.org/
☄
Peter J. Holzer
I don't know about the theory, but in practice a REPL makes debugging
easier because you can interactively test your code. This is especially
powerful if it is combined with a debugger. The Perl debugger is a
primitive REPL (well, only a REL, you have to P yourself), so you may
already have used some of its features (like invoking functions or
evaluating arbitrarily complex expressions) and take them for granted,
but if you've ever used a debugger which didn't have the ability or had
to work without any debugger you'll appreciate it (of course you can
always write test programs which do the same thing, but that takes more
time).
hp
Kyle T. Jones
> Trying to understand a language (machine or human) that you do
> not know is futile. You must either give up, or actually learn
> the language.
>
That argument is self defeating. You simply cannot "actually learn the
language" without "trying to understand (the) language".
HTH. HAND.
Cheers.