Perl is worse!

[Alex Martelli]

"Steve Lamb" <grey at despair.rpglink.com> wrote in message
news:slrn8o6lo2.f91.grey at teleute.rpglink.com...
> On Sat, 29 Jul 2000 13:53:02 +0200, Alex Martelli <alex at magenta.com>
wrote:
> >Yes, so the latter is best when you have a single format you want to
> >apply to several different variables at various point, the former is
> >best when the names are fixed.  That's why Python supplies both.
>
>     Excellent description except for one thing, I never said that the
variable
> names were fixed.  Take a look at Perl's ##foo, for example.  Well, more
> accurately ${$foo}.  Again, just taking a pseudo-code, not a real lanauge.

The 'soft-reference' where a variable holds the _name_ of another
variable?  As I understand it, it's deprecated, Perl texts suggest
you don't use it, and use strict (which is strongly suggested)
cries to high heavens if you do use it.  I would not take it as
something Perl experts consider a particularly good idea, then.


> >    "Here is a very %(adj)s %(noun)s!"
> "Here is a very $$adj:$format $$noun:$format!"
> >    "Ecco una %(noun)s molto %(adj)s!"
> "Ecci una $$noun:$format molto $$adj:$format!"
>
> >    print format % {'adj':adjective1, 'noun':noun1}
> >    print format % {'adj':adjective2, 'noun':noun2}
>
>     print format
>
>     Adj and noun need to be assighed in either case.  Except when we do it
> inline we can see what formatting goes with what.  It really is semantical
in
> nature since there is no different at all in function that I can find.
The

When the format string is expressed as an inline constant you can see it in
place, but you don't have the other advantages (such as
internationalization,
and assurance that the *same* format is used in N places, without having to
edit each place with the utmost care each time a change is specified) that
only come with obtaining the format-string through a variable.  The second
class of advantages generally dominate in larger programs.  But on these
axes there is indeed no important difference between Python's exact syntax
and the hypothetical one you suggest (most definitely, NO _semantical_
difference: semantical="related to meaning"; do you mean syntactical?).

The advantages of referring to an explicitly specified dictionary (mapping
object) rather than force the reference to be always and only to the
implicit mapping-object variable_names->variable_values are however
multifarious.  Several bindings (mapping objects, dictionaries) can be
easily maintained and passed around, with choice between them taken at
whatever moment is desired, up to the very last moment; the same thing
is horridly cumbrous to do if the implicit vars() mapping is the only
one you can use.  For example, say the two outputs may themselves need
to be made in the reverse order; then, having the two dictionaries
in a 2-element sequence, you only need to arrange to have either (0,1)
or (1,0) in another variable, and use a for loop over that variable.

Encoding such aspects in data is most often handier than expressing
them in code, which you'll need far more frequently if the tools you
have always necessarily make reference to the implicit mapping that
variable-names encode.  (That's part of why 'eval' is needed much more
often in Perl than in Python, by the way, as soon as a program gains
any heft and/or need for 'solidity'; but these are other issues).

> only difference is having to match up what is at the end of the string
with
> what is right there where you're looking at the moment.

When you end with % vars(), there is no substantial difference.
When you use the more substantial flexibility allowed by using
other mapping-objects, if that flexibility is needed, then the
advantages are many -- see above for a *beginning* to them.


> >> "%d:0:0 %c:U %s %s %s %s %d %s %s %s \
> >> %d:0:0!",$a,$b,$c,$d,$e,$f,$g,$h,$i,$j,$k
>
> >>     What variable goes with what again?
>
> >Yes, a format-string with named-placeholders does help with that, too.
>
>     But not as much as just having the variables in line with the
formatting
> where reading is still the natural left to right (for us natives of
European
> lanauges) with all information presented where it must be.

I'm a European native, too, and I disagree with your contention
that there is any substantial difference.


> >I'm very happy not _having_ to invent some arbitrary name when what
> >I want to do is output one or more arbitrary expressions, computed
> >on the fly, for example.  Naming has its place, but so does quiet
> >anonimity...:-).
>
>     Why do you need to place them at the end?

For many reasons, above all the need to distinguish and separate
_computational substance_ from _presentation_ -- as most obviously
shewn on the web, where far too many site-authors that just do not
understand this issue have made such an utter mess of things.

Presentation style in ONE place (be it a style-sheet, or a humble
format-string), computational content in ANOTHER (scripts, formulas,
expressions), makes each easy to edit, maintain, develop, and
reuse separately.  Mixing them up too much just makes a mess.


> "1 + 1 = ",1 + 1:0:0, ",really, it is!"
>
>     Again, fake language.  I don't see a need to have placeholders for
simple
> statements at the end when you can place those statements in line.

Apparently, you're very, VERY keen to never sell your software
anywhere except English-speaking markets, and, even there, strive
to make life as hard as possible for the technical writers that
are responsible for maintaining the text you present to the end
user, which are not the same people who maintain the program's
computational parts and should not have to delve into the code
of that program.

Most of us would just as soon keep things more flexible and
usable, with a format-string with place-holders, that can most
easily be moved to a separate file (where specialists can edit
it, internationalize it, etc) and fetched from there at need.

But even then, your fake language appears to have very strange
problems in order to offer you the disadvantage of mixing things
up that way.  Specifically, the flags and numbers related to
string-formatting end up mixed with the syntax of other kinds
of expressions.  You will therefore need to use more special
characters, distinct from those used for all other operators,
as well as lots of rules about precedence and grouping.  This
smacks to me as lots of ad-hoccitis, hard work, and complexity,
all for no benefit at all (indeed, the reverse).

I suggest you go ahead and fully design the fake-language of
your dreams, implement it (Python makes that pretty easy,
exactly because it has so LITTLE ad-hoccitis & complexity!),
and use it for a while.  I suspect this will give you much
keener insight and clearer perception of the issues that
are involved, one way or another; i.e., such experience will
by no means nevessarily change your opinions to make them more
similar to mine (many language designers and implementers have
all sorts of differing opinions on this, clearly -- just look
at the huge variability in languages' approach to formatting)
but at the very least it will give your opinions sharpness
and founding, which at this time they lack.  (Like most people
in our field with decades of experience, I've had to design
and implement several special-purpose languages of various
scope along the years, and, having essayed all flavours, I
now consider format-strings, particularly Python-like ones,
quite preferable to variable-by-variable formatting, e.g. the
mainstream-C++ approach; and note that I use C++ even more
than Python, so, once again, it's NOT an issue of "what I'm
[most] familiar with", but a well-rooted technical evaluation
of the pro's and con's of the many alternatives).


> >Could be (I _am_, after all, a well-known sadomasochist!), but, if
> >it were that, I think I'd be programming in C shell (hard to think
> >of a more painful way to make a living; and yet there _were_ people
> >writing scripts in it rather than the somewhat-less-painful Bourne
> >shell, for reasons I've always found utterly unfathomable...).
>
>     ESC-P comes to mind.  I find all shell scripts horrible.  Any time I
need
> to work on one I take the basic logic and rewrite in Perl.  Less need to
have

That's what I would have liked to do, but often couldn't because
Perl might not be installed on some target-machines, sigh.  At
least, Bourne-shell could be counted on at the time.

> to worry about globbing and proper escaping of everything and handing
> different input/output expectations from different programs.  Sure, I'll
use
> grep on the command line but I'd rather see while(<>){m//;} in the script,
> thank you.

You're welcome.  But

for line in fileinput.input():
    if cre.match(line): print line

currently makes me even happier:-).


Alex