Front page | perl.perl5.porters |
Postings from March 2000
Re: hook for qs// operator for embedded SQL?
Thread Previous
|
Thread Next
From:
Joseph N. Hall
Date:
March 20, 2000 01:52
Subject:
Re: hook for qs// operator for embedded SQL?
Message ID:
MailDrop1.2d7j-PPC.1000320025302@perlfaq.com
* So it looks like you want to define your qs function to have a
* sprintf()-like first argument:
*
* @result = qs("select %a from %t where %c = %v", \@cols, $table, $col,
* $val);
*
Why you would say that I "want" that when clearly I don't?
* You don't
* need any new syntax; you need new semantics, and that can be wrapped
* in what I've been calling the qs() subroutine.
No, I specifically said I wanted a new quoting operator, and that means
new syntax. Why not just say "I reject the notion that Perl needs any
more syntax" and just be honest about it, if that's what you really
feel. I don't need ideas on how to program with existing Perl. I have
plenty of those.
If this is going to be stuck at the "here's a more inconvenient syntax
that does the same thing" level, as many discussions in p5p apparently
are, you know, I could just use Lisp. That's one thing when you're
talking about closures and pseudohashes, but I'm talking about one
feature in particular and more broadly about features in general
that make the language more accessible to vast numbers of people.
Whatever. It's just a suggestion. If you can't see the merit in
bringing Perl as close to Embedded SQL as possible, where syntactic
convenience is THE primary motivation, then you'll never get the point
of my argument. If you don't buy the notion that "let's think of a
syntax that makes this as convenient as possible" is a valid starting
point, I can't say anything to you that will make any sense.
And it's not for "me" anyway. It's for the hordes of users who are
looking for more and more convenient ways to talk Intergalactic Dataspeak.
DBI is fairly straightforward for semi experienced Perl geeks, but
it's pretty weird for another crowd of people who don't come from
a procedural/structured programming background and don't really see
the gain in picking up references and objects and yada yada in the
process. Personally, I'm all for making Perl useful for people who
don't fully understand it, by making it easier to fully understand
parts of the language.
Versatility and completeness isn't the goal I'm trying to promote.
Simplicity is. If this were all about what's possible we would, as I
said, be speaking Scheme. Not everyone thinks printf is cool. Some
people might even like to see formats turned into something modern and
useful. God knows I hate teaching them but that's just because they're
half-assed by modern standards. But there's a reasonable class of
users who would benefit greatly from fully-functioning built in formats
that obviate the need to learn printf.
The past few hundred Perl students and readers I've interacted with
have helped me understand that "There's More Than One Way to Do It"
has many meanings, one of them being "There's Ways to Do It That Seem
Plain Stupid to Me, But Wonderful to Other Folks." And I've learned
to recognize the virtue in that, as I *believe* that the original
creator of the language did long before I developed the same full
set of clues.
Can I cast my vote in favor of ||| while I'm at it? I'm sick of coding
around its absence and introducing bugs with
$foo = $ENV{might_usefully_be_0} || 'default' in the meanwhile.
I saw the core of Perl bloat, what, 50-100% in 2-3 years between 5.005
and 5.6, seemingly adding no major new features, and in the meanwhile
here's AOLServer with TCL running screaming fast with threads in tiny
amounts of RAM, and Perl has no answer to that except "threads blow up
less often now, and Perl doesn't leak a whole lot of memory or lose
track of too many global variables." Nor does Perl let me build a
"static linked executable-like thing that doesn't require an exact copy
of my module tree." And there's this "our" thing that was the butt
of an entire evening of jokes in #perl.
I'll be happy to discuss qs//-like things with people who aren't trying
to convince me that I didn't really mean "create new syntax," but
I'm not going to get into the "NO NEW SYNTAX, IT BLOATS THE CORE AND
YOU DON'T NEED IT ANYWAY" argument, (1) because I don't buy it, (2)
because Perl has bloated anyway, (3) because I don't develop Perl and
it's not my job to carry a torch for the enhancement of the language if
its developers don't believe in user-visible enhancements, and (4)
because Perl has acquired new syntactical thingies like "our" that
are more useless and obfuscated than anything I would ever suggest.
I've digressed, but ... so there.
-joseph
Thread Previous
|
Thread Next