Re: Native language versions

Peter J. Holzer <hjp-usenet2@xxxxxx> wrote:

: So about the practical use:

: For a general purpose programming language: Probably not. "Real
: programmers" value the ability to share their programs all over the
: world too much. Maybe China will have supplanted the USA as the leading
: superpower in 50 years and we will all learn Chinese and create new
: programming languages based on Chinese grammar (which AFAIK is
: positional, too) and writing. But not now.

For sure this will happen. Even though this is not Perl, but TeX, I know
of one case in Mongolia where a Mongolian computer scientist implemented
a package with Mongolian commands, instead of the English commands (TeX
is macro-based, and it is not a big problem to compile a huge list of
aliases to the existing macros).

: > Is it still Perl?

: No. Definitely not. It is a different language which can be translated
: into perl and can use Perl modules.

Well, I am not at all against writing modules which can replace (or enrich)
"native" Perl commands, statements and structures with English names by
any other given language. A bit further into the still dawning age of Unicode,
and everything can be expressed with non-ASCII characters. Not that Perl
is the restricting factor, but the constraints are usually in the users'
platforms.

I still have my doubts that it will help to lead people back to the joy
of programming even a simple script. You cited the age of CLIs and built-
in Basic, command shells etc. This age will not really return to the average
computer user any more. Computers tend to become more and more taken for
granted, omnipresent and powerful, to a degree that they start vanishing
from public perception, just like electry which is delivered from wall
outlets, not power plants, etc. Who still realizes that a digital camera,
a mobile phone, the cash register at the local market or the ignition control
system of your car happen to be powerful computers with specialized purposes
and interfaces?

That leads me back to Perl. The true hurdle lies not in the choice of
English of French or Japanese words for things like "print" or "while".
These can be replaced easily. Judging by an overwhelming number of postings,
we see fundamental conceptual errors as the source of various posters'
problems. Take anything like

$line_1="first line";
$line_2="second line";
$line_3=...

combined with the question "How can I construct a variable name from a
variable?"

where everybody can see that the answer would be an array. Or someone
puts $element=@elements and wonders why @elements=('a','b','c')
always becomes "3" in $element, instead of "abc".

This newsgroup is full of initial postings based on conceptual errors, and
astonishingly enough, these conceptual errors can occur even in the code
of contributors who otherwise seem to be quite fluent in fairly idiomatic
Perl. I do not think that the ratio of conceptual misunderstandings will
really decrease with localized programming code wordings.

This is why I question the practicality of just translating the keywords
of a language like Perl. First of all, the documentation needs a good,
thorough and complete translation, then you still can translate keywords,
but when you come to concepts, structures and symbols, there is not much
to translate. You have to learn them. Is the average native English (be she
British, American or Asian-Pacific (Australia and Hong Kong come to my mind))
programmer statistically less error-prone and more successful as a programmer
just because she seemingly doesn't have to learn the keywords?

The module providing English names to Perl's built-in variables ($_, $/,
$., etc.) can be complemented by a module providing German, Japanese, Chinese
and other names. This is helpful indeed, but users still have to read and
understand from documentation and general computer science knowledge how
to manipulate these symbols, and how to manipulate their data by them.
It doesn't really help if a German user has difficulties applying a $/
if the concept of an $INPUT_RECORD_SEPARATOR is not well understood, notably
if the first occurrence in perlvar.pod says "# enable localized slurp mode".
It doesn't even use concepts like EOL, record separators etc. Just imagine
a young Chinese, Japanese or even German computer science student trying
to understand what "slurp" means in the context of reading from a file handle,
while the first reference in the Oxford English dictionary is:
eat or drink (something) with a loud sloppy sucking noise:
she slurped her coffee | [ intrans. ] he slurped noisily
from a wine cup.

The first thing the definition mentions is the noise of the action, not the
"whole cup of coffee in one scoop" concept.

Perl is not Java! And here, English-speaking computer scientists and Perl
programmers do have an unfair advantage over speakers of different tongues,
all the more in cultural backgrounds which allow the peaceful coexistence
of humour, wit and irony with absolutely serious business. Not all
cultures do appreciate this ambiguity which may be highly irritating in
Japan, Egypt, India or many other places.

To make a long story short: Language is more than lexicon and grammar.
Replacing the lexicon by close approximates of the lexicon is only partially
helpful. It is the documentation which needs a careful translation first.

Perhaps after porting Perl to so many platforms, we should start porting
the Perl documentation to more languages besides English. CPAN would gain
a huge advantage from such an effort, as would the global Perl community.

If a good framework is established, then any hint to e.g. perlreftut will
still point to the intended information, regardless of the language in which
the documentation is perused.

Sorry for the lack of conciseness.

Oliver.


--
Dr. Oliver Corff e-mail: corff@xxxxxxxxxxxxxxxxxx
.

Relevant Pages

  • Re: F is evil (was: XML::LibXML UTF-8 toString() -vs- nodeValue())
    ... So Futfizes symbols by accident. ... language, no matter if the programming language makes it easy or not. ... Sometimes this is because they don't speak English too well, ...
    (comp.lang.perl.misc)
  • Recommend an E-book Meeting the Following Criteria (Newbie, Long)
    ... I know several programming languages namely Java, Perl and C in this order ... Now I'm wondering which Python book I should get as there are so many out ... I'd like to mostly concentrate on language features but some pointers ...
    (comp.lang.python)
  • Re: A Lot of Questions from a Noob
    ... OOP is a language paradigm that is not specific to ... I Google'd for an introduction to object-oriented programming, ... Watch out for the die-hard Perl fanbois: ... PHP 5 OOP has come a long way from PHP 4. ...
    (comp.lang.php)
  • Re: Wondering if you guys would like to comment on this
    ... >>ever tried using someone's highly customized EMACS setup? ... I've had the same experience with perl that he ... problem with any programming language, perl tends to make it worse ... I have the same rules on LISP programming that I do with perl ...
    (comp.lang.lisp)
  • Re: For Henry to enjoy:
    ... Spoken language was the question Karla. ... based programming languages. ... English has been the undisputed lingua franca for the ... language taught in Russian schools, ...
    (soc.culture.baltics)