The single biggest STUPIDITY in Perl ...

[jps]

The single biggest STUPIDITY in Perl, IMO, is that it does not
implement proper list-of-list, list-of-hash, hash-of-list & hash-of-
hash structures.

If -for example- you could just write
my @list = ((1,2),(3,4));
to get a 2x2 matrix (rather than 4-element list) I think the code
could be soooo much more elegant, and easier to write in a much more
readable fashion.

I believe you could then eliminate some 99% of all references that you
see in actual Perl-code -- them all sitting there only as a dreaded
workaround for this profound defect of the language.

Or am I missing something here?

Is this, by any chance, being fixed in Perl6, btw?

 

[A. Sinan Unur]

The single biggest STUPIDITY in Perl, IMO, is that it does not
implement proper list-of-list, list-of-hash, hash-of-list & hash-of-
hash structures.

Need some attention, eh?

If -for example- you could just write
my @list = ((1,2),(3,4));
to get a 2x2 matrix (rather than 4-element list) I think the code
could be soooo much more elegant, and easier to write in a much more
readable fashion.

First, @list is an array.

Second, what is so unreadable about:

#!/usr/bin/perl

use strict;
use warnings;

my @x = ( [1,2], [3,4] );

print $x[1][0], "\n";

__END__

I believe you could then eliminate some 99% of all references that you
see in actual Perl-code -- them all sitting there only as a dreaded
workaround for this profound defect of the language.

I guess if Perl 1 - 4 never existed, Perl 5 might have done things
differently. However, if the existence of references is the worst thing
about Perl, then it really ain't so bad, IMO.

Or am I missing something here?

The proper attitude. If you find the language so profoundly STUPID, feel
free not to use it. If you are going to use it, try to understand why
things are the way they are before making proclamations.

Is this, by any chance, being fixed in Perl6, btw?

I still haven't paid much attention to Perl 6, but I bet you could find
out and inform us about the differences in the handling of multi-
dimensional data structures.

Maybe someone has already written something about multidimensional data
structures in Perl 6. I wonder how one might find out if such a document
exists. I wonder indeed.

http://www.google.com/search?&q=perl6+multidimensional+data+structure

Ain't life wonderful?

Sinan

--
A. Sinan Unur <[email protected]>
(remove .invalid and reverse each component for email address)

comp.lang.perl.misc guidelines on the WWW:
http://www.rehabitation.com/clpmisc/

 

[Tad J McClellan]

The single biggest STUPIDITY in Perl,

this profound defect of the language.

Or am I missing something here?

You are missing that you are free to use a less stupid and defective
programming language.

Perl is not for everyone.

 

[smallpond]

The single biggest STUPIDITY in Perl, IMO, is that it does not
implement proper list-of-list, list-of-hash, hash-of-list & hash-of-
hash structures.

Obviously you don't know about "0 but true"

 

[Peter Makholm]

Obviously you don't know about "0 but true"

Which, when you think of it, isn't quite as stupid as "0 and false".

//Makholm

 

[brian d foy]

The single biggest STUPIDITY in Perl, IMO, is that it does not
implement proper list-of-list, list-of-hash, hash-of-list & hash-of-
hash structures.

I think there are a lot of candidates for "biggest", and in Perl 4 this
might have been one of them.

I believe you could then eliminate some 99% of all references that you
see in actual Perl-code

Well, remember that objects are references, and I bet they make up most
of the references.

Is this, by any chance, being fixed in Perl6, btw?

Well, it probably gets worse, because now almost everything is an
object.

 

[jps]

I think there are a lot of candidates for "biggest" ...

Hi Brian!
Well -- I disagree!!
Been using Perl on and off since ca 5 years,
mostly for what it was actually designed and where it truly *SHINES*
-- i.e. "extraction and reports".
All of the other strange quirks --while many of them certainly
peculiar-- I really dont have much of a problem with.
Only this one REALLY leaves a persistent impression of two fingers in
your eyes

How so many propellerheads came to the conclusion that Perl was a good
tool for things like serving web-contents,
is certainly beyond me -- but if some genius decides to build a new
house with cuttlery, it cant be blamed on the cuttlery!

Well, it probably gets worse, because now almost everything is an object.

Well... Objects are a GOOOOD thing.
References are a BAAAAAAAAAAAAAAAAAAAD thing.
So there might still be hope

 

[Tim Greer]

How so many propellerheads came to the conclusion that Perl was a good
tool for things like serving web-contents,

I still think it is. After all, embedding Perl code in the web page and
web server process (not spawning a new process and creating the
overhead of CGI -- which is CGI as the issue and not Perl) is why PHP
came about in the first place. I don't believe it's a terrible thing,
and the difference is really about what content you want it to output
and in what manner. There are templates, mod_perl and Mason and a lot
of things that put it on par for embedding and make it just as easy,
but I don't believe a CGI script is the worst plan for web content
anyway in most cases.

 

[jps]

...what is so unreadable about:

#!/usr/bin/perl

use strict;
use warnings;

my @x = ( [1,2], [3,4] );

print $x[1][0], "\n";

Heeey! Youre CHEATING!
And the "use strict" pragma is BROKEN!!!

Mannerly Perl syntax is:
A) $x[0]->[1]
or
B) ${$x[0]}[1]

But thats not where the trouble is -- it comes when you start calling
subroutines with arrays and hashes in the parameter-list... which you
CANT!

 

[jps]

First, @list is an array.

Wrong! It's BOTH. Perl cant tell the difference

 

[Uri Guttman]

j> Wrong! It's BOTH. Perl cant tell the difference

i know you have a smiley but perl can tell the difference between lists
and arrays as they are very different animals which have only a couple
of actual similarities.

about the only thing you can do with both lists and arrays is accessing
elements using numeric indices or fixed ordering. this includes index
accesses, slices, list context assignments and arg lists, etc.

but the number of differences are more common:

arrays lists
------ -----
can change size fixed size
allocated from the heap allocated on the stack
freed later by freed after expression is done
garbage collector
lives between statements lives in a single part of an expression
can take references no referencing
can be passed around code can only be used one time
in its expression
can be given a name no name is possible
can make nested trees lists are one dimensional

so you can see they are very different with some listy operations in
common. that is why perl hackers get annoyed when people confuse lists
and arrays.

uri

 

[Tad J McClellan]

Wrong! It's BOTH.

No it isn't.

@list is an array.

@list _contains_ a list.


Just as with

$num = 3;

$num is a (scalar) variable.

$num contains a number.

Perl cant tell the difference

Yes it can.

An array has a changeable length. A list does not. An array is something
you can push or pop, while a list is a set of values. Some people make
the distinction that a list is a value while an array is a variable.

 

[cartercc]

I still think it is.  After all, embedding Perl code in the web page and
web server process (not spawning a new process and creating the
overhead of CGI -- which is CGI as the issue and not Perl) is why PHP
came about in the first place.  I don't believe it's a terrible thing,
and the difference is really about what content you want it to output
and in what manner.  There are templates, mod_perl and Mason and a lot
of things that put it on par for embedding and make it just as easy,
but I don't believe a CGI script is the worst plan for web content
anyway in most cases.

I've used both embedded technologies (PHP, JSP, ASP, etc) and
technologies that emit HTML (like traditional CGI). I strongly prefer
the latter. If you embed logic in HTML, you are mixing data, logic,
and document markup. If you use the Perl equivalent of servlets, you
separate logic and presentation.

Data should drive logic, and logic should drive presentation. As to
traditional CGI, mod_perl solves those kinds of problems.

As a general rule, I believe that The Best methodology for building
large web apps is to build a wall of separation between the data,
logic, and interface, using your logic components to control both the
data (and access to data) and the interface. Mixing interface with
logic isn't a good idea, IMO.

CC

 

[Tim Greer]

I've used both embedded technologies (PHP, JSP, ASP, etc) and
technologies that emit HTML (like traditional CGI). I strongly prefer
the latter. If you embed logic in HTML, you are mixing data, logic,
and document markup.

I don't overall mind the mixing of the HTML and logic, but I too prefer
the latter. I think too many people just don't understand the ease of
using Perl and CGI for serving content. Too many people are convinced
that Perl IS CGI and that CGI is "deathly slow". The differences are
negligible and I trust Perl over PHP any day regarding bug and security
ramifications. Not that I dislike PHP, I just know better.

I suppose if you get someone new and they don't want to be bothered by
specifying the content type/header and take 5 minutes to understand
permissions, that they might prefer PHP. I really don't mind either
way, but all of my code for the last 10 years has started in Perl
unless I'm told or asked to code in another language.

 

[Ted Zlatanov]

c> As a general rule, I believe that The Best methodology for building
c> large web apps is to build a wall of separation between the data,
c> logic, and interface, using your logic components to control both the
c> data (and access to data) and the interface. Mixing interface with
c> logic isn't a good idea, IMO.

This is a great rule as long as you accept that you have to break it
occasionally.

Ted

 

[brian d foy]

Hi Brian!
Well -- I disagree!!

If you disagree that there are a lot of candidates for Perl's biggest
design mistake, then you just don't use Perl enough.

This is a question I ask a lot of people to plumb the depths of their
experience. If you can't list five things, you just haven't used enough
of the language yet:

http://stackoverflow.com/questions/282329/what-are-five-things-you-hate-
about-your-favorite-language

 

[brian d foy]

Mannerly Perl syntax is:
A) $x[0]->[1]
or
B) ${$x[0]}[1]

Well, the accepted idiom is to leave off the implied -> between
subscripts:
..
$x[0][1];

You only need the arrow when the thing to the left is not a subscript
(and is a reference):

$ref->[0][1];

Your problem with references might be that you are using them wrong.

 

[Todd Wade]

Well... Objects are a GOOOOD thing.
References are a BAAAAAAAAAAAAAAAAAAAD thing.

References are bad for bad programmers. References are fast. This is
why perl is faster and uses less memory than python and ruby:

http://xodian.net/serendipity/index.php?/archives/27-Benchmark-PHP-vs.-Python-vs.-Perl-vs.-Ruby.html

Anyway, you're not complaining about references. You are complaining
that perl doesn't do automatic dereferencing (like its slower more
resource intensive cousins).

And to that I say... THANK THE HEAVENS ABOVE. Automatic dereferencing
removes a whole set of functionality needed to write concise programs.
It makes one write lines and lines of procedural code when all that
should be needed is a simple memory lookup.

Regards,

trwww

 

[Tad J McClellan]

} but the number of differences are more common:
}
} arrays lists
} ------ -----
} can change size fixed size
} allocated from the heap allocated on the stack
} freed later by freed after expression is done
} garbage collector
} lives between statements lives in a single part of an expression
} can take references no referencing
} can be passed around code can only be used one time
} in its expression
} can be given a name no name is possible
} can make nested trees lists are one dimensional

You left out:
evaluates to # of elements evaluates to last element
in scalar context in scalar context

Probably because you may have an array in scalar context, but
it is not possible to ever have a list in scalar context.


There IS NO LIST in:

my $foo = (7, 8, 9);

There is only the "comma operator" inside of some parenthesis.

So he left out:
can exist in scalar context never exists in scalar context

 

[Uri Guttman]

BC> } but the number of differences are more common:
BC> }
BC> } arrays lists
BC> } ------ -----
BC> } can change size fixed size
BC> } allocated from the heap allocated on the stack
BC> } freed later by freed after expression is done
BC> } garbage collector
BC> } lives between statements lives in a single part of an expression
BC> } can take references no referencing
BC> } can be passed around code can only be used one time
BC> } in its expression
BC> } can be given a name no name is possible
BC> } can make nested trees lists are one dimensional

BC> You left out:
BC> evaluates to # of elements evaluates to last element
BC> in scalar context in scalar context

incorrect. there is no such thing as a list in scalar context. it is
just a series of comma ops in that situation, no list is ever created.

uri