Any Perl victims care to explain this?

[Jeremy]

Come on Matt, you are flauting you unfamiliarity with Perl, and using 
it to repeat a few tired jokes.

Pull your data out of the database with "fetchrow_array", which will 
hand you one row each time you call it until it runs out of results.  
e.g.

my $dbh = new DBI ($connect_string);
my $sth = $dbh->prepare("SELECT * FROM table");
while ( my @array = $sth->fetchrow_array ) {
	print @array;
}

DBI likes to return list-style data structures, and you can use map 
(Perl's version of mapcar) to work with the list.

On 2002.04.04 19:22 Matthew Hawkins wrote:
> I've been tearing what's left of my hair out for two days trying to
> deal
> with a simple problem.
> 
> Any sane programmer would like to enjoy such wonderful programming
> constructs as obtaining the value of a key in a hash table (okay, a
> hash
> table reference), like so:
> 
> $value = $table->{'key'};
> 
> But thanks to Perl, which enjoys the full power of TIMTOWTDI, one must
> instead do:

Oh come on.  Everyone knows that C programmers love throwing around 
pointers which are, as I recall, completely untyped.  I don't think 
that there is even a way to tell what a pointer is pointing to.

You only need to do the following if your tables don't have primary 
keys, or if you request multiple rows at once.  How else would you 
expect it to return a collection of results?.  If you only query on 
your primary keys, you will never get ARRAYREFs back, 
> 
> if (ref($table->{'key'}) eq "SCALAR") {
>         $value = ${$table->{'key'}};

This will place a reference to the result hash in $value.  Not what you 
want.


> } elseif (ref($table->{'key'}) eq "ARRAYREF") {
>         $value = join(' ', @{$table->{'key'}});

This will produce something like:  "HASHREF(0xFDS30)". Probably not 
what you want.

> } else {
>         $value = [$table->{'key'}];
		   ^			   ^

these square brackets probably don't do what you want them to either.

You are probably dereferencing too early.  Just think of the hash 
values as structs and you'll find it a lot easier.

> 
> and pray to God that you don't encounter yet another random return
> type
> and have to add yet another conditional clause to deal with it.  Each
> time you need to use it.

Oh come on.  Everyone knows that C programmers love throwing around 
pointers which are, as I recall, completely untyped.  I don't think 
that there is even a way to tell what a pointer is pointing to.  Am I 
close?

> 
> Why?  TIMTOWDI - there is more than one way to do it, and by God we're
> going to force you to use as many of them as possible.

Ummm... Nobody forced you to pick Tie::DBI rather than pure DBI.  You 
can even pick the DBI handle out with $dbh = $table->tied(), if it's 
not your code.


> 
> FWIW %table is tie'd to a MySQL database (using Tie::DBI) and all
> values are integers.
> 
> Unlike sane languages, where you would have something like:
> 
> int return_value_from_hash(int key) {
>         return data[key];
> }
> 
> and the programmer can rest easy knowing that they will ALWAYS get an
> integer back, Perl likes to keep you on your toes and randomly selects

Not so.  Perl encapsulates your return values so they don't explode 
later.

> the return type from the list of all possible data types.  Then,
> knowing
> that you've employed nasty secret ninja hacks like the above to work
> around it, will return completely different data types the next day,
> forcing you to expand the list to deal.

And typecasting is so much more reliable?

> 
> 2/3rds of this script is dealing with this completely brain-dead
> "feature", and reinforces my commitment to take out Larry Wall in

OK, post it to the list, and we'll see if we can work on it.

> preference to Bill Gates when I finish my time machine.  The bastard
> even thinks that this insanity is a good thing, as documented here:
> http://www.acm.org/crossroads/xrds1-2/lwall.html
> 
> "He criticizes other modern languages that have been developed by
> people
> who 'try to define their languages such that you can't do anything
> bad.'"
> 
> Ummm dude.  Inconsistent return types are good?

Pointers, anyone?

>  Context-sensitive,
> sometimes with exceptions, sometimes just plain inconsistent meanings
> to
> built-in functions, operators and variables is good?  Line noise as
> the
> (GPL required) preferred format for editing is good?

I was sympathetic until I read this.  Now I'm just going to piss on the 
little lamer who doesn't know what he's talking about.

So, post your program to the list, and we'll see if it's the brain-dead 
features or the brain-dead programmer.  It's pretty clear that:

* you didn't read the documentation
* you don't have the first clue how to program anything other assembler 
(hammer and chisel work)
* you think you're a lot smarter than you are