The single biggest STUPIDITY in Perl ...

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.

Advertisements

jps <> wrote in news:0810b4ad-e075-45ca-b94b-:
> 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.

On Dec 11, 8:32 pm, brian d foy <> wrote:
> 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!

> > Is this, by any chance, being fixed in Perl6, btw?
>
> 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

jps wrote:
> 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.
--
Tim Greer, CEO/Founder/CTO, BurlyHost.com, Inc.
Shared Hosting, Reseller Hosting, Dedicated & Semi-Dedicated servers
and Custom Hosting. 24/7 support, 30 day guarantee, secure servers.
Industry's most experienced staff! -- Web Hosting With Muscle!

On Dec 11, 2:25 am, "A. Sinan Unur" <> wrote:
> > 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.

j> On Dec 11, 2:25 am, "A. Sinan Unur" <> wrote:
>> > 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.

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.

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.

On Dec 11, 3:27 pm, Tim Greer <> wrote:
> 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.

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.
--
Tim Greer, CEO/Founder/CTO, BurlyHost.com, Inc.
Shared Hosting, Reseller Hosting, Dedicated & Semi-Dedicated servers
and Custom Hosting. 24/7 support, 30 day guarantee, secure servers.
Industry's most experienced staff! -- Web Hosting With Muscle!

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.

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.

Bernie Cosell <> wrote:
> Uri Guttman <> wrote:
>
> } 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

BC> Uri Guttman <> wrote:
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.

Share This Page

Welcome to The Coding Forums!

Welcome to the Coding Forums, the place to chat about anything related to programming and coding languages.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about coding or chat with the community and help others.
Sign up now!