Chris Dutton wrote:
> So many operators...
Well, this seems a good as time as any to jump in with what's been
sticking in my brain for a while now. Last June, Simon C. wrote a
little philosophical thing, "Half measures all around", which generated
the appropriate amount of good discussion. I want to try and make a
case that's sortof tangential to that, but not, at the same time.
Here's my own argument for using "like/unlike", and "none", and a bunch
of other english-sounding things we haven't even talked about yet.
My general background is in tutoring/mentoring/educating/evangelizing
"new" programmers, where "new" either means new to programming, or new
to Perl5, or both. That's my little niche -- taking newbies, and
shoving them up the curve until they know the ins and outs. Pretty
successful at it too, I think. I mention this only because it seems to
be different from the experience of much of perl6-lang ... most of the
people here seem to be more of the "expert" level, people who you call
because they know Everything Perl, Always. :-) I'm typically more
focused on the beginning-level people.
Premise: So far, we've already gotten Perl6 to be much more powerful
than Perl5, and cleaned up a few of the more troublesome perl5
inconsistencies, but I don't think we've put much of a dent in the
"readability" complaints that non-perlers often voice (and we all know
I'm being generous in my phrasing, there.) I think we need to care
about these concerns a _lot_ more than we have in the past, simply
because of the cynical but obvious linkages:
1) I want to use Perl6, because I am confident that I can program
things faster in Perl6 than in any other mainstream language.
2) I only want "good" Perl6 programmers, so I don't give a, um, 'darn'
how much of the random population uses Perl6 in general, BUT...
3) The general population won't use it unless they can easily
understand it through self-study, and/or have been exposed
to it in an educational setting.
4) Joe Manager of Company X won't use it unless he can find
lots of programmers in the general population that know it.
5) If none of the Joe Managers in the other companies use it,
suddenly it puts a lot of pressure on me to explain why *we're*
using it, instead of, say, Java or C#. "It's better"
doesn't really fly, because the company's non-technical
staff judges "better" based primarily on the number of
magazine articles that mention the language.
6) Suddenly, my staff using Perl6 becomes a political issue, not a
technology one. I fight the battles, eventually quitting
the industry in disgust and moving to the California desert
where I put up "no trespassing" signs, dig a series of
inexplicable washing-machine sized holes, and wait for
the impending collapse of human civilization.
OK, that's why we care what the world thinks. Back on topic: so far
we've got conciseness, and a feature set that's essentially the
best-practices compilation of modern, successful programming concepts.
Pretty darn nice.
But understandable, we don't have yet.
Understandability in the large, certainly, is a matter of being able to
express common and/or complicated concepts in a concise enough way to
make the "big picture" of the program visible. So even though Perl6 is
full of nasty constructs such as '^.|=' and similar, I would argue that
(1) things quite that bad will be reasonably sparse in real programs,
and (2) they comprise so much functionality in such a little package
that the overall "flow" of what's happening in an algorithm is much more
understandable. Hence we have all hyperoperators, for example -- just
too much utility there *not* to do it.
But our version of "understandable" still means a steep, steep learning
curve. We need to soften that a bit more for the common cases. My own
solution would be, in part, that we offer english-word aliases like
"like", etc., even if they're only meant as training-wheel versions of
the more linenoisy things, wherever we can. So people can be trained on
the words, and graduate to the "professional" constructs as they become
more comfortable.
My bigger solution would be to reserve a lot more english-sounding
barewords, in all forms, towards the goal of making well-understood
concepts more obvious to newcomers. That's why I've been pushing for
architecturally unnecessary things like using "on" for events/callbacks/assertions:
my $v on get { ... }
on set { ... };
....or using constructs like 'as' and 'from' to do very smart, but very
in-your-face-obvious casting/transformations between types/classes,
instead of relying on more ambiguous constructs:
class MyClass {
from OtherClass { ... } # 'alternate' constructors
from int { ... }
as int { ... } # 'typecasting' multimethods
as str { ... }
as OtherClass { ... }
}
my MyClass $obj = MyClass.new;
print $obj; # as string
print $obj as int; # as int
....or even to just have the inclusion of more non-property properties
and other keywords, because they DWIM:
class MyClass is singleton;
cmethod class_method { ... }
method instance_method { ... }
my hex $i; # with built-in (de)serializers
.... even though there are other, more logically "correct" ways of
accomplishing the same things. [*1] Sure, we don't *need* those words,
but they're only a few extra chars, and they express rather fundamental
concepts in one-word English, instead of relying on knowledge of
canonical and/or punctuational constructs to build the same. Does it
complicate the grammar? Yes, a little. But maybe for some things,
TMTOWTDI isn't the right answer. Maybe some concepts are so universal
that there _should_ be a "best" way to do it, and a word that means it.
So this isn't a rant, exactly (read the preface of the POOC [*2] to see
just how much I like perl6 already) but I do think we need to
occasionally remind ourselves that the people on this list do *not*
represent the skill levels of the general population, and we *need* the
support of the general population. If we have even a slight bit of
trouble with something, heaven help us when we try to explain it to the
rest of the planet.
When I've been writing my dribbles of draft documentation, I've been
going to great lengths to explain concepts using as few big words as
possible, and it's really, really hard. I think we can make it a little
easier by having the language itself use as many of the little words as
possible, and explaining them as english-esque constructs instead of
programmerspeak. So lets have _lots_ of operators, and _lots_ of
two-to-four-letter barewords, so long as they each do something Big, or
something Universal. And let's locale-ize them, so that
non-english-speakers can use 'umu' to mean 'bool', etc. Hey, why the
heck not?
OK, philosophical ramblings over. Thanks for listening. :-)
MikeL
[*1] Am I emotionally attached to any of my own suggestions? No, not
really. I just want to document and use the end result; I don't care
how we get there, or even quite where "there" eventually is. If you've
been following this list, you know that 90% of the postings --even
Larry's stuff-- are just stream-of-conciousness things that are
sometimes scary, but are just thoughts, so nobody should freak out
because of anything they see here, unless and until it's Final.
[*2] http://cog.cognitivity.com/perl6/
