Native language versions

Discussion in 'Perl Misc' started by Ian, Jun 22, 2006.

  1. Ian

    Ian Guest

    Has anyone tried translating the command set of Perl into other
    languages (French, Japanese, Arabic etc.), so that native speakers do
    not need to learn any English in order to program, then writing a
    suitable compiler?
     
    Ian, Jun 22, 2006
    #1
    1. Advertising

  2. Ian wrote:
    > Has anyone tried translating the command set of Perl into other
    > languages (French, Japanese, Arabic etc.), so that native speakers do
    > not need to learn any English in order to program, then writing a
    > suitable compiler?
    >


    ... and loose the possibility to use CPAN modules?

    --
    Josef Möllers (Pinguinpfleger bei FSC)
    If failure had no penalty success would not be a prize
    -- T. Pratchett
     
    Josef Moellers, Jun 22, 2006
    #2
    1. Advertising

  3. Ian

    Guest Guest

    Ian <> wrote:
    : Has anyone tried translating the command set of Perl into other
    : languages (French, Japanese, Arabic etc.), so that native speakers do
    : not need to learn any English in order to program, then writing a
    : suitable compiler?

    Many years ago I as in Japan for the first time and had access to a
    computer. At that time, computers still came with built-in ROM with
    BASIC, which I could try after starting the machine. I was astonished
    and disappointed to see that print statements still were named print,
    and not insatsu (in whichever writing system that would be rendered
    doesn't really matter). Naively, I asked myself why the advanced
    technology of Japan had not brought forth a computer that would natively
    "work in Japanese".

    Years and many languages later I understood that such an endeavour is
    of little meaning. Any given language consists of more than words, there
    is also grammar. While you could replace "print" by "insatsu", you
    would also have to transform

    print $calar;

    into

    $calar wo insatsu;

    ("wo" being grammatical glue).

    suddenly you go from PO to OP (predicate-object to object-predicate).
    Your complete stack mechanism gets upset, ending up with a language
    like Forth or PostScript. Japanese is a bit like RPN for calculators.

    Saying

    insatsu $calar;

    would be completely ungrammatical, hence incomprehensible, in Japanese.

    Things get worse if you talk about conditionals.

    if ($a eq $b) {do something}

    would become

    ($a,$b to ha onaji).dattara {katsudou}

    since the condition in Japanese is expressed as a verb form, not as
    a particle.

    Worse with Arab which modifies the vowel structure of a consonantal skeleton
    in order to arrive at new meanings.

    No, this approach is completely impractical and not even of any academic
    interest. You cannot learn French while, for the sake of making things
    easy, maintain that you replace the French words by English. On y va -
    let's go? How will you transform that?

    The German-, French-, ... ized versions of MS Excel macro language and
    friends show how utterly useless the approach is. You gain ease of talking
    while loosing your complete audience. What a trade-off.

    Oliver.

    --
    Dr. Oliver Corff e-mail: -berlin.de
     
    Guest, Jun 22, 2006
    #3
  4. Ian

    Anno Siegel Guest

    In article <>,
    "Ian" <> writes:
    > Has anyone tried translating the command set of Perl into other
    > languages (French, Japanese, Arabic etc.), so that native speakers do
    > not need to learn any English in order to program, then writing a
    > suitable compiler?


    The meaning of computer language keywords and their meaning
    in a natural language have little to do with one another.
    Knowing what "print" means in English desn't help you any
    when it comes to its usage in a Perl context. So, even if
    your approach were feasible, the benefit would be small.
    The hard part to learn about computer language components
    is their interaction, not their individual meaning.

    Anno
     
    Anno Siegel, Jun 22, 2006
    #4
  5. Ian <> wrote:

    > Has anyone tried translating the command set of Perl into other
    > languages (French, Japanese, Arabic etc.)



    How do you say "grep" in French or Japanese?


    --
    Tad McClellan SGML consulting
    Perl programming
    Fort Worth, Texas
     
    Tad McClellan, Jun 22, 2006
    #5
  6. Ian

    Guest Guest

    Tad McClellan <> wrote:

    : > Has anyone tried translating the command set of Perl into other
    : > languages (French, Japanese, Arabic etc.)


    : How do you say "grep" in French or Japanese?


    grep in French could be ierg (imprimer expression rationelle globale), while
    in Japanese I'd expect shdi (seikihyougen wo dokodemo insatsu suru), but more
    idiomatical would be gureppu, of course.

    scnr,

    Oliver.


    --
    Dr. Oliver Corff e-mail: -berlin.de
     
    Guest, Jun 22, 2006
    #6
  7. Ian

    Ted Zlatanov Guest

    On 22 Jun 2006, wrote:

    > Has anyone tried translating the command set of Perl into other
    > languages (French, Japanese, Arabic etc.), so that native speakers do
    > not need to learn any English in order to program, then writing a
    > suitable compiler?


    I don't think the former would engender the latter. In particular,
    you'd need to translate and correct all the documentation
    appropriately for that language, and all your programs would require
    that special version of Perl. I don't think the effort is worth the
    loss of compatibility, considering the incremental effort of learning
    a few keywords is negligible compared to learning Perl as a language.

    Ted
     
    Ted Zlatanov, Jun 22, 2006
    #7
  8. -berlin.de wrote:
    > Ian <> wrote:
    > : Has anyone tried translating the command set of Perl into other
    > : languages (French, Japanese, Arabic etc.), so that native speakers do
    > : not need to learn any English in order to program, then writing a
    > : suitable compiler?


    In perl you don't need a separate compiler for that: You can write a
    filter module. See Lingua::Romana::perligata for a filter module which
    implements Latin syntax (including declensions and
    position-independence) for Perl.

    > Many years ago I as in Japan for the first time and had access to a
    > computer. At that time, computers still came with built-in ROM with
    > BASIC, which I could try after starting the machine. I was astonished
    > and disappointed to see that print statements still were named print,
    > and not insatsu (in whichever writing system that would be rendered
    > doesn't really matter). Naively, I asked myself why the advanced
    > technology of Japan had not brought forth a computer that would natively
    > "work in Japanese".
    >
    > Years and many languages later I understood that such an endeavour is
    > of little meaning. Any given language consists of more than words, there
    > is also grammar. While you could replace "print" by "insatsu", you
    > would also have to transform


    [examples where Japanese grammar differs from English grammar]

    > Worse with Arab which modifies the vowel structure of a consonantal skeleton
    > in order to arrive at new meanings.
    >
    > No, this approach is completely impractical and not even of any academic
    > interest.


    I don't think this would be impractical at all. I don't know Japanese or
    Arabic, but I don't think parsing a computer language based on Japanese
    or Arabic grammar would be harder than parsing Perl (indeed parsing Perl
    is quite hard - "only perl can parse Perl" as the saying goes). At least
    your examples don't look hard to me.

    > The German-, French-, ... ized versions of MS Excel macro language and
    > friends show how utterly useless the approach is. You gain ease of talking
    > while loosing your complete audience. What a trade-off.


    There are probably a lot more people who program Excel than any other
    programming language. There are of course other factors which make Excel
    attractive to non-programmers (not least that it doesn't *look* like a
    programming language), but I wonder whether translating the function
    names doesn't contribute to its popularity. There is a surprising number
    of people who don't understand basic English (even though they learned
    it in school).

    To you and me and other members of the Open Source community who are
    used to sharing our programs with other people all over the world, the
    mere thought of a localized programming language is a nightmare
    (debugging a program with Portuguese comments in it is hard enough, at
    least you understand the code), but there are people who don't speak
    English and who want to write programs only for themselves and their
    colleagues and friends. (and BTW, if you do it right, you can make such
    programs translatable - unlike human languages, the semantics of a
    programming language is known)

    hp

    --
    _ | Peter J. Holzer | Man könnte sich [die Diskussion] auch
    |_|_) | Sysadmin WSR/LUGA | sparen, wenn man sie sich einfach sparen
    | | | | würde.
    __/ | http://www.hjp.at/ | -- Ralph Angenendt in dang 2006-04-15
     
    Peter J. Holzer, Jun 22, 2006
    #8
  9. Josef Moellers wrote:
    > Ian wrote:
    >> Has anyone tried translating the command set of Perl into other
    >> languages (French, Japanese, Arabic etc.), so that native speakers do
    >> not need to learn any English in order to program, then writing a
    >> suitable compiler?
    >>

    >
    > ... and loose the possibility to use CPAN modules?


    If you do it via a source filter (like Lingua::Romana::perligata) you
    don't lose the CPAN modules. What you may lose is some of the usefulness
    of the documentation that comes with those modules since the examples
    may not work if you change for example the way functions are called or
    assignments are done. So you need somebody to translate the docs. But if
    you aim at programmers who don't speak English, you need to translate
    the docs anyway.

    hp

    --
    _ | Peter J. Holzer | Man könnte sich [die Diskussion] auch
    |_|_) | Sysadmin WSR/LUGA | sparen, wenn man sie sich einfach sparen
    | | | | würde.
    __/ | http://www.hjp.at/ | -- Ralph Angenendt in dang 2006-04-15
     
    Peter J. Holzer, Jun 22, 2006
    #9
  10. Ian

    Guest Guest

    Peter J. Holzer <> wrote:
    : > Ian <> wrote:
    : > : Has anyone tried translating the command set of Perl into other
    : > : languages (French, Japanese, Arabic etc.), so that native speakers do
    : > : not need to learn any English in order to program, then writing a
    : > : suitable compiler?

    : In perl you don't need a separate compiler for that: You can write a
    : filter module. See Lingua::Romana::perligata for a filter module which
    : implements Latin syntax (including declensions and
    : position-independence) for Perl.

    Which is a nice thing to have, but have we ever heard that the Vatican
    uses this module extensively?

    : > No, this approach is completely impractical and not even of any academic
    : > interest.

    : I don't think this would be impractical at all. I don't know Japanese or
    : Arabic, but I don't think parsing a computer language based on Japanese
    : or Arabic grammar would be harder than parsing Perl (indeed parsing Perl
    : is quite hard - "only perl can parse Perl" as the saying goes). At least
    : your examples don't look hard to me.

    No, that's right. You _can_ do it, but is it practical? Is it still Perl?
    I wonder how to maintain a claim that two languages are equal (perhaps
    better: equivalent) if both their grammars and lexica differ substantially?

    : There are probably a lot more people who program Excel than any other
    : programming language. There are of course other factors which make Excel
    : attractive to non-programmers (not least that it doesn't *look* like a
    : programming language), but I wonder whether translating the function
    : names doesn't contribute to its popularity. There is a surprising number
    : of people who don't understand basic English (even though they learned
    : it in school).

    While I stay with you that this feature may have contributed to the popularity
    of Excel, I've seen a number of cases where a file with scripts written in the
    German version wouldn't execute on the English version Excel. This was quite
    a few years ago, though, maybe things have changed.

    Oliver.
    --
    Dr. Oliver Corff e-mail: -berlin.de
     
    Guest, Jun 22, 2006
    #10
  11. <-berlin.de> <-berlin.de> wrote:
    > Tad McClellan <> wrote:
    >
    >: > Has anyone tried translating the command set of Perl into other
    >: > languages (French, Japanese, Arabic etc.)
    >
    >
    >: How do you say "grep" in French or Japanese?
    >
    >
    > grep in French could be ierg (imprimer expression rationelle globale), while
    > in Japanese I'd expect shdi (seikihyougen wo dokodemo insatsu suru), but more
    > idiomatical would be gureppu, of course.
    >
    > scnr,



    That was fun.

    I suppose we'd need some character other than "m" for m// then too?


    --
    Tad McClellan SGML consulting
    Perl programming
    Fort Worth, Texas
     
    Tad McClellan, Jun 22, 2006
    #11
  12. Ian

    Guest Guest

    Tad McClellan <> wrote:

    : I suppose we'd need some character other than "m" for m// then too?

    Most certainly. I suggest //i for m// (i as in itchi, to be matching).
    Note that the object predicate order is typical of Japanese. In contrast,
    the //i modifier of Perl (an attribute, that is), should be rendered
    in Japanese as m// (for m as in mushi, to ignore).

    Oliver.

    --
    Dr. Oliver Corff e-mail: -berlin.de
     
    Guest, Jun 22, 2006
    #12
  13. Ian

    Ted Zlatanov Guest

    On 22 Jun 2006, -berlin.de wrote:

    Tad McClellan <> wrote:
    >
    >> I suppose we'd need some character other than "m" for m// then too?

    >
    > Most certainly. I suggest //i for m// (i as in itchi, to be matching).
    > Note that the object predicate order is typical of Japanese. In contrast,
    > the //i modifier of Perl (an attribute, that is), should be rendered
    > in Japanese as m// (for m as in mushi, to ignore).


    Why stop there? Just write the operators in Unicode :)

    Ted
     
    Ted Zlatanov, Jun 23, 2006
    #13
  14. -berlin.de wrote:
    > Peter J. Holzer <> wrote:
    > : > Ian <> wrote:
    > : > : Has anyone tried translating the command set of Perl into other
    > : > : languages (French, Japanese, Arabic etc.), so that native speakers do
    > : > : not need to learn any English in order to program, then writing a
    > : > : suitable compiler?
    >
    > : In perl you don't need a separate compiler for that: You can write a
    > : filter module. See Lingua::Romana::perligata for a filter module which
    > : implements Latin syntax (including declensions and
    > : position-independence) for Perl.
    >
    > Which is a nice thing to have, but have we ever heard that the Vatican
    > uses this module extensively?


    No, I don't think so. It's an interesting case study, but of little
    practical value. Latin is a dead language - nobody speaks it as their
    first language, and the set of people who do speak it, are interested in
    programming and don't speak even a little bit English is probably very
    small. Conway probably chose Latin because its syntax is so different
    from most current programming languages. If you can implement a
    programming language based on Latin, you can probably implement one
    based on any living language, too.


    > : > No, this approach is completely impractical and not even of any academic
    > : > interest.
    >
    > : I don't think this would be impractical at all. I don't know Japanese or
    > : Arabic, but I don't think parsing a computer language based on Japanese
    > : or Arabic grammar would be harder than parsing Perl (indeed parsing Perl
    > : is quite hard - "only perl can parse Perl" as the saying goes). At least
    > : your examples don't look hard to me.
    >
    > No, that's right. You _can_ do it, but is it practical?


    I think I misunderstood you when you wrote "impractical". I thought you
    meant that it is extremely difficult to do. But it seems you only meant
    that the result would be of little practical use.

    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 embedded languages in applications or as shell/command languages:
    I think so. More and more people use computers which don't have an IT
    background. They want their computer to talk to them in their native
    tongue and they want to talk *to* their computer in their native tongue.
    English-based programming languages are an additional hurdle which keeps
    these people from programming - the other hurdle are GUIs. I started
    using computers around 1983. At that time, most of the documentation was
    English, the normal user interface was a command line interface which
    consisted of vaguely English words ("ls" isn't English, but it is easy
    to memorize as shorthand for "list") and the command line language
    (whether that was Basic on home computers, command.com's language on DOS
    or shell) also served as a script language. Programming was natural.
    Now people have GUIs, but programming languages are textual (yes, you
    can "record macros", but is that programming?). That's a major gap to
    cross. Their applications are all in their native language, but
    programming languages are based on English: That's another major gap. I
    think it is necessary to close both gaps so that ordinary users get back
    where they were 20 years ago: Where they can "teach" the computer to
    things, so that they don't have to do them themselves.


    > Is it still Perl?


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


    > : There are probably a lot more people who program Excel than any other
    > : programming language. There are of course other factors which make Excel
    > : attractive to non-programmers (not least that it doesn't *look* like a
    > : programming language), but I wonder whether translating the function
    > : names doesn't contribute to its popularity. There is a surprising number
    > : of people who don't understand basic English (even though they learned
    > : it in school).
    >
    > While I stay with you that this feature may have contributed to the popularity
    > of Excel, I've seen a number of cases where a file with scripts written in the
    > German version wouldn't execute on the English version Excel. This was quite
    > a few years ago, though, maybe things have changed.


    I think that's still the case (but I don't know: I don't use Excel) and
    it is sometimes a problem. However the majority of Excel users doesn't
    care as they don't share their spreadsheets with people who speak
    different languages.

    hp

    --
    _ | Peter J. Holzer | Man könnte sich [die Diskussion] auch
    |_|_) | Sysadmin WSR/LUGA | sparen, wenn man sie sich einfach sparen
    | | | | würde.
    __/ | http://www.hjp.at/ | -- Ralph Angenendt in dang 2006-04-15
     
    Peter J. Holzer, Jun 23, 2006
    #14
  15. Ian

    Guest Guest

    Peter J. Holzer <> 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: -berlin.de
     
    Guest, Jun 23, 2006
    #15
  16. -berlin.de wrote:
    > Peter J. Holzer <> wrote:
    > : > 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.


    And that's a good thing. I'm not pining for the "good old days". But I
    think that current GUIs (which haven't changed all that much since XEROX
    invented the mouse in the 1970s) aren't optimal either. I see all the
    time people doing repetitive tasks, for which on Linux I would write a
    five line shell script and be done with it. And I ask myself how the GUI
    user could be enabled to write that script. Or let's formulate this in a
    more general way: How can the user tell the computer: "I'm doing that
    stuff every week. Do it for me!"? The "language" doesn't even have to be
    written, it might be graphical, or a mixture. I agree that I'm getting
    away quite a bit from the OP's notion of just translating perl keywords
    :).


    > 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?


    I'd like to have perl (or any other sane scripting language) installed
    on my Nokia Communicator.

    There's probably not much use for a user-accessible programming language
    on a cash register. The cashier isn't supposed to reprogram the register -
    the presence of such a language would probably be considered a security
    risk. Neither do I see the need on a camera or a washing machine (but a
    network-accessible command/status interface would be useful for both). A
    modern mobile phone OTOH is almost a general purpose computer. There are
    a few things for which it is unsuitable due to its small size, but apart
    from that there isn't much difference to a desktop PC (and it's
    certainly more powerful than the first computers I used were).


    > 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.


    Right. Actually, it goes deeper. Some people have problems with the
    concept of a loop, or a variable. These people will probably never be
    able to write a program of any complexity, but even those can compose a
    linear list of "things to be done". Another reason why I see the value
    of translating programming languages more in embedded languages than in
    general purpose programming languages. A program without variables or
    loops seems strange to us. But it may replace 20 mouse clicks and
    filling in of 3 text fields with a single click, so it is useful for the
    user.


    > This is why I question the practicality of just translating the keywords
    > of a language like Perl.


    As I said, I wasn't talking about translating just the keywords. I
    specifically mentioned Lingua::Romana::perligata because it changes both
    the words and the grammar. And I tried to steer the topic away from
    general purpose programming languages to specific applications, because
    there I see value in localized programming languages.


    > 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?


    That might be an interesting topic for a study. But I think it's the
    wrong question. A "programmer" does program, so he has already learned
    those keywords. The more interesting question is IMHO: Are there more
    programmers among people who speak English than among people who don't?
    And if that is the case, is it because the latter find it harder to
    learn (English based) programming languages?


    > 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.


    Googling for "deutsche perl dokumentation" gives
    http://www.perlmongers.de/?DeutschePerlDokumentation and
    http://wiki.perl-community.de/bin/view/Perldoc/perl as the first hits,
    which is a rather sad result, as both look like somebody started a
    translation project and got bored with it very quickly.

    I agree that for Perl translating documentation and books is a lot more
    important than translating the language. A translated Perl wouldn't be
    Perl anyway.

    hp

    --
    _ | Peter J. Holzer | Man könnte sich [die Diskussion] auch
    |_|_) | Sysadmin WSR/LUGA | sparen, wenn man sie sich einfach sparen
    | | | | würde.
    __/ | http://www.hjp.at/ | -- Ralph Angenendt in dang 2006-04-15
     
    Peter J. Holzer, Jun 24, 2006
    #16
  17. [OT] GUIs [was: "Re: Native language versions"]

    On Sat, 24 Jun 2006 12:24:45 +0200, "Peter J. Holzer"
    <> wrote:

    >And that's a good thing. I'm not pining for the "good old days". But I
    >think that current GUIs (which haven't changed all that much since XEROX
    >invented the mouse in the 1970s) aren't optimal either. I see all the
    >time people doing repetitive tasks, for which on Linux I would write a
    >five line shell script and be done with it. And I ask myself how the GUI
    >user could be enabled to write that script. Or let's formulate this in a


    Really, this comes out so often... having started with a cli, albeit a
    very poor one just like the old command.com was, I have a natural
    inclination for clis. Of course the discovery of *NIX shells with the
    arrival of Linux was such a shift of perspective in terms of power at
    hand!!

    So we can see all the time how people, coming especially from the Win*
    world, have a hard time trying to do something with two or three
    buttons of a mouse that we can do with selected buttons out of 100 or
    so on a keyboard. In a fraction of the time that it takes them to
    reach for the mouse and move the cursor to the correct point...

    Nevertheless this is *not* the cli side of a cli vs. gui flame. Indeed
    guis are attracting, handy, respectable and there are jobs they're
    better suited to. All in all they're complementary.

    ==> The key point of this reflection is: shells are a means to manage
    programs. So is a window manager. Then there are text based commands
    to do system administration. Some are shell commands and others
    external programs. Their graphical counterparts are typically embedded
    in a file manager. Most of the time I prefer the cmd line tools, but
    in selected cases a file manager is better suited for some particular
    job. OTOH I bet most of you often find it easier to type 'someprogram
    &' in some terminal rather than searching someprogram in a menu or set
    of icons or some such! So... I'm generally a big supporter of the
    concept of separation (the right tool for the right job, and all
    interacting nicely to give the possibility of building something more
    complex together), but what I really miss is a beast that is at the
    same time a window manager, a file manager, and a (text-like) shell.


    End of the free-thought-session,
    Michele
    --
    {$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
    (($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
    ..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
    256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
     
    Michele Dondi, Jun 25, 2006
    #17
  18. [OT] mobiles [was: "Re: Native language versions"]

    On Sat, 24 Jun 2006 12:24:45 +0200, "Peter J. Holzer"
    <> wrote:

    >network-accessible command/status interface would be useful for both). A
    >modern mobile phone OTOH is almost a general purpose computer. There are
    >a few things for which it is unsuitable due to its small size, but apart
    >from that there isn't much difference to a desktop PC (and it's
    >certainly more powerful than the first computers I used were).


    Indeed mobiles are getting more and more complex and feature rich, and
    now a Java VM is commonly found of them. But I'd rather prefer them to
    be somewhat simpler and allow a programmable low-level system for the
    daring, instead. Something in forth, say, or io
    (<http://www.iolanguage.org>), maybe.


    Michele
    --
    {$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
    (($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
    ..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
    256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
     
    Michele Dondi, Jun 25, 2006
    #18
  19. On Sat, 24 Jun 2006 12:24:45 +0200, "Peter J. Holzer"
    <> wrote:

    >Right. Actually, it goes deeper. Some people have problems with the
    >concept of a loop, or a variable. These people will probably never be


    <joke>
    They may just program in a functional language which has no notion of
    variable or loop, and just use recursion.
    </joke>


    Michele
    --
    {$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
    (($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
    ..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
    256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
     
    Michele Dondi, Jun 25, 2006
    #19
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ed
    Replies:
    24
    Views:
    1,067
    Dimitri Maziuk
    Mar 27, 2006
  2. Dessip
    Replies:
    3
    Views:
    414
    Dessip
    Jun 16, 2006
  3. DaveInSidney
    Replies:
    0
    Views:
    459
    DaveInSidney
    May 9, 2005
  4. Replies:
    4
    Views:
    422
    Harlan Messinger
    Dec 27, 2006
  5. Saxo
    Replies:
    32
    Views:
    447
    Arved Sandstrom
    Jan 28, 2014
Loading...

Share This Page