5 ms·

Back in the 80s, Infocom [1] created a database program named Cornerstone. Because it was an integrated environment, identifiers were abstracted. A line of co

by spc476 9y ago

Back in the 80s, Infocom [1] created a database program named Cornerstone. Because it was an integrated environment, identifiers were abstracted. A line of code displayed on the screen as: xn = (A * y) * x * (1 - x) was actually stored as: id17 = (id1 * id11) * id10 * (1 - id10) and there was a mapping of internal IDs to visible names: id1 A id2 B ... id10 x id11 y ... id17 xn The upshot---you could change the name of a variable anywhere in the editor and the code would still work because the "name" picked by the programmer was not the actual "name" used by the system. I often wonder if that can't even extend to keywords in a language as well, translating this [2]: medan not_done börja för x:= 1 till 5 gör börja om person^.age = 120 så too_old(person); om person^.age > 130 så gåtill person_should_be_dead; slut; slut; into: while not_done begin for x := 1 to 5 do begin if person^.age = 120 then too_old(person); if person^.age > 130 then return person_should_be_dead; end end Or heck, while we're at it: while(not_done) { for (x = 1 ; x <= 5 ; x++) { if (person->age = 120) too_old(person); if (person->age > 130) return person_should_be_dead; } } But I'm not holding my breath on this. [1] Yes, the company that made all the text adventure games. [2] http://boston.conman.org/2008/01/04.1 http://boston.conman.org/2008/01/04.1

sethrin 9y ago
ALGOL 68 was published in multiple languages, but if you meant that the interpreter could switch between languages, Perl and some others have you covered: https://en.wikipedia.org/wiki/Non-English-based_programming_languages#Modifiable_parser_syntax https://en.wikipedia.org/wiki/Non-English-based_programming_...
jhbadger 9y ago
I realize that Perl is no longer all that popular of a programming language, but it had a lot of features along these lines -- you could even program it in Latin! #! /usr/local/bin/perl -w use Lingua::Romana::Perligata; adnota Illud Cribrum Eratothenis maximum tum val inquementum tum biguttam tum stadium egresso scribe. vestibulo perlegementum da meo maximo . maximum tum novumversum egresso scribe. da II tum maximum conscribementa meis listis. dum damentum nexto listis decapitamentum fac sic lista sic hoc tum nextum recidementum cis vannementa da listis. next tum biguttam tum stadium tum nextum tum novumversum scribe egresso. cis
- oblio 9y ago
  Perl might not be that popular precisely because you could even program it in Latin :D
kqr 9y ago
Sure, but why? I mean, even without the "internal IDs" you're basically talking about creating a Pascal code generator and hooking it up to an early stage in the existing Håstad compiler. A first year CS student could do that as a course project. It's not that complicated. But there are a few reasons we don't do that. Like the Sean Conner article argues, the specific keyword symbols we use barely matter. Sure, you can come up with pathological cases with obviously bad choices of keywords, but all reasonable choices can be learned in a matter of minutes and then you're good. As long as a for loop behaves like a for loop it really doesn't matter if we write "for", "för", "meanwhile", or "සදහා". We'll learn to recognise the symbol, whatever its etymology. Because of the above, when we "transpile" (which is apparently what the kids call compilation these days) we tend to want to do it to a language that is sufficiencly different (i.e.not a language whose only difference is that the keywords are made up of different symbols). And when you do that, you'll get code that uses idioms from one language but syntax from the other. And in your attempt to go from 100 people being able to read your code to 100,000 people, you accidentally went to 0 people.
akashakya 9y ago
But this will solve the problem only for the languages which are similar to English, because they share the same grammatical structure differing mainly only in the keywords. This is trivial to fix with approach you mentioned, But for the rest of the family of languages this require more change, (Sometimes change in the whole programming model) For example in Kannada language (or any other Dravidian language) sentence formation itself is different. In English you can read 'if' statement as a proper sentence ("If a equals to Zero") but in Kannada conjunction appear at the end, 'if' sentence is more like "a equals to zero 'then'", so these kind of changes requires non-trivial changes to programming languages. As an example I was trying to 'alias' basic functions (if, for, define... etc) to Kannada languages in Lisp (because its easy in lisp!), but these kind changes breaks "S-Expression" format due to change of the position of the function in the list. And typing in these languages in typical US-en keyboard is whole new problem in itself! But I believe that some problems can be expressed better in languages with different structure or at least better to its native speaker.
- carussell 9y ago
  Regarding Lisp's ordering, this has come up in the article "What if Lisp was invented by the Japanese?"[1]. Note also that in the comments to that article[2], I mentioned that "Japanese Lisp" is something I find easier to read and would prefer to write, even as a native English speaker. 1. http://lispnyc.org/blog/euske/what-if-lisp-was-invented-by-the-japanese http://lispnyc.org/blog/euske/what-if-lisp-was-invented-by-t... 2. https://news.ycombinator.com/item?id=2213012 https://news.ycombinator.com/item?id=2213012
  - kazinator 9y ago
    If Lisp had been invented in Japan, maybe the main connective of an expression would have ended up as the last item visually: (1 1 +). Maybe. However, it would still be the first element of the list in the abstract data structure: i.e. the equivalent of (car '(1 1 +)) -> +. (Or, rather, of course, ((1 1 +)' car) -> +. Let's use the fantasy read syntax.) The main point is not that + is leftmost or rightmost, but that it's at a fixed position in the data structure, and that it is the first/most accessible position.

by spc476 9y ago

sethrin 9y ago

ALGOL 68 was published in multiple languages, but if you meant that the interpreter could switch between languages, Perl and some others have you covered: https://en.wikipedia.org/wiki/Non-English-based_programming_languages#Modifiable_parser_syntax https://en.wikipedia.org/wiki/Non-English-based_programming_...

jhbadger 9y ago

I realize that Perl is no longer all that popular of a programming language, but it had a lot of features along these lines -- you could even program it in Latin! #! /usr/local/bin/perl -w use Lingua::Romana::Perligata; adnota Illud Cribrum Eratothenis maximum tum val inquementum tum biguttam tum stadium egresso scribe. vestibulo perlegementum da meo maximo . maximum tum novumversum egresso scribe. da II tum maximum conscribementa meis listis. dum damentum nexto listis decapitamentum fac sic lista sic hoc tum nextum recidementum cis vannementa da listis. next tum biguttam tum stadium tum nextum tum novumversum scribe egresso. cis

oblio 9y ago
Perl might not be that popular precisely because you could even program it in Latin :D

kqr 9y ago

Sure, but why? I mean, even without the "internal IDs" you're basically talking about creating a Pascal code generator and hooking it up to an early stage in the existing Håstad compiler. A first year CS student could do that as a course project. It's not that complicated. But there are a few reasons we don't do that. Like the Sean Conner article argues, the specific keyword symbols we use barely matter. Sure, you can come up with pathological cases with obviously bad choices of keywords, but all reasonable choices can be learned in a matter of minutes and then you're good. As long as a for loop behaves like a for loop it really doesn't matter if we write "for", "för", "meanwhile", or "සදහා". We'll learn to recognise the symbol, whatever its etymology. Because of the above, when we "transpile" (which is apparently what the kids call compilation these days) we tend to want to do it to a language that is sufficiencly different (i.e.not a language whose only difference is that the keywords are made up of different symbols). And when you do that, you'll get code that uses idioms from one language but syntax from the other. And in your attempt to go from 100 people being able to read your code to 100,000 people, you accidentally went to 0 people.

akashakya 9y ago

But this will solve the problem only for the languages which are similar to English, because they share the same grammatical structure differing mainly only in the keywords. This is trivial to fix with approach you mentioned, But for the rest of the family of languages this require more change, (Sometimes change in the whole programming model) For example in Kannada language (or any other Dravidian language) sentence formation itself is different. In English you can read 'if' statement as a proper sentence ("If a equals to Zero") but in Kannada conjunction appear at the end, 'if' sentence is more like "a equals to zero 'then'", so these kind of changes requires non-trivial changes to programming languages. As an example I was trying to 'alias' basic functions (if, for, define... etc) to Kannada languages in Lisp (because its easy in lisp!), but these kind changes breaks "S-Expression" format due to change of the position of the function in the list. And typing in these languages in typical US-en keyboard is whole new problem in itself! But I believe that some problems can be expressed better in languages with different structure or at least better to its native speaker.

carussell 9y ago
Regarding Lisp's ordering, this has come up in the article "What if Lisp was invented by the Japanese?"[1]. Note also that in the comments to that article[2], I mentioned that "Japanese Lisp" is something I find easier to read and would prefer to write, even as a native English speaker. 1. http://lispnyc.org/blog/euske/what-if-lisp-was-invented-by-the-japanese http://lispnyc.org/blog/euske/what-if-lisp-was-invented-by-t... 2. https://news.ycombinator.com/item?id=2213012 https://news.ycombinator.com/item?id=2213012
- kazinator 9y ago
  If Lisp had been invented in Japan, maybe the main connective of an expression would have ended up as the last item visually: (1 1 +). Maybe. However, it would still be the first element of the list in the abstract data structure: i.e. the equivalent of (car '(1 1 +)) -> +. (Or, rather, of course, ((1 1 +)' car) -> +. Let's use the fantasy read syntax.) The main point is not that + is leftmost or rightmost, but that it's at a fixed position in the data structure, and that it is the first/most accessible position.