7 ms·

First, the readme is simply hilarious! Jokes asides, the concept underlying this project is actually interesting. It wouldn't be bad at all if programming lang

by ghego1 5y ago

First, the readme is simply hilarious! Jokes asides, the concept underlying this project is actually interesting. It wouldn't be bad at all if programming languages were localizable. I think it would help many if it was possible to choose the (human) language in which to use a programming language. Ideally, the same source code could be viewed in different languages depending on the preferred idiom of the developer.

traceroute66 5y ago
> It wouldn't be bad at all if programming languages were localizable That is an admirable dream to have, and one that I have sometimes had myself. Unfortunately, as with most things reality soon puts an end to it. First, the dream is only really a dream you can have with the luxury of a Western language. It is unlikely to be viable once you start looking further East in the direction of e.g. Kartvelian languages (i.e. low number of speakers worldwide and even fewer with relevant specialisms in programming to write compilers) or Asian languages (e.g. Japanese and its particles and other complexities). Second, when you are writing code you don't really want to have to worry about the possibility of debugging your compiler. Sticking to English means the likelyhood of a more robust compiler because of more widespread adoption. You also remove technicalities such as UTF-8 or whatever else that might cause indirect issues. Its a bit like science really. Sure you can write your papers in your native language, but the reality is if you're serious about your work being discovered and are interested in being offered bigger and better jobs, you'll want to publish in English sooner rather than later.
- pyrale 5y ago
  > Unfortunately, as with most things reality soon puts an end to it. Usually, when a thing gets labeled as a dream, people don't try very hard either. > Sticking to English means the likelyhood of a more robust compiler because of more widespread adoption. The comment you quote specifically talks about localizable software, not having one compiler per language. When you I18n a website, you don't write n sites, for instance.
  - traceroute66 5y ago
    > Usually, when a thing gets labeled as a dream, people don't try very hard either. Some things are hard, but worth trying. Other things are a dream because the reality is they are unachievable either due to the realities of practical constraints or because the amount of work involved would be hugely disproportionate to the benefit. For example, I mentioned Kartvelian languages. How about we specifically look at Laz which according to Wikipedia at the last count in 1980 had only 22,000 native speakers. Writing a Laz compiler ? I'd say if we're being totally honest its a dream, not just "hard work".
    - pyrale 5y ago
      > the amount of work involved would be hugely disproportionate to the benefit. And you can trust english speakers to properly assess the benefits of I18N, right? > Writing a Laz compiler ? I'd say if we're being totally honest its a dream, not just "hard work". As I said in the message you quote, internationalizing a compiler is not the same as rewriting it. If you consider that making languages accessible to other languages means each natural language should have its own programming language and compiler, of course it's going to be hard. But that's moving the goalposts. First off, you don't need to port a programming language to every natural language. Some smaller goals would already help. For instance, making it easy for third parties to i18n the language and libraries would be a significant enabler.
    - JadeNB 5y ago
      > Writing a Laz compiler ? I'd say if we're being totally honest its a dream, not just "hard work". This seems like letting the perfect be the enemy of the good. "We can't possibly localize for every possible language ever" is not much of an argument for why localization itself isn't worth it.
- temac 5y ago
  IIRC, TI Basic dynamically translated keywords (and probably function names) depending on the current langage. That's less interesting if you have lots of libraries if you don't translate them.
junon 5y ago
> It wouldn't be bad at all if programming languages were localizable. Go switch Excel or Google Sheets into a language you don't know. Then try to use formulas with them. Come back and tell me if localized programming languages are a good thing after that. :D
- pyrale 5y ago
  > Go switch Excel or Google Sheets into a language you don't know. I don't believe that point supports your claim. Switching excel to a language you don't know is a good example of the benefits people who don't speak english get from localized languages, not the other way around. > Come back and tell me if localized programming languages are a good thing after that. :D The truth is that localized excel has enabled a generation of people speaking poor english to still do pretty dope stuff for their business. Likewise, localizable languages for children (e.g. Hedi) work pretty well at helping children discover computers before they have a firm grasp of english.
  - junon 5y ago
    And it makes support, reusable code, common understanding, and readability (in a team) fly out the window, and increases the amount of development overhead of whomever has to maintain the language.
    - tasogare 5y ago
      Only if the said support and code are not localized too. I'm using all my devices in English because it's easier to find help online but I can see why people less proficient in it would prefer localized software down to formulae and documentation.
    - pyrale 5y ago
      > it makes support Support is already a problem currently, because personalized error messages are less searchable but more useful than generic ones. Moving to error codes is a good example of an orthogonal concern that would incidentally help i18n. Supporting error formats that can be treated by machines is a further unrelated step that would also benefit i18n. So I would say the stuff we already do tend to make this concern less relevant. > reusable code That's an orthogonal concern. You don't write new code when you i18n something, you just create dictionaries. > common understanding, and readability (in a team) I don't believe anyone is making the point that one team should write in separate languages. However, a team able to choose its own language (possibly the one used by the rest of the business) is a plus. In non-english countries, it's very common to have code written in english to describe a business that is done in local language, with really bad translations of business terms. This already causes issues. > increases the amount of development overhead of whomever has to maintain the language. Why would the language maintainer do the i18n themselves?
BiteCode_dev 5y ago
> It wouldn't be bad at all if programming languages were localizable. It wouldn't be bad indeed, it would be terrible. I wouldn't be against some IDE add-ons allowing you to see the keywords in your language if you wish, but the underlying names should stay in english. And the function names as well. Otherwise: - you duplicate the documentation effort, which is already a burden; - you make googling things extra hard - people will use their language features, which means non ascii chars. Good luck typing "La leçon du père noël à l'école de la forêt" with something else than my french keyboard. - IT is nothing but thousands of conventions glued together. And names are a hell of a shortcut to describe conventions. Break that and you destroy trust, reliability and productivity. - you split the community. FOSS works so well because we can collaborate so well: we have one rosetta stone that lets us do so. Is has a basic alphabet, few rules, and is quite easy to learn. I'm a french Python dev, and Python 3 does allow you to write variables names with french accents. I would never do that, and really hope nobody ever does.
- pjerem 5y ago
  I'm also a french developer and though i've been very pedantic in the past against non-english code, I must say today that I really prefer "french" well expressed code over "english" code full of errors, "faux amis" everywhere and wrongly expressed intentions.
  - BiteCode_dev 5y ago
    The kind of code you talk about are usually internal only. People don't write libs, framework or main stream language in those situation. In that case, then it's ok to bite the bullet, to avoid the worst case scenario. But you are already in a bad place to start with. Because if you put in prod some code by somebody who can't write english properly, then it means your team doesn't have access to most information resources in the world. So your problem here is damage control, hardly a situation to generalize from.
    - pjerem 5y ago
      There’s a lot (maybe a majority where I live) of people who can perfectly read and understand English but not write a single sentence without making errors.
DylanSp 5y ago
Early VBA did this, apparently - see https://ericlippert.com/2021/02/17/life-part-38/#comment-119756 https://ericlippert.com/2021/02/17/life-part-38/#comment-119... on Eric Lippert's blog.
ur-whale 5y ago
> It wouldn't be bad at all if programming languages were localizable. What a terrible idea.
Jach 5y ago
I'm curious, do you speak another language? Anyway, I think the history of programming languages indicates that it wouldn't be all that helpful, simply because nothing's really caught on, despite many opportunities. What does seem useful is being able to have a way of representing non-ascii characters in source code, at least with comments but hopefully with symbols and of course with data, but even in languages that let you trivially define your own names for everything including the basic keywords and standard functions, you don't really see localization attempts or non-English speakers caring. It's more than good enough to just have native-language documentation that explains the concepts behind the English tokens; you need this in English too since it's not like there's always a clear direct correspondence between the English dictionary meaning(s) and the programming language's meaning(s) of the same word/abbreviation.
saagarjha 5y ago
AppleScript had this! But they ended up not shipping it.

by ghego1 5y ago

traceroute66 5y ago

> It wouldn't be bad at all if programming languages were localizable That is an admirable dream to have, and one that I have sometimes had myself. Unfortunately, as with most things reality soon puts an end to it. First, the dream is only really a dream you can have with the luxury of a Western language. It is unlikely to be viable once you start looking further East in the direction of e.g. Kartvelian languages (i.e. low number of speakers worldwide and even fewer with relevant specialisms in programming to write compilers) or Asian languages (e.g. Japanese and its particles and other complexities). Second, when you are writing code you don't really want to have to worry about the possibility of debugging your compiler. Sticking to English means the likelyhood of a more robust compiler because of more widespread adoption. You also remove technicalities such as UTF-8 or whatever else that might cause indirect issues. Its a bit like science really. Sure you can write your papers in your native language, but the reality is if you're serious about your work being discovered and are interested in being offered bigger and better jobs, you'll want to publish in English sooner rather than later.

pyrale 5y ago
> Unfortunately, as with most things reality soon puts an end to it. Usually, when a thing gets labeled as a dream, people don't try very hard either. > Sticking to English means the likelyhood of a more robust compiler because of more widespread adoption. The comment you quote specifically talks about localizable software, not having one compiler per language. When you I18n a website, you don't write n sites, for instance.
- traceroute66 5y ago
  > Usually, when a thing gets labeled as a dream, people don't try very hard either. Some things are hard, but worth trying. Other things are a dream because the reality is they are unachievable either due to the realities of practical constraints or because the amount of work involved would be hugely disproportionate to the benefit. For example, I mentioned Kartvelian languages. How about we specifically look at Laz which according to Wikipedia at the last count in 1980 had only 22,000 native speakers. Writing a Laz compiler ? I'd say if we're being totally honest its a dream, not just "hard work".
  - pyrale 5y ago
    > the amount of work involved would be hugely disproportionate to the benefit. And you can trust english speakers to properly assess the benefits of I18N, right? > Writing a Laz compiler ? I'd say if we're being totally honest its a dream, not just "hard work". As I said in the message you quote, internationalizing a compiler is not the same as rewriting it. If you consider that making languages accessible to other languages means each natural language should have its own programming language and compiler, of course it's going to be hard. But that's moving the goalposts. First off, you don't need to port a programming language to every natural language. Some smaller goals would already help. For instance, making it easy for third parties to i18n the language and libraries would be a significant enabler.
  - JadeNB 5y ago
    > Writing a Laz compiler ? I'd say if we're being totally honest its a dream, not just "hard work". This seems like letting the perfect be the enemy of the good. "We can't possibly localize for every possible language ever" is not much of an argument for why localization itself isn't worth it.
temac 5y ago
IIRC, TI Basic dynamically translated keywords (and probably function names) depending on the current langage. That's less interesting if you have lots of libraries if you don't translate them.

junon 5y ago

> It wouldn't be bad at all if programming languages were localizable. Go switch Excel or Google Sheets into a language you don't know. Then try to use formulas with them. Come back and tell me if localized programming languages are a good thing after that. :D

pyrale 5y ago
> Go switch Excel or Google Sheets into a language you don't know. I don't believe that point supports your claim. Switching excel to a language you don't know is a good example of the benefits people who don't speak english get from localized languages, not the other way around. > Come back and tell me if localized programming languages are a good thing after that. :D The truth is that localized excel has enabled a generation of people speaking poor english to still do pretty dope stuff for their business. Likewise, localizable languages for children (e.g. Hedi) work pretty well at helping children discover computers before they have a firm grasp of english.
- junon 5y ago
  And it makes support, reusable code, common understanding, and readability (in a team) fly out the window, and increases the amount of development overhead of whomever has to maintain the language.
  - tasogare 5y ago
    Only if the said support and code are not localized too. I'm using all my devices in English because it's easier to find help online but I can see why people less proficient in it would prefer localized software down to formulae and documentation.
  - pyrale 5y ago
    > it makes support Support is already a problem currently, because personalized error messages are less searchable but more useful than generic ones. Moving to error codes is a good example of an orthogonal concern that would incidentally help i18n. Supporting error formats that can be treated by machines is a further unrelated step that would also benefit i18n. So I would say the stuff we already do tend to make this concern less relevant. > reusable code That's an orthogonal concern. You don't write new code when you i18n something, you just create dictionaries. > common understanding, and readability (in a team) I don't believe anyone is making the point that one team should write in separate languages. However, a team able to choose its own language (possibly the one used by the rest of the business) is a plus. In non-english countries, it's very common to have code written in english to describe a business that is done in local language, with really bad translations of business terms. This already causes issues. > increases the amount of development overhead of whomever has to maintain the language. Why would the language maintainer do the i18n themselves?

BiteCode_dev 5y ago

> It wouldn't be bad at all if programming languages were localizable. It wouldn't be bad indeed, it would be terrible. I wouldn't be against some IDE add-ons allowing you to see the keywords in your language if you wish, but the underlying names should stay in english. And the function names as well. Otherwise: - you duplicate the documentation effort, which is already a burden; - you make googling things extra hard - people will use their language features, which means non ascii chars. Good luck typing "La leçon du père noël à l'école de la forêt" with something else than my french keyboard. - IT is nothing but thousands of conventions glued together. And names are a hell of a shortcut to describe conventions. Break that and you destroy trust, reliability and productivity. - you split the community. FOSS works so well because we can collaborate so well: we have one rosetta stone that lets us do so. Is has a basic alphabet, few rules, and is quite easy to learn. I'm a french Python dev, and Python 3 does allow you to write variables names with french accents. I would never do that, and really hope nobody ever does.

pjerem 5y ago
I'm also a french developer and though i've been very pedantic in the past against non-english code, I must say today that I really prefer "french" well expressed code over "english" code full of errors, "faux amis" everywhere and wrongly expressed intentions.
- BiteCode_dev 5y ago
  The kind of code you talk about are usually internal only. People don't write libs, framework or main stream language in those situation. In that case, then it's ok to bite the bullet, to avoid the worst case scenario. But you are already in a bad place to start with. Because if you put in prod some code by somebody who can't write english properly, then it means your team doesn't have access to most information resources in the world. So your problem here is damage control, hardly a situation to generalize from.
  - pjerem 5y ago
    There’s a lot (maybe a majority where I live) of people who can perfectly read and understand English but not write a single sentence without making errors.

DylanSp 5y ago

Early VBA did this, apparently - see https://ericlippert.com/2021/02/17/life-part-38/#comment-119756 https://ericlippert.com/2021/02/17/life-part-38/#comment-119... on Eric Lippert's blog.

ur-whale 5y ago

> It wouldn't be bad at all if programming languages were localizable. What a terrible idea.

Jach 5y ago

I'm curious, do you speak another language? Anyway, I think the history of programming languages indicates that it wouldn't be all that helpful, simply because nothing's really caught on, despite many opportunities. What does seem useful is being able to have a way of representing non-ascii characters in source code, at least with comments but hopefully with symbols and of course with data, but even in languages that let you trivially define your own names for everything including the basic keywords and standard functions, you don't really see localization attempts or non-English speakers caring. It's more than good enough to just have native-language documentation that explains the concepts behind the English tokens; you need this in English too since it's not like there's always a clear direct correspondence between the English dictionary meaning(s) and the programming language's meaning(s) of the same word/abbreviation.

saagarjha 5y ago

AppleScript had this! But they ended up not shipping it.