[ Sorry to fall off the net for several days . . .]
On 6/13/07, Larry Wall <[EMAIL PROTECTED]> wrote:
On Wed, Jun 13, 2007 at 05:08:34PM -0400, Charles Bailey wrote:
: I'm concerned that the relevant precedent isn't just Perl5. The ?: spelling
: of the ternary is pretty deeply embedded in programming languages -- I'm
: hard pressed to think of a widely used language in the past 10-15 years that
: spells it differently (though that may say more about my experience than the
: universe of "widely used" languages).
It's really just the C-based languages. Lots of popular languages don't
even give you a conditional operator, and seem to get by okay without it.
Granted, but that's 8 of the top 10 languages on the current TIOBE list.
Lies, damned lies, and statistics . . .
That had to be one of the main design considerations for Perl 1, but now
we've got the "design capital" to fix some things. The Perl 6 mandate
is not universal compatibility (which Perl 5 still represents in a
way), but the chance to fix everything that needs fixing. And this
one of the things I think C got wrong. Perl 6 is looking more for
You may well be right here -- you're certainly more qualified than I
in language building -- but this line of reasoning leaves me with
something of an uneasy feeling. I'm not sure Perl6 has all that much
of what I'll call "practical design capital", by which I mean ability
to change practice by making new ideas common usage. I'm
distinguishing that from what I'll call "formal design capital" -- the
ability to change practice by having good ideas to which people will
listen -- of which I think Perl6 has a good amount.
I think this distinction can be important for several reasons, not the
least of which is that they may antagonize one another. I'd argue
that Perl's FDC arises from its current widespread acceptance, showing
that many people think it currently implements "good" solutions to
some of the problems they need to solve, and from the respect given to
[EMAIL PROTECTED], because they've implemented those solutions, discussed them
intelligently, and are in general good people. This sort of capital
works best for big ideas, whether by putting them out for discussion
(read: persuasion), or by implementing them in a new language.
OTOH, I'd argue that PDC is more of a transient phenomenon, and arises
from the comfort users have with the language, whether it's that it
"feels natural" overall, or that they recall being able to accomplish
some necessary task(s) easily or elegantly. In some respects, it's
the net-equivalent of "what have you done for me lately?" I think
Perl 6 has less of a reserve here, partly because of its long
gestation, partly because of its informal reputation as a small step
up from APL in readability (cue the JAPH culture), and partly because
of its reputation for being disorganized and unsecure. (As an aside,
let me take pains to emphasize -- this being email -- that I am not
arguing that these claims are true, not that, to the extent they're
true they're Perl's fault. Nonetheless, they exist, in the minds of
potential users, and of the managers/vendors/spinners that specify
what language choices are allowed.) I also think that one wins or
loses in this arena as often due to the little things -- whether
something is easy and intuitive -- as to the big things -- whether
something is possible and clean.
Why do I belabor the obvious so? Because I think the discussion about
the ternary operator, like several others recently on these lists,
might be conflating the two, and might be missing an opportunity
thereby. In some cases, Perl6 will want to be the language on a
hilltop, beckoning others to follow into the land of elegance and
orthogonality. But there's also something to be said for ingratiating
and subverting. That, in turn, implies that there will be cases where
it's better to make a suboptimal choice in a small matter -- not
sacrificing major principles, and not jumping through hoops inside the
box to save the user two keystrokes, but inculturating in order to
better be able to make the really important points.
Whether ?: is a better choice in this respect than ??!! is perhaps a
matter of taste, and I'm not going to argue that either is the
Platonic spelling of the ternary operator. As best I can articulate
it, I think I'm arguing for a more explicit balance of "better" with
"comfortable" in making these choices.
I don't mean by any of this to devalue the extensive community input
into the early stages of Perl6 design. If anything, I may be
undervaluing it, since it occurred during a time when RL required that
I essentally drop out of the Perl community, and I missed much of the
detail. I also don't mean to ignore the ongoing input via these
lists, and I'm sure several other channels. It's also true that at
some point, to get a working result, The Cabal has to make design
decisions whether or not The Masses have come to consensus. That can
be hard for both sides, because any self-respecting Cabal has good
communication internally, and exchange with the rest of the world can
sometimes (actually|appear to) fall off.
semantic and pragmatic compatibility than syntactic compatibility.
We won't have to teach anyone the *idea* of a conditional operator,
just send them off to look for the green bikeshed.
To follow this metaphor, I think that outside the real disciples,
Perl6 will get N bikesheds, for some small value of N, before a user
wanders off to another locale where she doesn't need to consult the
map so often.
Certainly, all other things being equal (give or take), we'll go
for something familiar. And I'll say we even put a thumb on the
scales in favor of what Perl 5 programmers expect, now and again.
But sometimes it's still right to break something, and reduce the
level of compatibility concern down to just making sure they get
a good error message if they fall into old habits. In that case
it means making something different enough that the old one can be
recognized and dealt with. At some point you put the new wine into
new wine skins and throw the old ones out.
Absolutely. And Perl6 provides a singularity where it's possible to
get a bunch of new wine skins into service. But where the old
wineskins still hold, er, wine, we might think twice about using the
newfangled double-stitched skins.
Ironically, specific error messages will probably cut both ways. It's
nice to be told what the likely error is, but some subset of readers
will respond, "If you knew what I meant, just do it!"
It's not really that common, compared to, say, assignment, which you'll note
we've pretty much left untouched, except for relaxing the requirement for
parens on the right side of list assignment.
Yep. For that matter, if I had to pick one change in this area that'd
have maximum impact, I'd say a good assign-if-uninitialized idiom
would be way ahead of an if-then-else idiom.
: <paranoia>There's also the less important social problem that Perl6 has
: already spent a lot of goodwill in its long gestation. I think it can be
: earned back by doing things well, because they've been thought through
: carefully, but the language will be viewed with some initial skepticism.
I would like to think that "doing things well" is exactly the approach
Of course. Again, the medium may be garbling things here, or it may
just be my lousy writing. I'm certain that everyone in the discussion
is trying to do things well, and that @Larry's version of well is
pretty good. Hence Rule 1 works most of the time. But it's nice to
have Rule 2 around, too.
we're taking. We're not optimizing for the past, but for the future.
This might rehuffmanization of everything might influence more
generations of computer language than we can possibly imagine.
It could (I hope). But I also want to be careful we're not building Esperanto.
Certainly. The main problem is not so much that ? is ambiguous,
but that the : is. It's somewhat ambiguous with labels
(though arguably those don't generally occur in the same context).
The killer is that it's formally ambiguous with the colon that is
used to indicate the list of an unparenthesized method call (in either
direct or indirect form). That colon occurs where an infix is expected.
It's also ambiguous with adverbs, which can occur in that position
when modifying a preceding operator, as in 1..100:by(3). The fact that
?: tends to be used as one term in an expression means that things tend
to be written compactly without spacing, which amplifies that ambiguity.
ObTopic: I'm readily convinced that the special-casing needed to get
the : in ?: right wouldn't be worth it, on balance.
On the plus side, the fact that it's the : and not the ? that is most
problematic means that (unless the user adds their own infix:<?>) it's
pretty easy to recognize the old usage and give a good error message at
compile time. And I think that's all that's really necessary here.
It's the differences that silently produce an unexpected result
that we'll really need to worry about in terms of user satisfaction
and FAQ minimization. That's also why there's no infix:<.>, so at
Concur that it's the larger issue. Respectfully dissent (if it's at
all what you meant) that pointing out the error of using a borrowed
idiom is as much as is needed. It may be the best we can do, but I
like to think of it more as caving in to necessity than as meeting my
goal.
These are the everyday worries of a language designer. Well, me anyway...
I appreciate your taking the time to discuss this. To the extent that
my comments weigh heavily, feel free to sprinkle smilies as needed, or
just junk the whole thing. Otherwise, thanks for letting me take my
turn as Chicken Little.
--
Regards,
Charles Bailey
Lists: bailey _dot_ charles _at_ gmail _dot_ com
Other: bailey _at_ newman _dot_ upenn _dot_ edu
