Michael Lazzaro wrote: > 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. > > ... I don't think we've put much of a dent in the "readability" > complaints ... I think we need to care about these concerns a _lot_ > ...
I agree that this is an important concern which should be addressed. > 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. However I believe that having English aliases would make matters worse. They would make the language bigger. That's more to learn over all. There is already lots to learn in Perl, and I think having unnecessary duplication would make that even more work. Beginners would not need to learn the symbolic versions for writing their own code, but they'd need to be able to read the symbolic versions for reading other people's. And given how many people first encounter Perl by downloading somebody else's script from the web or by being thrown into maintenance of something written by a former employee, being able to read others' code is important. It's also slightly patronising. "We don't think you're good enough to play with the punctuation characters yet, but here's some alphanumerics to use instead." Would people submitting code in public forums get labelled as newbies because they've chosen to use the lettered versions? Would gurus who know the punctuation forms use the English versions so as to make their code more readable for beginners? Would this actually help beginners or merely make the situation worse when they finally do encounter the punctuation forms? Having exact synonyms also violates the principle that similar things should look similar. On encountering something 'new' in a program I would expect it to do something different. If I see C<+&> and already know that C<+> means numify in Perl and that C<&> is bitwise and in C (etc) then I might be able to guess that C<+&> is numeric bitwise and. But if I thought that I already knew that the symbol for that operation was C<numbitand> then I'd be less likely to guess the meaning of C<+&> cos I'd be searching among the space of things I didn't already know how to do. Finally, what happens to C<&&> and C<and> and friends? If they become synonyms we lose a convenient distinction. If they remain as they are we have a language where many ops have synonymous symbolic and English forms for 'ease of learning' but a few instead have precedence differences. If we come up with an English synonym for C<&&> and a symbolic synonym for C<and> I don't think that'd really help. This is only objecting to having English operators as synonyms for symbolic ones. None of the above would apply if where English forms were used they were to be the _only_ forms, with no symbolic equivalents. > 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. I think that makes sense where there are appropriate words to use. However many of the concepts we're dealing with don't have obvious everyday-English equivalents. "Numbitand" certainly isn't an English word. Even for concepts such as map and hash I don't think the English word is a great help to many beginners: they know maps as things you look at to get lost when driving, and merely have to remember that Perl uses map mean 'like a loop but giving a list of values'. I wouldn't like to speculate on what they know as hash, but again it's a jargon word with a specific meaning in Perl largely unassociated with anything in real life. We're talking about having lots of operators in Perl 6. There are potentially twenty-four different or operations[*0]. I don't think there are twenty-four different English words which can usefully denote those meanings in a memorable way. At least combining symbols means that patterns can be learnt. That makes me sound against having English operators at all. I'm not. I agree that well-chosen English words will be more readable for beginners and that that is a good thing, even if it means some gurus having to type four letters instead of two symbols[*2]. But I can see it being hard to solve in some places. *0 Logical high precedence, logical low precedence, superpositional, numeric bitwise, string bitwise (that's five), all with exclusive-or variants (ten), plus the or-defined variants at two levels of precedence (twelve) all of which can be hyped[*1] over a list (twenty-four) *1 I'm not sure that "hyped" is the correct verb here for "applied over a list with the hyper operator", but it sounded better than "hypered". *2 Which when you take <Shift> into account, and the fact that punctuation symbols seem to move around on keyboards when you aren't looking, isn't really any more. Smylers
