Re: use English
On Apr 27, 2005, at 6:39 AM, Aaron Sherman wrote: On Tue, 2005-04-26 at 10:48, Luke Palmer wrote: Aaron Sherman writes: The reasons I don't use English in P5: * Variable access is slower Hmm, looks to me like $INPUT_RECORD_SEPARATOR is faster. (Actually they're the same: on each run a different one won, but just barely like this). Remember that I'm a Perl 3 programmer who has just gotten used to this 5 thing... ;-) I sometimes lose track of the ugly hacks that have been rationalized into workable practice over the versions. use English used to require an extra level of indirection in the implementation, but clearly no longer does. I don't have a perl older than 5.6.1 to test against, but this was probably back in the 5.002 or 5.003 timeframe. I'm guessing. It is also the fact that English.pm mentions $' and $` and that any mention of those variables flips a global switch inside perl which causes *every* regex with capturing parens to be slower. See http://search.cpan.org/~nwclark/perl-5.8.6/pod/perlvar.pod#BUGS Graham.
Re: use English
On Wed, 2005-04-27 at 14:38, Luke Palmer wrote: There's still a lot of premature optimization going on [...] I'm surely guilty of one of them. I feel like the autothreading semantics of junctions will be way to expensive without the compiler knowing whether there a junction in a particular variable. Well, more to the point, autothreading of junctions will hit the wall of Parrot duping the interpreter. That's probably not something you want to suffer just to resolve a junction, is it? I suppose it depends on how snarled the junction is -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: use English
Aaron Sherman writes: On Wed, 2005-04-27 at 14:38, Luke Palmer wrote: There's still a lot of premature optimization going on [...] I'm surely guilty of one of them. I feel like the autothreading semantics of junctions will be way to expensive without the compiler knowing whether there a junction in a particular variable. Well, more to the point, autothreading of junctions will hit the wall of Parrot duping the interpreter. That's probably not something you want to suffer just to resolve a junction, is it? What? Why will it do that? Luke
Re: use English
Aaron Sherman wrote: As a side note, I'd like to suggest that English is just rubbing people's noses in the fact that they're not allowed to program in their native tongue. Names might be less in-your-face. Why are we even having to say use English or Names or whatever? Why not just make it a part of the core alongside the original short special var names? In my opinion the short version of special vars is one of the worst features of Perl, despite the fact that I like concise code. But then again, I'm not a golfer. Marcus Adair
Re: use English
On Thu, 2005-04-28 at 13:52, gcomnz wrote: Aaron Sherman wrote: As a side note, I'd like to suggest that English is just rubbing people's noses in the fact that they're not allowed to program in their native tongue. Names might be less in-your-face. Why are we even having to say use English or Names or whatever? Why not just make it a part of the core alongside the original short special var names? In my opinion the short version of special vars is one of the worst features of Perl, despite the fact that I like concise code. But then again, I'm not a golfer. Of course, you're right, and Larry and others have made this point repeatedly. I can be a tad thick from time to time ;-) -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: use English
On Tue, 2005-04-26 at 10:48, Luke Palmer wrote:
Aaron Sherman writes:
The reasons I don't use English in P5:
* Variable access is slower
Hmm, looks to me like $INPUT_RECORD_SEPARATOR is faster. (Actually
they're the same: on each run a different one won, but just barely like
this).
Remember that I'm a Perl 3 programmer who has just gotten used to this
5 thing... ;-)
I sometimes lose track of the ugly hacks that have been rationalized
into workable practice over the versions. use English used to require
an extra level of indirection in the implementation, but clearly no
longer does. I don't have a perl older than 5.6.1 to test against, but
this was probably back in the 5.002 or 5.003 timeframe. I'm guessing.
When will you people stop caring about speed that doesn't matter.
This matters. I'm not going to switch around all over the place, I'm
either going to use the English names everywhere or the punctuation
names everywhere, not a mix of both -- THAT would be terribly unreadable
-- and back when that access hurt (I did measure it), I could not have
afforded to use the English variables in tight loops. For example:
while() {
if ($. == 1) {
print Header: $_;
}
$total += $_;
if (eof) {
$. = 0;
}
}
This was the very sort of thing that convinced me not to use English
back in the day, when I measured performance of one reporting program
with and without English variables. I found that with them it took about
10 minutes longer than without. Without won.
Ever since I stopped caring about speed, I've started to write code
almost twice as fast. And the code itself isn't slower.
Ok, so let's separate the premature optimization from removing massive
bottlenecks from code. When I can get a reporting program that takes
30-60 minutes to run to drop 10 minutes in execution time, I'm going to
do that. This is NOT premature optimization.
What you describe is what Knuth has also described. You should never
worry about trivial details of optimization while writing the minutia of
a program because a) you don't know if that bit of code will even exist
in the final version b) the optimization might be better accomplished at
a higher level c) you might be PREVENTING optimization opportunities at
a higher level!
And I promise, that will never be somewhere where the difference between
$/ and $INPUT_RECORD_SEPARATOR matters.
It used to be. Clearly the ugly hack that was use English has been
fixed. Old lessons are not easily unlearned.
Either way this is not really about Perl 6, is it?
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: use English
Aaron Sherman writes: Ever since I stopped caring about speed, I've started to write code almost twice as fast. And the code itself isn't slower. Ok, so let's separate the premature optimization from removing massive bottlenecks from code. When I can get a reporting program that takes 30-60 minutes to run to drop 10 minutes in execution time, I'm going to do that. This is NOT premature optimization. Oh. Wow. That's, er, significant. I came into Perl right at the beginning of 5.6.0, so I can't say anything about this history. I couldn't imagine that a variable indirection could add that much to a segment of code. But if you say so... I retract my comment. Well, no I don't. I retract the fact that my comment was directed at you. There's still a lot of premature optimization going on[1]. Luke [1] I'm surely guilty of one of them. I feel like the autothreading semantics of junctions will be way to expensive without the compiler knowing whether there a junction in a particular variable. But I have nothing to back that fear up, it was just a gut reaction. And I fought pretty hard
use English
On Mon, 2005-04-25 at 22:24 -0500, Rod Adams wrote: Not exactly a fair comparison, since it's common to not use English due to the $ issue. I suspect that if that was not the case, it would be used more. The reasons I don't use English in P5: * Variable access is slower * Names like OUTPUT_AUTOFLUSH are painful * I remember $', $/, $\ more easily (that's probably just from having written code with them for 13+ years) Now, assuming P6 makes: $FUNKYNAME := $*; efficient, then my only real concern is how much of a pain these are to type. I'd really love to have names that are short (3-7 characters) and yet clear enough to justify using English. Let's look at P5 English, and see how that might look. Note that these are all regular variables (e.g. no $* noise), which is because an explicit call to use English would import these names to your namespace. P5 P6 $ARGok $MATCH ok $PREMATCH $BEFORE $POSTMATCH $AFTER $LAST_PAREN_MATCH $LAST @LAST_MATCH_END @POSEND $INPUT_LINE_NUMBER n/a $INPUT_RECORD_SEPARATOR n/a $OUTPUT_AUTOFLUSH n/a $OUTPUT_FIELD_SEPARATOR $FIELDSEP $OUTPUT_RECORD_SEPARATOR$RECSEP $LIST_SEPARATOR $LISTSEP $SUBSCRIPT_SEPARATOR$SUBSEP (already an alias in P5) $FORMAT_PAGE_NUMBER n/a $FORMAT_LINES_PER_PAGE n/a $FORMAT_LINES_LEFT n/a @LAST_MATCH_START @POSSTART $FORMAT_NAMEn/a $FORMAT_TOP_NAMEn/a $FORMAT_LINE_BREAK_CHARACTERS n/a $FORMAT_FORMFEEDn/a $ACCUMULATORn/a $CHILD_ERRORn/a $ERRNO $ERR (it's not just a number, POSIX aside) $EXTENDED_OS_ERROR $OSERR $EVAL_ERROR n/a $PIDgood (note: might be n/a if accessed through OO) $UIDgood $EUID good $GIDgood $EGID good $PROGRAM_NAME $PROG $COMPILING n/a? $DEBUGGING n/a? $SYSTEM_FD_MAX ? (will P6 have access to this?) $INPLACE_EDIT ? $OSNAME good (but might be in a separate module) $PERLDB ? $LAST_REGEXP_CODE_RESULT$RULEEVAL $EXCEPTIONS_BEING_CAUGHT? $BASETIME good $PERL_VERSION $PERL $WARNING? $EXECUTABLE_NAME$PERLEXE ARGV? $ARGV good, but probably ARGS ARGVOUT ? @F ? @INC? @_ alias: @PARAMS %INC? %ENVgood %SIGgood (but possibly different) As a side note, I'd like to suggest that English is just rubbing people's noses in the fact that they're not allowed to program in their native tongue. Names might be less in-your-face.
Re: use English
Aaron Sherman writes:
On Mon, 2005-04-25 at 22:24 -0500, Rod Adams wrote:
Not exactly a fair comparison, since it's common to not use English
due to the $ issue.
I suspect that if that was not the case, it would be used more.
The reasons I don't use English in P5:
* Variable access is slower
% perl -MBenchmark=timethese -MEnglish -e 'timethese(1e6, {
/ = sub { $/ = \n },
RS = sub { $INPUT_RECORD_SEPARATOR = \n }
})''
Benchmark: timing 100 iterations of /, RS...
/: 2 wallclock secs ( 1.41 usr + 0.00 sys = 1.41 CPU) @ 709219.86/s
(n=100)
RS: 1 wallclock secs ( 1.20 usr + 0.05 sys = 1.25 CPU) @ 80.00/s
(n=100)
Hmm, looks to me like $INPUT_RECORD_SEPARATOR is faster. (Actually
they're the same: on each run a different one won, but just barely like
this).
When will you people stop caring about speed that doesn't matter. Even
if $/ were faster, it would only be by a neglegable amount. Your
readability is a lot more important than a few clock cycles here and
there.
Ever since I stopped caring about speed, I've started to write code
almost twice as fast. And the code itself isn't slower. It's just the
fact that after I used to write every line, I would think is this fast
enough; could I make it faster?. I would even trip myself up,
abandoning projects because I couldn't find a fast enough way to do it,
or because my current implementation was too slow. But not by evidence,
just by judgement upon looking at the code.
Speed is important. And I'm a game programmer, so speed is pretty
important to me. I've found (and this is widely known, but perhaps
every programmer needs to discover it for himself) that it is hard to
tell where you will be spending most of your cycles. Once you know,
then you can go back and optimize it.
And I promise, that will never be somewhere where the difference between
$/ and $INPUT_RECORD_SEPARATOR matters.
Luke
Re: Macros [was: Whither use English?]
On Fri, Apr 15, 2005 at 12:45:14PM +1200, Sam Vilain wrote: : Larry Wall wrote: : Well, only if you stick to a standard dialect. As soon as you start : defining your own macros, it gets a little trickier. : : Interesting, I hadn't considered that. : : Having a quick browse through some of the discussions about macros, many : of the macros I saw[*] looked something like they could be conceptualised : as referring to the part of the AST where they were defined. : : ie, making the AST more of an Abstract Syntax Graph. And macros like : 'free' (ie, stack frame and scope-less) subs, with only the complication : of variable binding. The ability to have recursive macros would then : relate to this graph-ness. That is one variety of macro. : What are the shortcomings of this view of macros, as 'smart' (symbol : binding) AST shortcuts? The biggest problem with smart things is they're harder for not-so-smart people to understand. : The ability to know exactly what source corresponds to a given point on : the AST, as well as knowing straight after parse time (save for string : eval, of course) what each token in the source stream relates to is one : thing that I'm aiming to have work with Perldoc. I'm hoping this will : assist I18N efforts and other uses like smart editors. Yes, that's an important quality for many kinds of tools, whether documentation, debugging, or refactoring. : By smart editors, I'm talking about something that uses Perl/PPI as its : grammar parsing engine, and it highlights the code based on where each : token in the source stream ended up on the AST. This would work : completely with source that munges grammars (assuming the grammars are : working ;). Then, use cases like performing L10N for display to non- : English speakers would be 'easy'. I can think of other side-benefits : to such regularity of the language, such as allowing Programatica- : style systems for visually identifying 'proof-carrying code' and : 'testing certificates' (see http://xrl.us/programatica). Glad you think it's 'easy'. Maybe you should 'just do it' for us. :-) : macros that run at compile time, and insert strings back into the : document source seem hackish and scary to these sorts of prospects. We also allow (but discourage) textual substitution macros. They're essentially just lexically scoped source filters, and suffer the same problems as source filters, except for the fact that you can more easily limit the damage to a small patch of code. The problem is that the original patch of text has to be stored in the AST along with the new chunk of AST generated by the reparse, and it's not at all clear how a tool should handle that conflict. It's better to only parse once whenever possible, and just make sure the original text remains attached to the appropriate place in the AST. More basically, it's usually better to cooperate with the parser than to lie to it. : But then, one man's hackish and scary is another man's elegant : simplicity, I guess. : : * - in particular, messages like this: : - http://xrl.us/fr78 : : but this one gives me a hint that there is more to the story... I : don't grok the intent of 'is parsed' : - http://xrl.us/fr8a This is mostly talked about in the relevant Apocalypses, and maybe the Synopses. See dev.perl.org for more. Larry
Re: Whither use English?
On Thu, Apr 14, 2005 at 01:25:15PM +1200, Sam Vilain wrote: : Juerd wrote: : According to Wikipedia there are around 400 million native English : speakers and 600 million people who have English as a second language. : Should the remaining ~5.5 billion humans be exluded from writing perl : code just so that we English speakers can understand all the code that is : written? : Yes. : : So, you gladly invite the curse of semantic fixation. : : 我不邀 Hmm, speaking of semantic fixation, in Japanese that last character has come to mean "ambush" rather than "invite". But either way, [EMAIL PROTECTED]n3 :-) (give or take a word order or two). : As we will know exactly what are symbols and what is code, it should : even be possible to automatically perform L10N on source code, without : breaking it. Well, only if you stick to a standard dialect. As soon as you start defining your own macros, it gets a little trickier. : So stop being empirical! Empires also have their occasional uses. :-) Larry
Macros [was: Whither use English?]
Larry Wall wrote: Well, only if you stick to a standard dialect. As soon as you start defining your own macros, it gets a little trickier. Interesting, I hadn't considered that. Having a quick browse through some of the discussions about macros, many of the macros I saw[*] looked something like they could be conceptualised as referring to the part of the AST where they were defined. ie, making the AST more of an Abstract Syntax Graph. And macros like 'free' (ie, stack frame and scope-less) subs, with only the complication of variable binding. The ability to have recursive macros would then relate to this graph-ness. What are the shortcomings of this view of macros, as 'smart' (symbol binding) AST shortcuts? The ability to know exactly what source corresponds to a given point on the AST, as well as knowing straight after parse time (save for string eval, of course) what each token in the source stream relates to is one thing that I'm aiming to have work with Perldoc. I'm hoping this will assist I18N efforts and other uses like smart editors. By smart editors, I'm talking about something that uses Perl/PPI as its grammar parsing engine, and it highlights the code based on where each token in the source stream ended up on the AST. This would work completely with source that munges grammars (assuming the grammars are working ;). Then, use cases like performing L10N for display to non- English speakers would be 'easy'. I can think of other side-benefits to such "regularity" of the language, such as allowing Programatica- style systems for visually identifying 'proof-carrying code' and 'testing certificates' (see http://xrl.us/programatica). macros that run at compile time, and insert strings back into the document source seem hackish and scary to these sorts of prospects. But then, one man's hackish and scary is another man's elegant simplicity, I guess. * - in particular, messages like this: - http://xrl.us/fr78 but this one gives me a hint that there is more to the story... I don't grok the intent of 'is parsed' - http://xrl.us/fr8a
Re: Whither use English?
Juerd wrote: According to Wikipedia there are around 400 million native English speakers and 600 million people who have English as a second language. Should the remaining ~5.5 billion humans be exluded from writing perl code just so that we English speakers can understand all the code that is written? Yes. So, you gladly invite the curse of semantic fixation. As we will know exactly what are symbols and what is code, it should even be possible to automatically perform L10N on source code, without breaking it. So stop being empirical! TIA, Sam.
Re: Whither use English?
On Mon, 11 Apr 2005, Juerd wrote: Seriously, is there some reason that we would not provide a Language::Russian and Language::Nihongo? Given Perl 6, it would even [snip] Because providing it leads to its use, and when it gets used, knowing English is no longer enough. I have some code that uses Dutch variable names. When I show that code to people who can't read any Dutch, they have a hard time finding out Which reminds me of the TeX format ConTeXt which is (told to be) somehow more powerful and modern wrt LaTeX, but has a much narrower user base, and IIRC is expressedly design to support localized user interfaces, the only existing one should actually be ductch. I'd be curious to know if and how this works amongst ConTeXt users... Michele -- [...] is like requiring to play tennis with a square ball. Which admittedly makes the game more interesting. - Giuseppe Oblomov Bilotta in comp.text.tex (edited)
Re: Whither use English?
On Mon, Apr 11, 2005 at 03:42:25PM -0400, Aaron Sherman wrote: I don't think you can say (as Larry has) that you want to be able to fully re-define the language from within itself and still impose the constraint that it can't confuse people who don't know anything about my module. You might argue that Language::Dutch should never ship with the core... that's a valid opinion, but SOMEONE is going to write it. It'd be a kind of strange form of censorship for CPAN not to accept it. After all, there's more than one way to say it... isn't there? While it may be possible to do it, and while it may be an interesting exercise to implement it, that doesn't mean that anyone *using* it for anything other than a joke isn't a blithering idiot. I'm not even sure I like the *possibility* of using non-ascii letters in identifiers, even. I think we already have Latin-1 in identifiers... more's the pity. Let's see about UTF-8 pugs my $??? = 1; undef pugs $???; 1 I see a sequence of three question marks, there's no funny foreign characters there. I have to confess to being surprised that $??? is legal. -- David Cantrell | Benevolent Dictator Of The World May your blessings always outweigh your blotches! -- Dianne van Dulken, in alt.2eggs...
Re: Whither use English?
Thomas Yandell skribis 2005-04-12 13:13 (+0100): According to Wikipedia there are around 400 million native English speakers and 600 million people who have English as a second language. Should the remaining ~5.5 billion humans be exluded from writing perl code just so that we English speakers can understand all the code that is written? Yes. But your numbers are utterly useless, as they are counts of humans, not programmers. I think that the number of programmers who don't understand English is very small. They know English because historically, the programmer's world has been English. Of course, the level of comprehension differs greatly. That's why where things get hard, Perl lets you write the wrong thing, like 1th and 2th, maybe even 5rd and 7nd. And documentation should be written as simply and clearly as possible. If a word like mnemonic is used, it should first be explained. And keywords are new to any programmer anyway. Mnemonically, it may be easy to remember that say prints something, but it certainly doesn't say anything. And how is remembering my or readline or try any harder than the many not-at-all-english \W operators that Perl has? Then, there are books, documentation, mailing lists and fora, most of which are available in English only. A small part is translated, but I find it hard to believe that the translated portion can be enough. (Still, having them around does help many people, and that's why I think perldocs should perhaps come in several languages (as a different project, so translation delays don't delay Perl releases)). Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Whither use English?
On Tue, Apr 12, 2005 at 02:38:01PM +0200, Juerd wrote: (Still, having them around does help many people, and that's why I think perldocs should perhaps come in several languages (as a different project, so translation delays don't delay Perl releases)). Should ? Who is going to pay for all these translations? There are already volunteer efforts to translate into Japanese and Italian, according to http://www.perl.org/docs.html plus I'm aware of perlchina.org, which is actively translating documentation to Chinese: http://wiki.perlchina.org/main/recently_revised/ Nicholas Clark
Re: Whither use English?
Nicholas Clark skribis 2005-04-12 13:58 (+0100): (Still, having them around does help many people, and that's why I think perldocs should perhaps come in several languages (as a different project, so translation delays don't delay Perl releases)). Should ? Yes, should. That's ideology, though. Who is going to pay for all these translations? Who is going to pay for Parrot? Perl 6? Who's paying for Pugs? Who's going to pay for perldocs in English? Did I miss some important memo? Many people work on Perl 6 voluntarily, and as many could work on translations, but you need an army of translators to keep up with newer versions, and that's why I think it should be official, so it gets lots of attention. There are already volunteer efforts to translate into Japanese and Italian, according to http://www.perl.org/docs.html plus I'm aware of perlchina.org, which is actively translating documentation to Chinese: http://wiki.perlchina.org/main/recently_revised/ That's nice, but were this an international project for in theory any language in existence, then I had probably heard of it much sooner, which is my argument for making translated perldocs an official project that isn't limited to any language. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Whither use English?
On Tuesday 12 April 2005 07:42 am, David Cantrell wrote: On Mon, Apr 11, 2005 at 03:42:25PM -0400, Aaron Sherman wrote: I'm not even sure I like the *possibility* of using non-ascii letters in identifiers, even. I think we already have Latin-1 in identifiers... more's the pity. Let's see about UTF-8 pugs my $??? = 1; undef pugs $???; 1 I see a sequence of three question marks, there's no funny foreign characters there. I have to confess to being surprised that $??? is legal. If it helps any, the problem is somewhere betwen lists.develooper.com and your eyes; the missing doodad was U+0E81 LAO LETTER KO, which is pleasantly curvy.
Re: Whither use English?
On Tue, Apr 12, 2005 at 02:38:01PM +0200, Juerd wrote: Thomas Yandell skribis 2005-04-12 13:13 (+0100): According to Wikipedia there are around 400 million native English speakers and 600 million people who have English as a second language. Should the remaining ~5.5 billion humans be exluded from writing perl code just so that we English speakers can understand all the code that is written? But your numbers are utterly useless, as they are counts of humans, not programmers. I think that the number of programmers who don't understand English is very small. They know English because historically, the programmer's world has been English. There's another issue that he didn't address. OK, let's allow identifiers in (say) Urdu. That's great for the three people in the entire world who speak Urdu, right up to the moment that they want their English, or Russian, or German, or Japanese users to submit patches. -- David Cantrell | London Perl Mongers Deputy Chief Heretic It's my experience that neither users nor customers can articulate what it is they want, nor can they evaluate it when they see it -- Alan Cooper
Re: Whither use English?
I'm not even sure I like the *possibility* of using non-ascii letters in identifiers, even. I think we already have Latin-1 in identifiers... more's the pity. According to Wikipedia there are around 400 million native English speakers and 600 million people who have English as a second language. Should the remaining ~5.5 billion humans be exluded from writing perl code just so that we English speakers can understand all the code that is written? I think not. Tom
Re: Whither use English?
But your numbers are utterly useless, as they are counts of humans, not programmers. I think that the number of programmers who don't understand English is very small. They know English because historically, the programmer's world has been English. My point was that English speakers are in a minority and that the current bias towards English speakers is not necessarily a good thing, and definitely not something we should seek to preserve. Of course, the level of comprehension differs greatly. That's why where things get hard, Perl lets you write the wrong thing, like 1th and 2th, maybe even 5rd and 7nd. And documentation should be written as simply and clearly as possible. If a word like mnemonic is used, it should first be explained. And keywords are new to any programmer anyway. Mnemonically, it may be easy to remember that say prints something, but it certainly doesn't say anything. And how is remembering my or readline or try any harder than the many not-at-all-english \W operators that Perl has? My point was in response to the expressed sentiment that non-ascii letters should not be used in identifiers, rather than in keywords. Then, there are books, documentation, mailing lists and fora, most of which are available in English only. A small part is translated, but I find it hard to believe that the translated portion can be enough. (Still, having them around does help many people, and that's why I think perldocs should perhaps come in several languages (as a different project, so translation delays don't delay Perl releases)). I sincerely hope that one day there will be perl books written by non-English speakers that I can find English translations for ;-) Tom
Re: Whither use English?
On Tue, Apr 12, 2005 at 03:09:10PM +0200, Juerd wrote: Nicholas Clark skribis 2005-04-12 13:58 (+0100): (Still, having them around does help many people, and that's why I think perldocs should perhaps come in several languages (as a different project, so translation delays don't delay Perl releases)). Should ? Yes, should. That's ideology, though. I read should as a danger word. It's often person A describing a desirable feature and intimating that unspecified other people B-Z ought to be implementing it. Who is going to pay for all these translations? Who is going to pay for Parrot? Perl 6? Who's paying for Pugs? Who's going to pay for perldocs in English? Did I miss some important memo? Many people work on Perl 6 voluntarily, and as many could work on translations, but you need an army of translators to keep up with newer versions, and that's why I think it should be official, so it gets lots of attention. You missed an important social observation. Many *programmers* work on these projects voluntarily because they find programming fun. Translation isn't programming, so it's unlikely to be as appealing to the majority of the community involved in Perl 6 currently. That's nice, but were this an international project for in theory any language in existence, then I had probably heard of it much sooner, which is my argument for making translated perldocs an official project that isn't limited to any language. Would you be volunteering to organise this? It's nothing personal if I'm sounding harsh. There is always this great temptation to assign jobs to the they department. (They should do this They should do that). There is no they department in a volunteer organisation - stuff happens because people care about it enough to do it themselves. Nicholas Clark
Re: Whither use English?
Nicholas Clark skribis 2005-04-12 14:34 (+0100): Yes, should. That's ideology, though. I read should as a danger word. It's often person A describing a desirable feature and intimating that unspecified other people B-Z ought to be implementing it. Please note that I try to not think about who's going to implement it at all. That makes being creative and coming up with good ideas much, much easier. Yes, if it is done, people are indeed involved, but if we all agree that something must happen, that's not terribly relevant. And before we can agree, someone must first let it enter discussion. Translation isn't programming, so it's unlikely to be as appealing to the majority of the community involved in Perl 6 currently. If it wasn't for all the pain in my wrists, hands and arms, I would already have translated perldocs and Beginning Perl (1st ed.) to Dutch. And I can't imagine I'm the only language nerd who also understands Perl. Translations work well for lots of other software, and I don't see why software for programming languages would be any different. Would you be volunteering to organise this? When/if I have the time and health to spend on it, certainly. This is one of the many things I'd love to do, but at the moment can't. There is no they department in a volunteer organisation - stuff happens because people care about it enough to do it themselves. Of course there is a they. Many of them even. Let me list a few groups of people commonly referred to as they: * parrot people * @Larry * perldoc/doc/kwid people * p6l people * the people who will be writing perl6 I'm one of the people who has ideas but is currently unable to help implementing them. I can discuss them, though, and I hope that my input can somehow, even though I'm not writing any code, help make Perl 6 a great language. For me, there is a very large they, and without them, there'd never be a Perl 6. If stuff is only happening because people care about it, then my approach should be to try and make people care, and a mailing list like this is a perfect medium for that. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Whither use English?
Juerd skribis 2005-04-12 15:46 (+0200): Please note that I try to not think about who's going to implement it at all. That makes being creative and coming up with good ideas much, much easier. And to be honest, it makes coming up with bad ideas much easier than that even :) Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Whither use English?
On Tue, Apr 12, 2005 at 03:46:03PM +0200, Juerd wrote: Yes, if it is done, people are indeed involved, but if we all agree that something must happen, that's not terribly relevant. And before we can That's another dangerous word. If stuff is only happening because people care about it, then my approach should be to try and make people care, and a mailing list like this is a perfect medium for that. This I agree with completely. It's the right way to go about things, as you're not able to do them in person. It's just dangerous words such as should and must that I don't like, because they start to sound like they're imposing obligations on volunteers. Maybe I'm jaded, but if you read enough feedback about Perl 5 it seems that there are an awful lot of people in the world using it who seem to expect rather a lot for nothing. I'd just like people to be careful in their choice of words when suggesting things. Nicholas Clark
Re: Whither use English?
On Tue, Apr 12, 2005 at 03:48:02PM +0200, Juerd wrote: Juerd skribis 2005-04-12 15:46 (+0200): Please note that I try to not think about who's going to implement it at all. That makes being creative and coming up with good ideas much, much easier. And to be honest, it makes coming up with bad ideas much easier than that even :) Good point. Saves having to ask how would I do that?, let alone answer it :-) Nicholas Clark
Re: Whither use English?
On Tue, 2005-04-12 at 07:42, David Cantrell wrote: You might argue that Language::Dutch should never ship with the core... that's a valid opinion, but SOMEONE is going to write it. It'd be a kind of strange form of censorship for CPAN not to accept it. After all, there's more than one way to say it... isn't there? While it may be possible to do it, and while it may be an interesting exercise to implement it, that doesn't mean that anyone *using* it for anything other than a joke isn't a blithering idiot. We're all programmers (I assume), and we've all come across environments where programming tools that seemed useless or silly in one environment were critical in another. The education example I gave is an ideal one, but there are dozens of others from any number of fields. Perl 6 offers us the opportunity to create true dialects, and dialects are valuable things. I don't recommend that everyone rush in and use such a module, but it has its value. I'm not even sure I like the *possibility* of using non-ascii letters in identifiers, even. I think we already have Latin-1 in identifiers... more's the pity. This is just ASCII prejudice (which seems strange, as your domain implies you're not here in the US where such prejudice is usually assumed). There's nothing fundamentally wrong with having $ther as a variable name, other than the fact that most Americans are confused by it because they think and ae are identical. They're wrong. We've already deeply embraced the Latin-1 character set for many purposes in Perl 6. I *would* however, have a use warning unicode type of thing which would warn on the use of any Unicode character in an identifier whose standard display form is difficult to distinguish from some more commonly used character's display form. For example, is just a bit too close to b, so you might want to warn the user unless their default locale was one where it's commonly used, or at least provide a facility for requesting such warnings. Let's see about UTF-8 pugs my $??? = 1; undef pugs $???; 1 I see a sequence of three question marks, there's no funny foreign characters there. I have to confess to being surprised that $??? is legal. That's either a bug in your mailer (or possibly something that tried to re-encode your mail for you) or the fact that you're using some ancient output device that doesn't grok Unicode character sequences. It's refusing to display perfectly valid Content-Type: text/plain; charset=UTF-8 mail in Content-Transfer-Encoding: quoted-printable correctly. It should render pugs my $=E0=BA=81 =3D 1; as the appropriate Unicode sequence. Certainly we've already stated that the default encoding of Perl 6 programs will be UTF-8, and that means that such sequences are valid, and all editors I know of handle these sequences correctly (Emacs, vim, eclipse, etc.) I don't see why stopping someone in Russia from writing code in their native syllabary is wrong... after all, they're probably not going to use ASCII to represent words that I can read anyway... they're going to use ASCII to write a romanized form of their own language. Restrictions on style should be performed at a higher level. For example the new CPAN for Perl 6 might have some qualifiers that you can attach to your programs that describe character set used and other stylistic conventions. That way, I might choose to look for only modules that are written in a language that I feel comfortable maintaining. Then again, I might not care, and just install whatever works. -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith It's the sound of a satellite saying, 'get me down!' -Shriekback
Whither use English?
I'm working on docs/S28draft.pod in the pugs project. And consulting perl5's perlvar.pod, the issue of use English comes up. AFAICT from various sources, little has been said about this NOTE: http://groups-beta.google.com/group/perl.perl6.language/msg/fa241233bcfba024: we've already been through the whole Cuse English; thing and how no one uses it What's the word. Will there be something like use English? Regards to all, David
Re: Whither use English?
David Vergin skribis 2005-04-11 9:44 (-0700): What's the word. Will there be something like use English? Yes, and it's the default :) Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Whither use English?
On Mon, 2005-04-11 at 14:31, Juerd wrote: David Vergin skribis 2005-04-11 9:44 (-0700): What's the word. Will there be something like use English? Yes, and it's the default :) Yes, but it will be spelled: use $*LANG ;-) Seriously, is there some reason that we would not provide a Language::Russian and Language::Nihongo? Given Perl 6, it would even be quite valid for those modules to add aliases for all of the core functions and keywords, not just global variables. -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: Whither use English?
Aaron Sherman skribis 2005-04-11 14:49 (-0400): Yes, but it will be spelled: use $*LANG ;-) Seriously, is there some reason that we would not provide a Language::Russian and Language::Nihongo? Given Perl 6, it would even be quite valid for those modules to add aliases for all of the core functions and keywords, not just global variables. Because providing it leads to its use, and when it gets used, knowing English is no longer enough. I have some code that uses Dutch variable names. When I show that code to people who can't read any Dutch, they have a hard time finding out what it does and how it works. If even builtin functions become unfamiliar, this figuring out becomes impossible instead of hard, without learning the language it's written in. English sucks in many interesting ways, but at least it's a de facto standard and documentation will be available in it. I'm not even sure I like the *possibility* of using non-ascii letters in identifiers, even. As a 12-year old, I used several BASIC dialects. One time I found a Dutch BASIC. It had TOON instead of PRINT, and INVOER instead of INPUT. Even though these words were in my own language, I found using them hard just because I was used to something entirely different. You could say it only takes some getting used to, but it's easier to get used to one language than to all languages a grammar exists for. And even though I knew when I wrote it that it was a mistake, I used esperato identifiers in Lingua::EO::Supersignoj. You can't imagine how often I've used new instead of nova since I released that. A next version is going to have English as the primary language, even though I love Esperanto. I do think translating *documentation* is a very good idea. But please let that be an official project, with lots and lots of committers, because every one-man translation operation eventually dies. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Whither use English?
On 2005-04-11 15:00, Juerd [EMAIL PROTECTED] wrote: I'm not even sure I like the *possibility* of using non-ascii letters in identifiers, even. I agree that it would be a nightmare if project A used presu instead of print everywhere, while project B used toon, etc. But non-ASCII identifiers are a good thing, because there are many places even in the English-speaking world even in Ugly America where people are used to such identifiers. I want to be able to use $ for a variable representing angstroms, to see the constant Math::Trig:: in trig functions, to declare a sub that does summations, etc etc. And even if those dont come through in email properly, they make it through CVS/SVN commits and updates just fine. :)
Re: Whither use English?
On Mon, 2005-04-11 at 15:00, Juerd wrote: Aaron Sherman skribis 2005-04-11 14:49 (-0400): Yes, but it will be spelled: use $*LANG ;-) Seriously, is there some reason that we would not provide a Language::Russian and Language::Nihongo? Given Perl 6, it would even be quite valid for those modules to add aliases for all of the core functions and keywords, not just global variables. Because providing it leads to its use, and when it gets used, knowing English is no longer enough. I don't think you can say (as Larry has) that you want to be able to fully re-define the language from within itself and still impose the constraint that it can't confuse people who don't know anything about my module. You might argue that Language::Dutch should never ship with the core... that's a valid opinion, but SOMEONE is going to write it. It'd be a kind of strange form of censorship for CPAN not to accept it. After all, there's more than one way to say it... isn't there? English sucks in many interesting ways, but at least it's a de facto standard and documentation will be available in it. Let's think about this in terms other than someone distributing code to the masses. What about teaching? If I were going to teach the basic concepts of programming, I'd like to do so with a language whose constructs are all native. This is simply practical: having to learn vocabulary at the same time that you learn a new WAY of communicating makes it harder. If CPAN had a Language::NYUpperEastSide, then I might consider using that for my elementary computer class rather than try to teach everyone real English AND programming in one year ;-) I'm not even sure I like the *possibility* of using non-ascii letters in identifiers, even. I think we already have Latin-1 in identifiers... let me check. Yep: pugs my $ = 1; undef pugs $; 1 Let's see about UTF-8 pugs my $ = 1; undef pugs $; 1 A-yup! -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: Expunge use English from Perl?
On Wed, 27 Sep 2000, Nathan Wiger wrote: Yeah, I've never liked the _ syntax, I've always thought it was weird (to say the least). I think grouping file tests would be much cleaner. As long as you are okay with having to restat for 'or' clauses. (There are work arounds, and supposedly 'this or that' is less common for file tests.) -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: Expunge use English from Perl?
On Mon, Oct 02, 2000 at 07:32:42AM -0400, Bryan C. Warnock wrote: On Wed, 27 Sep 2000, Nathan Wiger wrote: Yeah, I've never liked the _ syntax, I've always thought it was weird (to say the least). I think grouping file tests would be much cleaner. As long as you are okay with having to restat for 'or' clauses. (There are work arounds, and supposedly 'this or that' is less common for file tests.) A rather sweeping statement. ANDing makes more sense for the permissions checks, but ORing makes more sense for the type checks. For example, I can imagine -f $foo || -l $foo being a rather common idiom. -- Bryan C. Warnock ([EMAIL PROTECTED]) -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: Expunge use English from Perl? (was Re: Perl6Storm: Intent toRFC #0101)
On Wed, 27 Sep 2000, Nathan Wiger wrote: Russ Allbery wrote: I've found the use of use English in code I had to maintain to be annoying and unhelpful, and to actually degrade the maintainability of the code Y'know, I couldn't have said this better myself. :-) I've always felt that "use English" was a waste of time and effort, a bandaid trying to act as a tourniquet. Well, I think it has some limited uses. Remember that not everyone programs in perl all day everyday. Many competent people are only occasionally perl programmers. I find that I don't remember many of the less-frequently-used perlvars (where less-frequently-used depends on the types of programs I write, obviously). I certainly couldn't tell you off-hand the differences among $ $ $( and $). I'd have to look them up. I think it's a nice little bit of optional sugar and I don't see any reason to throw it away. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Expunge use English from Perl? (was Re: Perl6Storm: Intent to RFC #0101)
On Thu, Sep 28, 2000 at 10:00:49AM -0400, Andy Dougherty wrote: On Wed, 27 Sep 2000, Nathan Wiger wrote: Y'know, I couldn't have said this better myself. :-) I've always felt that "use English" was a waste of time and effort, a bandaid trying to act as a tourniquet. I think it's a nice little bit of optional sugar and I don't see any reason to throw it away. The key point is that it's optional. If you think it's a waste of time and effort, don't use it. If other people use it, well... does Perl stop people programming in ways you don't like? -- It is better to wear chains than to believe you are free, and weight yourself down with invisible chains.
Re: Expunge use English from Perl? (was Re: Perl6Storm: Intent to RFC #0101)
Andy Dougherty [EMAIL PROTECTED] writes: I find that I don't remember many of the less-frequently-used perlvars (where less-frequently-used depends on the types of programs I write, obviously). I certainly couldn't tell you off-hand the differences among $ $ $( and $). I'd have to look them up. I never understood why these were variables. You don't change UIDs or GIDs that often, and when you do you tend to want precise control and because they're variables, they have weird interaction semantics and you have to assign to them in just the right order to get done what you want to get done. See recent threads on comp.lang.perl.moderated. I'd honestly rather see getuid, geteuid, getgid, getegid, and getgroups, along with some consistent and complete subset of the setting functions (with portability magic behind the scenes), in a separate module that only those programs that need to do UID fiddling need to load. I guess the exception is getpwuid($), which is probably done more than any other operation on UIDs, but maybe just keep that single variable. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Expunge use English from Perl? (was Re: Perl6Storm: Intent to RFC #0101)
Simon Cozens wrote: On Thu, Sep 28, 2000 at 10:00:49AM -0400, Andy Dougherty wrote: On Wed, 27 Sep 2000, Nathan Wiger wrote: Y'know, I couldn't have said this better myself. :-) I've always felt that "use English" was a waste of time and effort, a bandaid trying to act as a tourniquet. I think it's a nice little bit of optional sugar and I don't see any reason to throw it away. The key point is that it's optional. If you think it's a waste of time and effort, don't use it. If other people use it, well... does Perl stop people programming in ways you don't like? I agree with you. That's why I'd never RFC that we should lose it.* I was just voicing my opinion that I personally think it's a waste. But that doesn't mean others don't like it. ;-) -Nate * assuming it doesn't harm the language, which it doesn't currently
Expunge use English from Perl? (was Re: Perl6Storm: Intent to RFC #0101)
Russ Allbery wrote: I've found the use of use English in code I had to maintain to be annoying and unhelpful, and to actually degrade the maintainability of the code [snip] I've yet to understand why I'd *want* to use English regularly; so far as I can tell, it has essentially no benefit in the long term. [snip] I know it's not the only stance to take, but I prefer to try to make my Perl code very readable by people who know Perl, and encourage people who don't know Perl who are trying to read my code to learn Perl first, or at the same time. [snip] use English doesn't really address the syntactical points of Perl that make it hard to read for someone who doesn't know Perl; it strikes me, and always has struck me, as a bad partial solution to a problem that may not need to be solved and that only makes things more complicated in the long run. Y'know, I couldn't have said this better myself. :-) I've always felt that "use English" was a waste of time and effort, a bandaid trying to act as a tourniquet. Using Randal's code: /foo/ print while ; Note that "use English" here does nothing to improve the horribly unreadable - yet beautifully succinct and flexible - syntax that is Perl. My personal feeling is that I'd love "use English" to be expunged from the language altogether - it's unnecessary bloat that only increases the number of mistakes that people can make. But I'm not sure if I have the guts to write that RFC just yet. ;-) -Nate
Re: Expunge use English from Perl? (was Re: Perl6Storm: Intent to RFC #0101)
On Wed, Sep 27, 2000 at 04:39:32PM -0700, Nathan Wiger wrote: My personal feeling is that I'd love "use English" to be expunged from the language altogether - it's unnecessary bloat that only increases the number of mistakes that people can make. But I'm not sure if I have the guts to write that RFC just yet. ;-) Are you talking about the overlong variable names? Aliasing -X is being proposed through a 'use english;' mechanism. Z.
Re: Expunge use English from Perl? (was Re: Perl6Storm: Intent to RFC #0101)
Adam Turoff wrote: On Wed, Sep 27, 2000 at 04:39:32PM -0700, Nathan Wiger wrote: My personal feeling is that I'd love "use English" to be expunged from the language altogether - it's unnecessary bloat that only increases the number of mistakes that people can make. But I'm not sure if I have the guts to write that RFC just yet. ;-) Are you talking about the overlong variable names? Aliasing -X is being proposed through a 'use english;' mechanism. It's a good thing we've got Larry Wall to untie the Gordian knot of perl6. One rfc to add more english, one to take it away. -- Robert Mathews Software Engineer Excite@Home
Re: Expunge use English from Perl?
My personal feeling is that I'd love "use English" to be expunged from the language altogether - it's unnecessary bloat that only increases the number of mistakes that people can make. But I'm not sure if I have the guts to write that RFC just yet. ;-) Are you talking about the overlong variable names? Aliasing -X is being proposed through a 'use english;' mechanism. Yes, but perhaps a little bit of both. Truthfully, I've always seen long alternatives as useless bloat, not used widely over the long term. Once people learn the shortcuts, they use them. Expunging "use English" may will improve Perl syntax, since it's one less way to do things with already dubious value. Yes, the overlong variable names are a waste of time, IMO, because I've never seen them used in "real code". It's almost a rite of passage to take off the training wheels and use the "real names" of the variables. Who wants to write $INPUT_RECORD_SEPARATOR when you can write $/ ? I'm not vehemently opposed to "use English", or even the long alternatives to -r and -w that RFC 290 proposes. But I do think, truthfully: 1. They don't solve the real syntactic problems 2. Very few people will ever use them long-term So if they bloat the language, we should consider expunging them. They certainly bloat Camel with duplicate definitions. And I consider the mneumonic of $! much stronger than $ERRNO (or was that $OS_ERROR or $SYS_ERROR or ??) Personally, my stance is that we should all come to accept that we use and love a language with a syntax that drives many people mad. Not everyone's gonna like Perl, so I think we should just accept it and move on. -Nate
Re: Expunge use English from Perl?
On Wed, Sep 27, 2000 at 05:11:30PM -0700, Nathan Wiger wrote: Yes, but perhaps a little bit of both. Truthfully, I've always seen long alternatives as useless bloat, not used widely over the long term. Once people learn the shortcuts, they use them. Expunging "use English" may will improve Perl syntax, since it's one less way to do things with already dubious value. A lot of use English has to do with aliasing global variable linenoise, which is already going away. For instance, $/ is becoming per-handle, and $: (?) is probably going away because it has nasty action-at-a-distance properties, and FORTRAN programmers never use it to offset the zero-index to one. (Abigail uses it to make japhs that bizarrely store the number 17.) It has nothing to do with improving the syntax though, because everything in use English is a variable that serves as a reference to some other variable. I'm not vehemently opposed to "use English", or even the long alternatives to -r and -w that RFC 290 proposes. But I do think, truthfully: 1. They don't solve the real syntactic problems No, because the syntactic problems are -s(FH)/2, and that is solved by fsize(FH)/2 iff -s is replaced with fsize (or a better spelling thereof). 2. Very few people will ever use them long-term I dunno. I remember looking at some code that used '-x _' that had half a department befuddled. -rwx FH is better, and gets rid of the special case bare _ syntax. Z.
Re: Expunge use English from Perl?
Adam Turoff wrote: It has nothing to do with improving the syntax though, because everything in use English is a variable that serves as a reference to some other variable. Yes, and that's why I really think it's a waste of time. ;-) I'm not vehemently opposed to "use English"... But I do think, 1. They don't solve the real syntactic problems No, because the syntactic problems are -s(FH)/2, and that is solved by fsize(FH)/2 iff -s is replaced with fsize (or a better spelling thereof). This is one thing that I'm scared most of, and that is having two alternatives which work only in certain contexts. I'm sure p5p has already extensively looked at -s(FH)/2 being "wickedly broken" (as I believe Tom put it), but the solution should theoretically be to make -s(FH)/2 work. The consensus has already pretty much said that they want -s et all to stick around. So if RFC 290's idea is still to replace -X, then I'm very much against it. But I was under the impression that they're just "use english" alternatives. If, however, these alternatives fix bugs that -X can't handle, then that's not good. I'll dig through the p5p archives and toke.c to see if any wisdom is magically imparted on me. ;-) 2. Very few people will ever use them long-term I dunno. I remember looking at some code that used '-x _' that had half a department befuddled. -rwx FH is better, and gets rid of the special case bare _ syntax. Yeah, I've never liked the _ syntax, I've always thought it was weird (to say the least). I think grouping file tests would be much cleaner. -Nate
