From: Sean Conner
Date: 07:43 on 22 Dec 2006
Subject: Re: perl
It was thus said that the Great David Cantrell once stated:
> On Sun, Dec 17, 2006 at 09:36:52PM -0800, Aaron J. Grier wrote:
>
> > this is exactly what I hate about perl. "there's more than one way to
> > do it" invariably means that some dumbfucks out there will attempt to do
> > it every single way possible in the language. perl apparently prides
> > itself on this.
>
> A general purpose language which can't be used in different ways to
> solve different problems is not fit for purpose. Are you proposing that
> programming languages should be rigid and unsuitable for a wide range of
> tasks?
Um ... <raises hand> ... I'd like somethimg a bit more consistent.
A typical programic idiom I use (when programming in C) is:
if (argc == 1)
do_some_process(stdin);
else
{
for (i = 1 ; i < argc ; i++)
{
input = fopen(argv[i],"r");
do_some_process(input);
fclose(input);
}
}
So imagine my surprise when:
if (scalar(@ARGV) == 1)
{ # the one bit of consistancy I can do without actually
&do_some_process(STDIN);
}
else
{
for ($i = 1 ; $i < scalar(@ARGV) ; $i++)
{
open INPUT,$ARGV[i];
&do_some_process(INPUT);
close INPUT;
}
}
Doesn't work at all. Problem one (remember, I come from a C background
here), $ARGV[0] *doesn't* contain the program name ($ARGV isn't right since
it's only defined when using <ARGV> apparently---lovely), so okay, I adjust
some numbers and it *still* fails because you can't pass file handles to
subroutines.
Only, it seems like you *can* but only if you use the *obvious* notation
open INPUT,$ARGV[i];
&do_some_processing(*INPUT);
close INPUT;
Never mind the fact that every @#$@#$ variable in Perl is preceeded by a
'$', '@' or a '%' *except* for filehandles, diretory handles and block
labels.
Yes, C has its quirks too, but at least there I can actually pass any type
of variable to a subroutine without having a special notation for a certain
class of variables.
-spc (And least you think otherwise, there's plenty to hate in C, but I'm
afraid I've lived with it long enough to subconsciously work around
its quirks ... )
From: Anton Berezin
Date: 08:36 on 22 Dec 2006
Subject: Re: perl
On Fri, Dec 22, 2006 at 02:43:08AM -0500, Sean Conner wrote:
> Um ... <raises hand> ... I'd like somethimg a bit more consistent.
>
> A typical programic idiom I use (when programming in C) is:
>
> if (argc == 1)
> do_some_process(stdin);
> else
> {
> for (i = 1 ; i < argc ; i++)
> {
> input = fopen(argv[i],"r");
> do_some_process(input);
> fclose(input);
> }
> }
>
> So imagine my surprise when:
>
> if (scalar(@ARGV) == 1)
> { # the one bit of consistancy I can do without actually
> &do_some_process(STDIN);
> }
> else
> {
> for ($i = 1 ; $i < scalar(@ARGV) ; $i++)
> {
> open INPUT,$ARGV[i];
> &do_some_process(INPUT);
> close INPUT;
> }
> }
Now, this is just silly. This reminds me of someone complaining that Perl
sucks because Perl code is difficult to read by C programmers. Perl is
hateful, but not for these reasons. You are just trying to write C here.
\Anton.
From: Sean Conner
Date: 08:44 on 22 Dec 2006
Subject: Re: perl
It was thus said that the Great Anton Berezin once stated:
> On Fri, Dec 22, 2006 at 02:43:08AM -0500, Sean Conner wrote:
>
> > Um ... <raises hand> ... I'd like somethimg a bit more consistent.
> >
> > A typical programic idiom I use (when programming in C) is:
> >
> > if (argc == 1)
> > do_some_process(stdin);
> > else
> > {
> > for (i = 1 ; i < argc ; i++)
> > {
> > input = fopen(argv[i],"r");
> > do_some_process(input);
> > fclose(input);
> > }
> > }
> >
> > So imagine my surprise when:
> >
> > if (scalar(@ARGV) == 1)
> > { # the one bit of consistancy I can do without actually
> > &do_some_process(STDIN);
> > }
> > else
> > {
> > for ($i = 1 ; $i < scalar(@ARGV) ; $i++)
> > {
> > open INPUT,$ARGV[i];
> > &do_some_process(INPUT);
> > close INPUT;
> > }
> > }
>
> Now, this is just silly. This reminds me of someone complaining that Perl
> sucks because Perl code is difficult to read by C programmers. Perl is
> hateful, but not for these reasons. You are just trying to write C here.
Um ...
Unix is written in C. Perl came to life in the Unix universe. Plenty of
Unix utilities like cat, sed, od, grep and less (and more) can be used on
files or in pipes. This idiom is pretty strong in the Unix world. Perl
seems to go out of its way to prevent this (or is that me as a C programmer
speaking?)
-spc (then again, it took a year or two for me to stop writing assembly
language in C ... 8-)
From: Abigail
Date: 10:03 on 22 Dec 2006
Subject: Re: perl
--FoLtEtfbNGMjfgrs
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Dec 22, 2006 at 03:44:22AM -0500, Sean Conner wrote:
> It was thus said that the Great Anton Berezin once stated:
> > On Fri, Dec 22, 2006 at 02:43:08AM -0500, Sean Conner wrote:
> >=20
> > > Um ... <raises hand> ... I'd like somethimg a bit more consistent.
> > >=20
> > > A typical programic idiom I use (when programming in C) is:
> > >=20
> > > if (argc =3D=3D 1)
> > > do_some_process(stdin);
> > > else
> > > {
> > > for (i =3D 1 ; i < argc ; i++)
> > > {
> > > input =3D fopen(argv[i],"r");
> > > do_some_process(input);
> > > fclose(input);
> > > }
> > > }
> > >=20
> > > So imagine my surprise when:
> > >=20
> > > if (scalar(@ARGV) =3D=3D 1)
> > > { # the one bit of consistancy I can do without actually
> > > &do_some_process(STDIN);
> > > }
> > > else
> > > {
> > > for ($i =3D 1 ; $i < scalar(@ARGV) ; $i++)
> > > {
> > > open INPUT,$ARGV[i];
> > > &do_some_process(INPUT);
> > > close INPUT;
> > > }
> > > }
> >=20
> > Now, this is just silly. This reminds me of someone complaining that P=
erl
> > sucks because Perl code is difficult to read by C programmers. Perl is
> > hateful, but not for these reasons. You are just trying to write C her=
e.
>=20
> Um ...
>=20
> Unix is written in C. Perl came to life in the Unix universe. Plenty =
of
> Unix utilities like cat, sed, od, grep and less (and more) can be used on
> files or in pipes. This idiom is pretty strong in the Unix world. Perl
> seems to go out of its way to prevent this (or is that me as a C programm=
er
> speaking?)
No.
You just don't seem to know Perl.
Abigail
--FoLtEtfbNGMjfgrs
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFFi61pBOh7Ggo6rasRAmy2AJ0fDS45bMxUfUtb8V9K0FbSVnNAhwCdGZIK
DAsAxkTjkOEVg8G0uLBLG3Q=
=PN/C
-----END PGP SIGNATURE-----
--FoLtEtfbNGMjfgrs--
From: Abigail
Date: 10:02 on 22 Dec 2006
Subject: Re: perl
--hwvH6HDNit2nSK4j
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Dec 22, 2006 at 02:43:08AM -0500, Sean Conner wrote:
> It was thus said that the Great David Cantrell once stated:
> > On Sun, Dec 17, 2006 at 09:36:52PM -0800, Aaron J. Grier wrote:
> >=20
> > > this is exactly what I hate about perl. "there's more than one way to
> > > do it" invariably means that some dumbfucks out there will attempt to=
do
> > > it every single way possible in the language. perl apparently prides
> > > itself on this.
> >=20
> > A general purpose language which can't be used in different ways to
> > solve different problems is not fit for purpose. Are you proposing that
> > programming languages should be rigid and unsuitable for a wide range of
> > tasks?
>=20
> Um ... <raises hand> ... I'd like somethimg a bit more consistent.
>=20
> A typical programic idiom I use (when programming in C) is:
>=20
> if (argc =3D=3D 1)
> do_some_process(stdin);
> else
> {
> for (i =3D 1 ; i < argc ; i++)
> {
> input =3D fopen(argv[i],"r");
> do_some_process(input);
> fclose(input);
> }
> }
>=20
> So imagine my surprise when:
>=20
> if (scalar(@ARGV) =3D=3D 1)
> { # the one bit of consistancy I can do without actually
> &do_some_process(STDIN);
> }
> else
> {
> for ($i =3D 1 ; $i < scalar(@ARGV) ; $i++)
> {
> open INPUT,$ARGV[i];
> &do_some_process(INPUT);
> close INPUT;
> }
> }
>=20
> Doesn't work at all. Problem one (remember, I come from a C background
> here), $ARGV[0] *doesn't* contain the program name ($ARGV isn't right sin=
ce
> it's only defined when using <ARGV> apparently---lovely), so okay, I adju=
st
> some numbers and it *still* fails because you can't pass file handles to
> subroutines.
>=20
> Only, it seems like you *can* but only if you use the *obvious* notation
>=20
> open INPUT,$ARGV[i];
> &do_some_processing(*INPUT);
> close INPUT;
>=20
> Never mind the fact that every @#$@#$ variable in Perl is preceeded by a
> '$', '@' or a '%' *except* for filehandles, diretory handles and block
> labels.
>=20
> Yes, C has its quirks too, but at least there I can actually pass any t=
ype
> of variable to a subroutine without having a special notation for a certa=
in
> class of variables.
You know, in Perl, the equivalent of the C snippet would just be:
do_some_process;
while in do_some_process, you'd use the '<>' to read input. Perl has the
snippet build in - if there are no arguments, '<>' will read from the
file(s) given as arguments.
Don't blame Perl for not having to translate your C code.
Abigail
--hwvH6HDNit2nSK4j
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFFi60rBOh7Ggo6rasRApJFAKDBVV4CG8ymp5TGjg8E3a9GBS+q3wCcD5zg
tGuMW/N3EKBpA/ahzXU9myw=
=a5LP
-----END PGP SIGNATURE-----
--hwvH6HDNit2nSK4j--
From: Peter da Silva Date: 13:09 on 22 Dec 2006 Subject: Re: perl > You know, in Perl, the equivalent of the C snippet would just be: > > do_some_process; > > while in do_some_process, you'd use the '<>' to read input. Perl has > the > snippet build in - if there are no arguments, '<>' will read from the > file(s) given as arguments. Yep, Perl is full of rigidly defined areas of doubt and uncertainty like that. The fix to pointlessly obscure syntax is to introduce more obscure syntax that handles some common cases that the pointlessly obscure syntax makes difficult... without actually doing anything about the fact that you have to use do_some_process(STDIN); but do_some_process(*INPUT); when you suddenly realize that you need to handle files ending with ".o" differently from files ending in ".a" and by the way doesn't that mean that file boundaries actually matter now...?
From: Abigail
Date: 13:27 on 22 Dec 2006
Subject: Re: perl
--3FyYKcuUbgqNYeqV
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Dec 22, 2006 at 07:09:44AM -0600, Peter da Silva wrote:
> >You know, in Perl, the equivalent of the C snippet would just be:
> >
> > do_some_process;
> >
> >while in do_some_process, you'd use the '<>' to read input. Perl has=20
> >the
> >snippet build in - if there are no arguments, '<>' will read from the
> >file(s) given as arguments.
>=20
> Yep, Perl is full of rigidly defined areas of doubt and uncertainty=20
> like that. The fix to pointlessly obscure syntax is to introduce more=20
> obscure syntax that handles some common cases that the pointlessly=20
> obscure syntax makes difficult... without actually doing anything about=
=20
> the fact that you have to use
>=20
> do_some_process(STDIN);
>=20
> but
>=20
> do_some_process(*INPUT);
>=20
> when you suddenly realize that you need to handle files ending with=20
> ".o" differently from files ending in ".a" and by the way doesn't that=20
> mean that file boundaries actually matter now...?
You want to know whether you are at a file boundary? Use eof().
You want to know the name of the current file? Use $ARGV; perl will
set it for you. (And as a previous poster mentioned, $ARGV is only set
when reading from files. Which means that if it's not set, you aren't
reading from a file - but from standard input. And yes, if you use '-'
as a filename argument, Perl will read from STDIN, just like most of the
other Unix tools. Want to read from a pipe as well? Supply 'someprogram
|' as the file name, and Perl will take care of setting up the pipe for
you. I always thought that magical open was only hated by people not
understanding Unix, but appears it's not so).
And yes, it's hateful that filehandles aren't first class
objects. However, while can't get rid of the hateful syntax for backwards
compatability reasons, one doesn't need barefiles very often. See, in
the last century people agreed that the filehandle syntax is hateful,
so they made it that primitives that take filehandles are argument can
also take a reference to a filehandle as argument, and all will work well.
open my $filehandle, "<", "/etc/passwd" or die;
while (<$filehandle>) {print}
close $filehandle;
works perfectly fine.
And if you don't like <>, use 'readline'.=20
Abigail
--3FyYKcuUbgqNYeqV
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFFi91bBOh7Ggo6rasRAux/AJ0QmL+LrvZH2xm9TVGdZkV/RDK4vACeJaNc
yOGB7kAcHUzj8zlMAK4+OV0=
=wYvh
-----END PGP SIGNATURE-----
--3FyYKcuUbgqNYeqV--
From: Peter da Silva Date: 15:04 on 22 Dec 2006 Subject: Re: perl On Dec 22, 2006, at 7:27 AM, Abigail wrote: > And yes, it's hateful that filehandles aren't first class objects. Thank you. I really appreciate acknowledgment of valid hate. :) Oh, if only Xerox hadn't driven a stake through Smalltalk's heart by trying to make it into a cash cow ... having EVERYTHING being a first class object is lovely.
From: A. Pagaltzis Date: 18:41 on 22 Dec 2006 Subject: Re: perl * Peter da Silva <peter@xxxxxxx.xxx> [2006-12-22 14:10]: > The fix to pointlessly obscure syntax is to introduce more > obscure syntax that handles some common cases that the > pointlessly obscure syntax makes difficult... without actually > doing anything about the fact that you have to use Fallacy. Fixing the pointlessly obscure filehandle syntax wasn't remotely the point of introducing the diamond operator's magic behaviour. Making Perl more useful for writing utilities was the point, and it definitely succeeds at that. Certainly I don't hate the fact that I can add features to many scripts by deleting a bunch of code. Regards,
From: demerphq Date: 19:26 on 22 Dec 2006 Subject: Re: perl On 12/22/06, Peter da Silva <peter@xxxxxxx.xxx> wrote: > > You know, in Perl, the equivalent of the C snippet would just be: > > > > do_some_process; > > > > while in do_some_process, you'd use the '<>' to read input. Perl has > > the > > snippet build in - if there are no arguments, '<>' will read from the > > file(s) given as arguments. > > Yep, Perl is full of rigidly defined areas of doubt and uncertainty > like that. The fix to pointlessly obscure syntax is to introduce more > obscure syntax that handles some common cases that the pointlessly > obscure syntax makes difficult... without actually doing anything about > the fact that you have to use > > do_some_process(STDIN); > > but > > do_some_process(*INPUT); > > when you suddenly realize that you need to handle files ending with > ".o" differently from files ending in ".a" and by the way doesn't that > mean that file boundaries actually matter now...? Whats really hateful is complaining about syntax that is more or less /already deprecated/. Ok, STDIN, STDOUT, and STDERR are exceptions, but in general one does not use globally scoped file handles in perl. Instead one is strongly recommended to use lexically scoped filehandles, which dont have any of the issues that you have outlined. And frankly you can always my $stdin = \*STDIN; my $stdout = \*STDOUT; my $stderr = \*STDERR; ... do_some_process($stderr); instead. Or just think to yourself "STDIN, STDOUT, STDERR are not like the other filehandles my program might deal with, as they are provided by the shell/os, so maybe they /should/ look different" Cheers, Yves
From: peter (Peter da Silva) Date: 22:04 on 22 Dec 2006 Subject: Re: perl > instead. Or just think to yourself "STDIN, STDOUT, STDERR are not like > the other filehandles my program might deal with, as they are provided > by the shell/os, so maybe they /should/ look different" *snork*. There's absolutely NOTHING magical about file descriptors zero, one, and two and I've had to use them as regular file descriptors for ordinary files more than once, back when you only got twenty of the buggers.
From: Earle Martin
Date: 11:10 on 22 Dec 2006
Subject: Re: perl
The software that I hate the most is often the software I have to do
maintenance on. I'm a 100% Perl guy, and spend a lot of time with
other people's Perl. One of my pet hates is seeing this:
> for ($i = 1 ; $i < scalar(@ARGV) ; $i++)
> {
> open INPUT,$ARGV[i];
Perl is not C. Yes, it lets you write do this. But you shouldn't. Why?
Because it has useful constructs like "foreach" that let you avoid
hateful neolithic code like this.
> &do_some_process(INPUT);
Just as hateful, or even more so, is something like this, which
generally indicates the author hasn't read any books about Perl that
were published since 1998, or learnt Perl from a shoddy website, last
updated around 2001, whose author hasn't read any books about Perl
that were published since 1998.
From: Dave Hodgkinson
Date: 11:20 on 22 Dec 2006
Subject: Re: perl
On 22 Dec 2006, at 11:10, Earle Martin wrote:
> The software that I hate the most is often the software I have to do
> maintenance on. I'm a 100% Perl guy, and spend a lot of time with
> other people's Perl. One of my pet hates is seeing this:
>
>> for ($i = 1 ; $i < scalar(@ARGV) ; $i++)
>> {
>> open INPUT,$ARGV[i];
>
> Perl is not C. Yes, it lets you write do this. But you shouldn't. Why?
> Because it has useful constructs like "foreach" that let you avoid
> hateful neolithic code like this.
We've just started enforcing perlcritic which has led to some
interesting
debate about fixing such shonky code at the risk of breaking it.
One of my favourites is "return;" vs. "return undef;".
From: Sean Conner
Date: 20:29 on 22 Dec 2006
Subject: Re: perl
It was thus said that the Great Earle Martin once stated:
> The software that I hate the most is often the software I have to do
> maintenance on.
I'll agree to that 100%.
> I'm a 100% Perl guy, and spend a lot of time with
> other people's Perl. One of my pet hates is seeing this:
>
> > for ($i = 1 ; $i < scalar(@ARGV) ; $i++)
> > {
> > open INPUT,$ARGV[i];
>
> Perl is not C. Yes, it lets you write do this. But you shouldn't. Why?
> Because it has useful constructs like "foreach" that let you avoid
> hateful neolithic code like this.
Yes, I know that. What I did not know (until it bit me) was that @ARGV
does *not* contain the program name.
I'm primarily a C programmer. So ..
int main(int argc,char *argv[]) { ... }
/* or char **argv */
and guess what? argv[0] contains the program name, while the rest of the
command line appear starting at argv[1].
So I see that this Perl language has an array @ARGV. I don't care for the
program name, so that means:
shift @ARGV; # or is it pop @ARGV ?
foreach $argument (@ARGV) { ... }
or the for() loop. Since I'm already used to using for(), that's what I
used. Little did I realize that Perl has conviently stripped the first
argument for me (the program name).
But *neolithic code*?
What? I should do
map
{
open INPUT $_;
&do_some_process;
close INPUT;
} @ARGV;
So, am I wrong in trying to apply previous programming experience to Perl?
> > &do_some_process(INPUT);
>
> Just as hateful, or even more so, is something like this, which
> generally indicates the author hasn't read any books about Perl that
> were published since 1998, or learnt Perl from a shoddy website, last
> updated around 2001, whose author hasn't read any books about Perl
> that were published since 1998.
Odd. I have O'Reilly's "Perl in a Nutshell" book (latest version) since I
already know how to program in an imperative langauge thank you very much
and all I really *care* to know is how to declare variables, call
subroutines and pass data back and forth, and what functions are available
to me.
Guess I was wrong in that.
-spc (Back to C for me ... )
From: Yoz Grahame Date: 09:09 on 26 Dec 2006 Subject: Re: perl On 12/22/06, Earle Martin <hates-software@xxxxxxxx.xxx> wrote: > > Just as hateful, or even more so, is something like this, which > generally indicates the author hasn't read any books about Perl that > were published since 1998, or learnt Perl from a shoddy website, last > updated around 2001, whose author hasn't read any books about Perl > that were published since 1998. Funny you should mention, 'cos one of the last Perl books I read was Christiansen's "Perl Cookbook", which came out in 1998. It was meant to make me feel much more confident about my coding (after five solid years of Perl) and instead it scared the shit out of me because it was jam-packed with samples where a slight, unintuitive change in the way you call something will produce a completely different result. For example, two near-identical lines of code which, to the eye of an intermediate Perl coder, look like they do exactly the same thing. One of the things I've always really liked about Perl (and I still do) is Wall's efforts to bring the friendliness, fluidity and flexibilty of natural language to a programming language. I know lots of people hate post-statement ifs and unlesses, but I think they're great. Unfortunately, because it's a *really* leaky abstraction, it means that you don't get the resilience of meaning that natural language has. Perl will let you accidentally do things that are the complete opposite of what you meant. The compiler will often bend over backwards to allow certain things that it should just stop (and no, -w won't catch them all). Yes, many languages will let you shoot yourself in the foot in all kinds of ways, but Perl seems to be *way* better at it than most. This is why a fair degree of effort has gone into creating modules that discourage the wilder kinds of coding, make Perl into a less flexible language. The many slightly-different invocations, the module-driven Perl variations and basically all the TMTOWTDI-ness is great for flexibility but it is also deeply, deeply hateful. Firstly, for what it does to both The Principle Of Least Surprise; secondly, for the amount of brain-space I need to allocate to being able to handle all the different ways I will encounter of doing the same fucking thing. To me, the final nail in TMTOWTDI's coffin was Ruby on Rails vs Catalyst. In providing loads of different possible arrangements of template engine and all that other stuff, it both multiplied the amount of decision making you need to do to get something basic done, increased unnecessary complexity and as a result managed to significantly reduce the chance of getting help on whatever specific problems you hit during your project. RoR, for all its many faults, provides a single path to project building that greatly simplifies things. This is why several of the remaining Perl hackers who I converse with regularly are moving over to RoR or Django. Ultimately, flexibility can be a lifesaver but only at the point when you need it. Before then, it's a burden. This problem is one of the biggest sources of FOSS-related hate, coming from geeks who think that "more choice" always equals "better". To quote Edina from Ab Fab: "I don't want more choice! I just want nicer things!" I still think Perl's great - I've been coding in it for over 10 years. But for future web projects, I'll probably be checking out something else. As for language hate: how come nobody's mentioned PHP yet? Because, fucking hell, do I have some SERIOUS bile worked up there... -- Yoz
From: A. Pagaltzis Date: 16:11 on 26 Dec 2006 Subject: Re: perl * Yoz Grahame <yoz@xxx.xxx> [2006-12-26 10:10]: > To me, the final nail in TMTOWTDI's coffin was Ruby on Rails vs > Catalyst. In providing loads of different possible arrangements > of template engine and all that other stuff, it both multiplied > the amount of decision making you need to do to get something > basic done, increased unnecessary complexity and as a result > managed to significantly reduce the chance of getting help on > whatever specific problems you hit during your project. Errm, right. That's why noone on the mailing lists uses anything but TT2 and DBIC, why the beginner's tutorials don't mention any other options, and why inquiries about these two tend to get answered very quickly. Of course, it's better to switch to a system where the "ORM" is built by people who say multi-column primary keys are bad for you and foreign keys are pointless. That's "opinionated". Like that certain "RDBMS" whose developers were also "opinionated", I guess, and used to very publically state that transactions are silly (and who needs subselects anyway?). Regards,
From: Yoz Grahame Date: 19:40 on 26 Dec 2006 Subject: Re: perl On 12/26/06, A. Pagaltzis <pagaltzis@xxx.xx> wrote: > > Errm, right. That's why noone on the mailing lists uses anything > but TT2 and DBIC, why the beginner's tutorials don't mention any > other options, and why inquiries about these two tend to get > answered very quickly. Wasn't the case last time I checked, which I admit to have been over a year ago. Back then, it was "Catalyst's great because it lets you choose either TT2 or HTML::Mason or HTML::Template! To work out which you want, consider [... INSANE ROBOT MONKEY SPEAK...]" Also, the module documentation mostly consisted of "Er... this bit coming soon!" which I wouldn't have minded if the publicity machine hadn't already been turned on. > Of course, it's better to switch to a system where the "ORM" is > built by people who say multi-column primary keys are bad for you > and foreign keys are pointless. That's "opinionated". Like that > certain "RDBMS" whose developers were also "opinionated", I guess, > and used to very publically state that transactions are silly > (and who needs subselects anyway?). Hate seconded. I certainly don't wish to imply that RoR doesn't have buckets of hate, though I don't have enough experience with it to know where the hate lies. As for that "RDBMS", I was one of those laughing the loudest when the hurried work on those silly transactions meant that the previous world-beating benchmarks were dragged down to the level of other products with considerably more sensible designs. With version 5 they may actually get up to the feature set of a 15-year-old version of Oracle, though only by merging with another similarly-aged product (SAPDB). They'll still need to work on those horrid "reliability" and "data resilience" features that, for some reason, people keep demanding. -- Yoz
From: Sean Conner
Date: 00:31 on 27 Dec 2006
Subject: Re: perl
It was thus said that the Great Yoz Grahame once stated:
>
> The many slightly-different invocations, the module-driven Perl
> variations and basically all the TMTOWTDI-ness is great for
> flexibility but it is also deeply, deeply hateful. Firstly, for what
> it does to both The Principle Of Least Surprise; secondly, for the
> amount of brain-space I need to allocate to being able to handle all
> the different ways I will encounter of doing the same fucking thing.
THANK YOU! That's what I was trying to get across---Perl violates the
Principle of Least Surprise ("What do you mean I can't pass file handles?").
> As for language hate: how come nobody's mentioned PHP yet? Because,
> fucking hell, do I have some SERIOUS bile worked up there...
Oh God! I'm having flashbacks to osCommerce ... aieeeeeeeeee!
-spc (help)
From: Jonathan Stowe Date: 13:25 on 28 Dec 2006 Subject: Re: perl On Tue, 2006-12-26 at 01:09 -0800, Yoz Grahame wrote: > > As for language hate: how come nobody's mentioned PHP yet? Because, > fucking hell, do I have some SERIOUS bile worked up there... Dynamiting Turkeys in a barrel seems so unsporting at this time of year .... /J\
From: Peter da Silva
Date: 12:48 on 22 Dec 2006
Subject: Re: perl
> -spc (And least you think otherwise, there's plenty to hate in C,
> but I'm
> afraid I've lived with it long enough to subconsciously work around
> its quirks ... )
Oh, let's dredge up some luscious C hate.
/* Comments /* Don't nest */
Which is doubly hateful when some bugger does a compiler that
implements nested comments, so you have to start finding places where
someone's commented out a declaration like so:
/* int i; /* index */
And change it to
#if 0
int i; /* index */
#endif
Except that another bugger has done this with a compiler that does
nested comments somewhere else so their code looks like
/* int ilTruc; / * il'Tuccadore (the man of 1000 faces) */
and now you have
#if 0
int ilTruc; / * il'Tuccadore (the man of 1000 faces) */
#endif
Which works fine (except that people who name variables after obscure
jokes in Discworld books need pointy hate inserted nasally), except
when you hit a compiler that follows Allman's design rather than
Ritchie's and tokenizes the code inside #if...#endif instead of
whacking it out in the preprocessor, and that "'" gives it conniptions.
So now you have to go back through the code again...
BUT AT LEAST NOBODY OUT THERE IS SAYING THAT THIS IS A GOOD IDEA
I hope.
From: Aaron Crane Date: 19:00 on 22 Dec 2006 Subject: Re: perl Peter da Silva writes: > Oh, let's dredge up some luscious C hate. > > /* Comments /* Don't nest */ Unlike in PostgreSQL, where C-ish-syntax comments _do_ nest: /* SELECT foo FROM /* XXX: need better table and column names */ tbl WHERE bar = '/*'; */ Oh, hang on, that doesn't help at all. Consider this a hate for PostgreSQL's not-quite-C comments. HEY, LANGUAGE DESIGNER! DON'T ALLOW COMMENTS OF THE SAME SYNTAX TO NEST! Now, a C implementation that warns you when it finds a /* sequence inside a /*...*/ comment is definitely a good thing. I might even go so far as to describe as hateful an implementation that doesn't do that by default. Even better would be for the language to forbid /* inside a /*...*/ comment, but that's another story. > #if 0 > int ilTruc; / * il'Tuccadore (the man of 1000 faces) */ > #endif > > Which works fine [...] except when you hit a compiler that follows > Allman's design rather than Ritchie's and tokenizes the code inside > #if...#endif instead of whacking it out in the preprocessor, Such a compiler is buggy. There's a reason the standard says the compiler must behave as if it goes through the various processing phases in order.
From: peter (Peter da Silva) Date: 22:02 on 22 Dec 2006 Subject: Re: perl > Such a compiler is buggy. There's a reason the standard says the compiler > must behave as if it goes through the various processing phases in order. The reason the standard says that is because people like me have already suffered through the hate of dealing with compilers that did things like that because there was no standard that said they shouldn't. This is vintage hate, hate bottled in a time when the world was younger, and simpler, and if anyone had told us we'd be hating some of the things we're hating now we'd have looked at them and said something like "Star Trek isn't reality, nobody would EVER be so stupid as to do THAT". Hate like that you don't let go of all at once.
Generated at 10:25 on 16 Apr 2008 by mariachi