Non-English-based programming languages
en.wikipedia.org
en.wikipedia.org
This all brings me to the thought that native-English speakers probably have a rather different experience with programming languages, since the keywords must constantly invoke deeply ingrained associations but that's in turn modified by regularly seeing and thinking of them in the programming context.
КОНЕЦ ЕСЛИ
However, my experience teaching Japaneses has been that what is crucial if you want to make a programming language accessible to different nationalities is to translate error messages correctly. Learning IF, FOR, RETURN is not hard. There are 20 words max to learn. You could learn that many kanjis in one day if you needed. However, when you are not good at English, understanding "Access error: Array index is out of bounds" requires another level of understanding and vocabulary.
(* which would probably get closed by s.o. mods)
Let's be clear: it is my opinion that today, basic english is a pre-requisite to any programmer.
What I am saying is that people making "native" programming language seem to want to change that and that they are misguided if they think the language is the crucial part. The crucial part are the error messages, which indeed are often very poorly translated.
Yes, heap/stack would look weird in french as well, but as weird as they look in english the first time you encounter them. However if you translate the error message correctly, a novice programmer will understand that it is a memory problem and may try to hunt the error more efficiently.
But you're right, people who don't speak English very well (and aren't too experienced) often don't even notice non-fatal errors.
I still think that showing translated error messages isn't very good. 1) Messages are often translated poorly (I won't go into detail here) and sometimes don't even make sense 2) Googling for a translated message won't turn up (m)any results 3) Poor translations might eventually be fixed, but IMO error messages should be considered part of the API
I think the best recourse it to display the original message _and_ a translated message, or _maybe_ an (international) error code and a translated message.
The great thing about the Japanese language is that with kanji you can make messages extremely concise, e.g.:
"Access error: Array index is out of bounds" --> "エラー: 境界外読取/書込"
which would make it acceptable IMO to display messages side-by-side. (It's unfortunate that "error" became "エラー" in Japanese)
The "searchability on Stack Overflow" argument may vary depending on language, by the way - Japanese is one of the languages where technical information written in the language is fairly abundant (considering JP natives tend to avoid writing in English themselves and rather stick to writing Japanese), but this may not be true for other languages. Another factor is how likely the speaker of the language is to be English-bilingual.
At least with respect to error messages, that has not been my experience. I've almost never had success googling Japanese error messages. That (and the insanity with remembering how to get java to display English error messages, since it doesn't respect LANG/LC_ALL) is 100% the reason why I gave up on using Japanese on my development system.
It's very hard to find solutions online when you only get a localized error message.
That was true in the old days with C or Pascal, but it's not much the case any more. Modern C++ has about 100 keywords [1]. Even Swift (Apple: "easy to learn") has about 100 reserved words.
[1]: https://en.cppreference.com/w/cpp/keyword [2]: https://www.quora.com/What-are-the-reserved-Swift-keywords
I am a native English speaker and former ESL teacher with a masters degree in applied linguistics, as well as veteran developer.
Moreover, when you cross over those jargon terms into their regular meaning, hilarity ensues.
For example, you can easily prove that oaks are infinitely tall in winter. Start by observing that in winter, oaks don't have leaves. Then consider the graph-theory definition of "tree" and "leaf".
That's debatable. It's impossible for me to say "if" in any context without thinking about programming now. I can't help it.
When I was a younger programmer (as in, during the first few years), I discovered that assuming boolean / formal logic meanings for {if, or, else, and} in communication with my spouse (art + sales, and very smart, though not a programmer or trained in symbolic logic) resulted in, shall we say ... miscommunication. So I had some unintended help in building the separate registers of meaning / communication. :-)
Building separate meaning registers for communication does take some time.
I cringe every time I hear the and/or thing translated to Spanish, usually several times in a row.
Not sure if it's the usual mistranslation or it's also idiotic in the original text.
But "or" in English doesn't always mean xor in code. Sometimes it is the same as or in code.
There exist languages which lack this ambiguity. Latin has two different words for "or" – "vel" (inclusive) and "aut" (exclusive).
1: do you think it's A or do you think it's not A? 2: yes (assigning a truth value to the or expression rather than indicating which or operand is true.)
"Do you want /pizza or a \burger\?" = XOR
"Do you want /pizza or a /burger/? = OR (as in programming)
It can make a good (though well-worn) joke to answer the XOR version with "Yes."
“Or” in English can mean either exclusive-or or inclusive-or (usually it means the latter), and/or is a means to specify inclusive-or without ambiguity (the parallel construct for exclusive-or is “X or Y, but not both”) used mostly in contexts where misconstruction can be exotics to the drafter of the text, such as contracts and formal policy documents.
In code, the meaning is already unambiguous; in all languages I am aware, “or” or the symbol referred to in speech with that name (e.g., “||”) is strictly inclusive, and do there is an exclusive-or operator, it is different.
But in type system the disjunction concept represents 'either', the concepts are more like how people refer to 'or'.
I can't think of any where that's true; logical “and” and “or” are usually exactly what they claim to be, and many languages implement both as short-circuiting operators, whereas XOR can't short circuit because you can never know the result without considering both arguments.
Programmer's spouse: Honey, go to the shops and buy 1 bottle of milk, if they have eggs buy 6.
Programmer brings home 6 bottles of milk.
Let us be clear that this is US English and not British, but I agree with your sentiment: that the keywords are more a linguistic jargon than anything.
Although the main topic here is about other languages, there are also nuances within the two main streams of English that it's also a little wierd sometimes.
For me, I spell color with a U: ie. colour, but when coding, it's always been the US variant. I've typed this word so much that when I need to type it in my variant, that colour just looks wrong, even though it's the correct spelling in (my area).
Occasionally, when skimming British code, I've come across colour variables and it looks wrong. Similarly, I've looked at French code and there are similar strange things that leak out. The same for Russian and Japanese code I've encountered, eg:
> function <insert_diacritic_or_kanji_here>(char p)...*
The purist in me really wants to state: "everyone should type US English", but the more accepting part of me concedes that maybe keywords should be internationalised (/internationalized) too. Maybe a preprocessor system would suffice (eg somecode.c.jp -> somecode.c), but as you state: it doesn't seem right because of the 'jargon' nature of it.
The good news is that machine code and punch cards have no language, so maybe we could revert to using that and then we can neatly skip over this issue entirely ;-)
So really, this is exactly the same problem human language exists to solve. There's no getting away from it.
Aren't most instruction names are English abbreviations?
Maybe we can internationalize those too. Just to be consistent of course.
I think you're thinking of boring old assembly...? eg (a move instruction):
> MOV EAX,15
Yes you're right about the abbreviated english, but that's why I didn't suggest it as an i18n solution.
As english, I think programming language mostly comes somewhere between willful butchery and deep elegance. Some words are like a weird riff off newspeak (grep, troff, etc), some words are obvious cultural artefacts of people trying to show how pragmatic and unpretentious they are (Factory, Object, Bash, etc), while others are trying to show some kind of inculcation, like maths terms, or stuff from electronics, but all of it has this great feeling of cultural-technical history. Some are these weird mysteries, like, why did early teletype use allcaps? Isn't lower case more legible? Did the entire early history of programming get written in shouts because the earliest users were military guys that liked shouting?
“Generic”, “general”, “generalize” and “specific”, “special”, “specify”, etc. all come from the relation between “species” and “genus”, where genus is a larger category containing a species. The use of these in a programming context is not too far removed from the same usage in non-technical conversation or in (non-biology) technical contexts like philosophy or mathematics.
Similarly for “abstract” (meaning idealized or separated from particular cases) and “concrete”, which have been used in logic/philosophy for a long time.
Static means unchanging.
Void means “empty”, or in a legal context invalid.
> why did early teletype use allcaps
Because it replaced humans listening to Morse code, which has no lower case. Also, the first primitive keyboards from the mid 19th century used something like piano keys, which take up a ton of space, and even still up through the 1960s data transmission was expensive so people wanted to save every possible bit.
You can read about https://en.wikipedia.org/wiki/Teleprinter, https://en.wikipedia.org/wiki/Telex, https://en.wikipedia.org/wiki/Teletype_Model_33, etc.
Sure, but Morse code doesn't have upper case either. It doesn't have case! It just has one set of letters and numbers and punctuation marks, it doesn't specify what case the letters should be represented in when they are not written in Morse code.
In my own case (pun intended) I used to copy Morse code by writing it down in my own weird mix of lowercase letters and semi-cursive writing.
It was just the convention to transcribe them using all upper case.
This is exactly what bothers me. Why no lower case? Why not no upper case? You'd need the same number of keys, and it would be more legible. It would use the same amount of space.
A telegram is a short enough message that being hard to read isn’t really a bottleneck. If it costs a day’s wages to send a couple sentences, the recipient is going to be able to spend a couple minutes on figuring out what it says. People weren’t sending novels around by telegraph.
As I responded to you elsewhere, the idea that capitals are hard on the eyes is just a myth. All caps with no spaces is bad, but that's because of the missing spaces.
Here's a bit of parody code I wrote on the subject. https://github.com/ksaj/Capitalize.Lisp
(protip: It doesn't do anything the comments say it does, even though the results appear to.)
It was considered a bit flash to use this but for interactive programs input prompts looked a lot nicer.
Nowadays I only use ALLCAPS to visually mark code that I want to refactor, or where later attention is needed, such as for code that might open security vulnerabilities if handled incorrectly.
https://meh.com/forum/topics/capital-crimes-part-1--shout-sh...
No, it isn't.
I believe the result is that lower-case words are easier to read at sufficiently close distance but legibility drops off sooner as distance increases. I also believe that while upper-case words may be less legible, individual letters are more legible as upper-case, and therefore upper-case words may be easier for very inexperienced readers who haven’t learned words by shape and still piece them together by letter.
"The result" is that if you pull people off the street and ask them to read capitalized or lower-case text, they're slower at reading the capitalized text. People like pasabagi want to leap to the conclusion that that means reading capitalized text is harder. That conclusion is unjustified; the rest of the result is that the difference in reading speed disappears after a small amount of practice. Lowercase text is more common. But obviously that can't justify the choice of a writing system; any writing system will be common if it's in common use.
Note also that your claims don't actually refute pasabagi's original conclusion. If lowercase text is easier to read because of its ubiquity, this still means we should use lowercase text—the same way that we use the right-hand rule for screwing things in and out. Books, and lowercase, were around longer than telegraph.
https://docs.microsoft.com/en-us/typography/develop/word-rec...
> since your claim goes against the accepted ‘wisdom.’
This is overly generous as a description of a collection of myths that have been known false for decades.
> Note also that your claims don't actually refute pasabagi's original conclusion. If lowercase text is easier to read because of its ubiquity, this still means we should use lowercase text
No, it doesn't, because if we ignore your advice and use capitalized text, capitalized text will be common enough that the advantage of lowercase text disappears.
I see you're talking about some alternative universe where you convince significant portion of publishers (if not a majority) to switch to uppercase. The practical question is, did teletype or early programming languages or road signs flip us over to that universe? Doesn't seem so. In the world where I am, lowercase text is more legible because it's ubiquitous.
The styles don't compete with each other for space in your mind. It's just a question of whether you're used to them.
English doesn't have genders and cases [1] so grammatical constructs such as if/then/else, case of, unless etc. suffer much less than when you have gender and case. Oh, god, and plural forms of those.
For a Russian speaker using a PL in Russian is constant pain as your brain tries to add all the missing parts to the words:
if(count(letters<must have a plural ending, accusative case>) > limit<must have singular ending, genitive case>){
words.append(word<must have singular ending, accusative case>)
}
[1] Well, it does have those, but not in the same capacity as other languages.
I buy your thought, and your prediction means that Mandarin speakers might have an easier time with a Mandarin programming language than a latin or slavic language speaker would have with a latin- or slavic-based programming language.
My experience was actually not bad; I didn't have any trouble associating the words with the abstract concepts involved in sending the turtle around the screen. I was doing fairly simplistic stuff though, I'll concede.
I wonder if instead of decoding words when programming "in the hardware", we form new associations for the (relatively) limited set of keywords languages provide? I mean, in most code, the words provided by the language make up maybe 5%-10% of the code. The names we give things seem much more important.
To your point of not being able to tune out inane heard content in my native language I agree. I'm not proficient enough in any others to have tried it, sadly.
For example I learned that to print a line in Pascal you use writeln() at 12 or so. It didn’t occur to me until 10+ years later that writeln is shorthand for “write line”. To me it’s just a symbol with no meaning outside that particular context.
I know what you mean, but I think you get over it quickly. There's a switch in mental context as you start to code and the fact that certain keywords mean something in your native language just doesn't matter.
Currently in JavaScript the various forms of "var" and "for" makes me cringe involuntarily when I'm mentally parsing code. "for let foo of bars"?? Gah!
I would imagine stuff like that makes a language harder to translate because instead of words, you now have an ordering that might not work. I was surprised to see so few languages on that list where it was essentially a direct keyword translation. There's very little English in C-like languages until you actually start naming everything in the libraries.
These days, I am hearing more Russian and Dutch. Along with Spanish, German and Swedish, impossible for me to speak but hovering at the edge of understanding, my brain cannot ignore when I hear them.
Programming languages, after 40 years of it I'm not aware of any particular effect of the English words. With "Wolfram Language", for instance, I think it would help if the words were based on Esperanto or Swahili, as I can never anticipate the magic invocations needed.
Language is weird.
Pinyin for Chinese isn't self contained, you have to guess what really means. If I saw pinyin code, unless it is absolutely necessary, like not ambiguous and no proper English translation, it won't pass CR if I am reviewing it.
That's probably the reason. I'd bet after working for the same time with 1C, you (or I, for that matter) would completely ignore keywords and names being in the Russian language. You'd die from the boredom much earlier though, but that's a different matter)
Btw, END IF is as weird as КОНЕЦ ЕСЛИ.
Childhood does things to your brain. And language recognition doesn't work the same way as motor skills.
Surprisingly, one of the main issues that I thought of was a cultural one. Thais culturally don't use a single word to encapsulate complex meaning. We use a combination of words to capture that kind of meaning.
Just to give an example: a taxi driver is 'human-drives-taxi' in Thai. A barber is 'tradeperson-cuts-hair'. So, the programming language would be really verbose.
Also, since programming originates from the western world, we never really have Thai words for many concepts in programming. I've been programming for years, and I have no idea how to say 'software', 'hardware', 'class', 'inheritance', 'encapsulation', 'abstraction', 'refactoring' in Thai.
I'd argue that if you said most of these words to non-programmer native english speaker, they'd have the wrong connotations anyway.
Programming has become (is becoming?) an international language of its own (albeit with outsized influence from english). I think eventually it will be much like the latin used in science and medicine today.
I remember at work a colleague asked "how do I kill chubby slave?", which didn't sound strange at the time, since Chubby was an authentication system (IIRC).
But, when thinking about it, that's probably a very offensive sentence in English.
Of course, you get plenty of people saying that we should all not care about the origin or other meanings of words in programming, and yet they tend to care deeply about maintaining the status-quo.
Because changing is more work than not. It shouldn’t be a surprise when people get upset because you want to change fundamental terminology in some software’s architecture because a group is triggered by the originally chosen words.
E.g. Somehow master and slave are more offensive than killing parents and leaving orphans?
Now, assuming that you are just using the term as a trite implication that people bothered by these terms are just easily upset, I would question that. The transatlantic slave trade was a tragedy and its effects still haunt a huge number of people to this day.
Would you be OK with using holocaust analogies in your code? I would hope you would say no, and I imagine most people would agree. So we have established that there are references that are not suitable to make, and it is a question of degrees.
Changing these things is some work, yes, but it makes working with those systems nicer for a large number of people, for whom those analogies are a negative thing.
I'm definitely not advocating that every other term in computer science is defensible either. If you have an issue with certain ones, I would suggest bringing them up.
No one is suggesting that it should be illegal or anything, just some projects make those changes to improve the quality of those projects. And yes, how nice it is for people to work with a thing is absolutely a part of its quality.
We now have a set of programming terms that are a mix of: borrowings which already existed in other contexts (possibly of Latin or similar roots), Russian words instead of English ones, and straight up transliterated calques. This all coexists completely naturally because the words now serve as roots for further derivation and forming a layer of slang on top of the formal terms. Notably, young people are quick to appropriate foreign words—and they tend to be the ones who get into new tech.
There were (joking?) proposals for using Russian-root words for computing terms, and by now they sound like bringing an Orthodox priest speaking Old Church Slavonic into a datacenter.
At the same time, in colloquial language we happen to replace English words with unrelated but similarly sounding Russian words. For example, saying мыло (soap) instead of 'mail' or 'поймать лося' (catch a moose) for activated stop loss order.
Including my favorite variant, the “Russian-English Computer Learning Set”: http://sannata.org/articles/subor.shtml
Though the manufacturer appears to be wholly Chinese.
I struggle to imagine that thai can't do similar extensions - inheritance maps directly onto the personal concept of ownership down (human) lineages, surely you have that?
Serious but weird suggestion, talk to a poet.
They did; that's why they were repurposed in computing.
"Ware" means goods, especially something for sale. Hardware means the wares used in construction: screws, hinges, brackets and so on, or any equipment. Extending that to computer hardware is straightforward.
"Software" is new for computing, by analogy to hardware.
"Inheritance" has the meaning taken from biology or reproduction. "You've inherited your mother's good looks!"
"Encapsulation" means to wrap something in a capsule; online dictionaries say it was first used in 1872, and gives an undated example of a pilot encapsulated in a cockpit. I don't have the subscription to see the 1872 usage.
"Class" means a group of things sharing some characteristic. Remember that the code you wrote is a class definition; "class" has its normal, English meaning.
"Refactor" may be novel in computing, I'm not sure. You could also apply the word to a document.
Consider that a correction on what I originally wrote.
Now take a time-machine back to then and meet with The Man On The Clapham Omnibus, a term used in english legal law to denoye the everyman, the utter mr. average. Use those terms on him:
'software'?
(blinks)
'hardware'?
"ah yes, as purchased at the ironmonger's"
'class'
"oh yes, like in prep school?"
err, no.
"well then like the labourers and shipmen, and the aristocracy? That kind of class I take it"
etc. etc. The terms are easy to transmute but it hadn't happened then. Agreed about encapsulation, abstraction, refactoring etc though.
Disagree with me at your peril, I got downvote rights yesterday - so does one feel luck, punk?
Well, does one?
:)
"Class" — yes, like in school, or social class. The thing in common in 1950 might be "all boys, all age 13-14, all learning chemistry". A Java EarlyTeenChemistryBoy. (Isn't the first example when learning OO programming something like the class Student, a subclass of Person
In any case, my lawyer will argue we don't want the man on the Clapham omnibus, but the better-educated man in the first-class carriage of the 8:15 express to Birmingham.
(You will find you can't downvote this reply, and I think it's poor etiquette to pick some other random comment of mine and downvote that, although that does happen.)
1860 F. W. Farrar Ess. Origin Lang. viii. 172 Every subordinate clause being inserted in the main one by a species of incapsulation.Thais wouldn't want to call their machines (or anything or anyone) 'slave' with serious tone. It sounds offensive.
Thinking about it, native English speakers might have internal struggle about many programming words.
As a non-native english speaker, rude/strange/crude/offensive words don't really cause me emotional impact.
This can happen in English too, eg Experts Exchange <-> Expert Sex Change.
[1] https://ja.wikipedia.org/wiki/%E3%83%87%E3%82%B9%E3%83%88%E3...
Just like German. A fridge is a cold-cupboard, a car is a driving-thing, etc.
But While, if, else, for are concise words.
- lighter is fire stuff
- plane is fly stuff
- tools are work stuff
The term "Zeug" usually translates to "stuff" colloquially as "thing" would be a better fit for the literal "Ding".
I remember trying to learn APL and then watching https://www.youtube.com/watch?v=v7Mt0GYHU9A and was amused that there is this world where programming is just symbols :D
So maybe look at i.e. something apl-like, or maybe ml or haskell or erlang, where so many things you can do with functions and composing them, or even Prolog, where everything could be thought of as a set of rules/constraints to be solved (I think? haven't programmed in Prolog since uni :) )
If you haven't seen them, the late John Scholes did a number of absolutely beautiful demonstrations programming in APL[1], [2], [3].
[1]: https://www.youtube.com/watch?v=DsZdfnlh_d0
The most public APL dialect using the classic symbols (not J/K/Q/etc) seems to be Dyalog APL - they offer one of their older versions 14 free for non-commercial use (Windows), and they offer their current version 17 free for non-commercial use if you give them your full details (maybe Linux as well?). There is a book "Mastering Dyalog APL" by Bernard Legrand from ~2008 which is available as a PDF with companion files from: https://www.dyalog.com/mastering-dyalog-apl.htm although they have added to the language since that book was released.
There are other APL interpreters - GNU APL, NARS2000, ngn/apl, dzaima/apl (Java/Android) in various states of development and license conditions, and the developers of the last two are also sometimes in the APL Orchard chatroom on StackExchange.
Online there's https://tryapl.org/ run by Dyalog, and https://tio.run/# which has three APL interpreters.
The classic 1970s book "APL\360 an Interactive Approach" by Gilman and Rose is online as a PDF here: http://www.softwarepreservation.org/projects/apl/Books/ with other books as well. That's before the {} syntax for anonymous functions was added to the language, and other developments.
Videos:
Jay Foad while he was at Dyalog, talking through some Advent of Code puzzles with APL: https://dyalog.tv/Webinar/?v=Q_vgSN6rza0 (might want to skip the introduction of explaining the Advent of Code puzzle format).
Aaron Hsu with Dhaval Dalal and Morten Kromberg, talking through some problems using APL https://www.youtube.com/watch?v=Gsj_7tFtODk
And anything that you get from YouTube searching for Aaron Hsu, he has several talks / presentations from high level ideas to working with trees represented using arrays.
As an example, here is kertoma.itp (an example routine to calculate a factorial):
Pienen luvun kertoma on
riippuen siitä, onko se pienempi tai yhtä suuri kuin yksi,
joko yksi
tai pieni luku kerrottuna pienen luvun edeltäjän kertomalla.
Luvun edeltäjä on se vähennettynä yhdellä.
Olkoon pieni muuttuja uusi muuttuja, jonka arvo on nolla.
Kun nykyinen sivu avautuu,
pieneen muuttujaan luetaan luku
ja nykyinen sivu näyttää pienen muuttujan arvon kertoman.
This is German VBA:
Funktion VorherigerGeschaeftstag(dt Als Datum) Als Datum
Dim wd Als Integer
wd = Wochentag(dt) ' Wochentag liefert 1 für Sonntag, 2 für Montag usw.
Prüfe Fall wd
Fall 1
' Auf Sonntag wird Datum vom letzten Freitag zurückgegeben
VorherigerGeschaeftstag = dt - 2
Fall 2
' Auf Montag wird Datum vom letzten Freitag zurückgegeben
VorherigerGeschaeftstag = dt - 3
Fall Sonst
' Andere Tage: vorheriges Datum wird zurückgegeben
VorherigerGeschaeftstag = dt - 1
Ende Prüfe
Ende Funktion
If I send the same file to a fellow Dutchman, their Excel can't.
Excel, for some obscure reason lost in time, decreed that the Dutch do not, in fact, separate their comma-separated values with commas. We use semicolons. No one seems to know why Microsoft thinks we apparently do this. That means that a normal bog-standard CSV file won't work by just double-clicking it or opening it in Excel.
That's right: a Dutch comma-separated values file must have semi-colons according to Excel.
LibreOffice meanwhile works with anything you throw at it, in any language, of course. It'll just ask you about the separators, defaulting to commas.
Which reminds me of 10+ years ago when I worked for a consultancy and often on site with one of its main clients. Both were originally Finnish but by then very large multinational enterprises.
Occasionally whilst doing some archaeology investigation of some internal libraries or old systems you encounter an ancient Java (or worse) library using Finnish class and methods names.
Usually confused the heck out of all of us as there never were a Finnish speaker on any of the projects I was on, and I was there for 6 years. But as much as a decompiled java program you can guess what it does, though not what it intended to do...
Using non-English in programming may have made a little sense when they were a smaller Finnish only company, but 10+ years later, many mergers and acquisitions etc and it really did not make sense any more .:)
Considering the offices I worked for them in Oslo, Stockholm and Copenhagen the development teams was all a mix of nationalities (Scandinavians, English, Belgian, Italian, Polish, Indian) using anything but English would have been silly by then.
[0] https://www.scala-lang.org/blog/2017/04/01/announcing-skala....
VBA on this machine has English keywords (Sub/Dim/If/While), but Swedish application APIs (search in Word is Sök for instance). Screenshot of one of the sample macros: https://i.imgur.com/vDWQcWk.png
wer, var, def
My native language is German. Some ideas:
* We can take nouns and combine them to longer nouns. A "list of objects" is "Objektliste". Parsing will be a challenge but it makes the language more terse and auto-completion is faster.
* We also have gender specific articles. It is "das Objekt" and "die Liste". We could use this to have three possible namespaces, so "der Foo", "die Foo", and "das Foo" would refer to three different things.
* All nouns start with an uppercase letter, so your loop index must be "I" or "J". We could have user-defined qualifiers (like const) which are distinct from variables because they start lowercase. So where you have to use @ in Python, we just use lowercase.
- in many C-derived languages, a “list of objects” is spelt “object[]” as a type, with the “list” (array) specifier postfixed. (Functions declared to return arrays take this syntax to quite an interesting extreme.)
- in Perl and some derivative languages, sigils serve as a prefix to denote context of use or type; $var is different than %var or @var, for example.
- In Ruby, a leading uppercase character defines a constant, and some aspects of the language are sensitive to the case of the identifiers used.
Of course, it’d be super interesting to put many of these ideas into a single language, as it could well be quite different (and refreshing!) than many of the languages we use today.
Yeah, but i and j come from math. I've never seen a math paper where people summed a variable using a capital subscript.
I think it might be more interesting to think about how you write a German version of a language that is meant to be English-like. Something like SQL or Cobol.
Für i = 1 bis 2 ...
Für das I = 1 bis 2 ...
Für i: 1 bis 2! Für i: 1 bis 10, aber schnell!
You're reminding me of perl, where $foo, %foo, and @foo can coexist.
I remember at my Dutch university we would get intro to programming courses in Java. We would often discuss things in Dutch, but found it awkward to talk about `null` (the "pointer") and `0` (the integer, which in Dutch is "nul").
In fact, I remember a distinct bug that happened from informal communication of an API. The conversation went (in Dutch):
Student 1 - "What does Function A return if the input is invalid?"
Student 2 - "Nul"
Student 1 - "Null?"
Student 2 - "Yes".
We ended up saying "null" as "naL", with heavy emphasis on the L and kept 0 as "nul", to somewhat mitigate these problems. The awkwardness never really went away.
I wonder if Guido van Rossum when designing Python intentionally bypassed this issue by naming the null pointer "None". This is the only language I know of that uses None, some use "nil" AFAIK, but the language issue (in Dutch) is not avoided in these cases.
I also wonder if other non-native English speakers who wrote English-based programming languages have applied similar considerations to avoid possible confusion between the native language of the speaker and English.
… and I'm a well-educated native speaker.
English proudly possesses a prodigious panoply¹ of… um… phrase particles.
¹ I have never heard this word spoken.
I also love listening to people speak the "pronunciation poem" out loud. It's very interesting to hear how the pronunciation of each second word is changed, just to make it rhyme with the first (mispronounced) word.
https://www.learnenglish.de/pronunciation/pronunciationpoem....
In the ML family the empty alternative of the `Option` type is called `None`; in Haskell corresponding `Maybe` type has `Nothing`.
> While in graduate school at the University of California, Berkeley, Larry Wall and his wife were studying linguistics with the intention of finding an unwritten language, perhaps in Africa, and creating a writing system for it. They would then use this new writing system to translate various texts into the language, among them the Bible.
And Perl was explicitly designed with a slant towards natural-language traits. Wall has said that he didn't know as much about creating programming languages, and that this likely affected Perl. So he might've written about the linguistic aspects instead.
> Wall's training as a linguist is apparent in his books, interviews, and lectures. He often compares Perl to a natural language and explains his decisions in Perl's design with linguistic rationale. He also often uses linguistic terms for Perl language constructs, so instead of traditional terms such as "variable", "function", and "accessor" he sometimes says "noun", "verb", and "topicalizer".
https://yvoloshin.github.io/php/2018/01/20/why-does-php-spea...
The first thought that came to mind as I was writing this was: some kind of logographic APL. I don't actually know what such a thing would like, but I'm sure I wouldn't be able to read it.
It's a good thing, I agree. There is no reason to worry either, as uncommon hard to input unicode symbols in the core language is such a huge usability failure, that those languages simply have no chance of gaining any significant mind share.
Davies' choice of the word "packet" was very deliberate. "I thought it was important to have a new word for one of the short pieces of data which traveled separately," he explained. "This would make it easier to talk about them." There were plenty of other possibilities — block, unit, section, segment, frame. "I hit on the word packet," he said, "in the sense of small package." Before settling on the word, he asked two linguists from a research team in his lab to confirm that there were cognates in other languages. When they reported back that it was a good choice, he fixed on it. Packet-switching. It was precise, economic, and very British. And it was far easier on the ear than Baran's "distributed adaptive message block switching."
I wish that much thought went into other technical naming. (Looking at you, grep.)
∪ - dyadic downshoe is union ( https://tryapl.org/?a=%27ab%27%20%27cde%27%20%27fg%27%20%u22... )
proper-subset isn't builtin; this might do it, but there are probably neater ways
'ab' 'cde' 'fg' {((≢⊆⍺)>≢⊆⍵)∧(≢⊆⍵)=+/⍺∊⊆⍵} 'cde' 'ab'
Not sure it needs "for-all" because functions work on all elements by default. It can have for: loops, but they aren't math-like.
Men du hade inte säga varför du skulle skriver detta på engelska. Till exampel, är engelska mycket bättre än svenska för som programmerarspråk?
To make a programming language based on Polish that captures the core of the language would be pretty strange - variable names would need to change depending on the role of the variable in the expression, and the order of the subexpressions in an expression shouldn't matter.
Function names should change too depending on which subject they are called, and most of the time subject name should be skipped :)
Just like Polish noun cases, I don't see how any of the interesting distinctive features of English are captured by programming languages.
use Lingua::tlhInganHol::yIghun;
<<'u' nuqneH!\n>> tIghItlh!
{
wa' yIQong!
Dotlh 'oH yIHoH yInob
qoj <mIw Sambe'> 'oH yIHegh jay'!
<Qapla'!\n> yIghItlh!
} jaghmey tIqel!
Although compression tools replace the majority of symbols with short Ascii symbols, so it may not show in the final packed code.
It looks like the closure compiler emits Ascii only, using escapes for Unicode symbols that are not transformed.
However, you can also have programming languages with abbreviated keywords or no keywords, which is also sometimes suitable. If there are keywords, I will always do it in American.
(And when writing music, I will write all of the notation in Italian, even though I do not speak Italian. If I don't know the Italian word for something, I will ask someone who does know, and write that.)
```
Enkelt >> var första = "Nej! Jag ville inte att skriver detta!"
Enkelt >> skriv($första)
Nej! Jag ville inte att skriver detta!
```
Pro-tip: You can use LLVM for non-ASCII naming, if you don't want to stick to Enlish-only letters.
[0] - https://enkelt.ml/index.html
[1] - https://trinket.io/embed/python/10bb0ea708?outputOnly=true&r...
What I find more interesting is actually how removed from spoken English most programming language reserved words are.
Taking C and derivatives: "if" is pretty close, and "while" captures the meaning of the word but not its typical usage. The meaning of "return" is correct, but jargon (yes, you're "going back" to where you were called from, but that's not what people mean when they use the word normally). But from there it gets weird fast: "else" reflects a somewhat odd sense of the word that sounds archaic and stilted in human communication; "for" and "break" have little to no connection to spoken language at all.
As far as type names: "int" makes sense if you took high school math, and "char" abbreviates a real word that no one uses ("letter" is the one we get taught in school). But no amount of literacy is going to tell you what "short", "long", "double" or (weirdest of all) "float" mean, those are all terms of art you need to learn from scratch regardless of what language you speak.
So I think it's actually a good example of your broader point, that the meaning of English words as programming keywords is often very different from their meaning in other contexts.
The discussion was about programming languages and English. What on earth is this about?
You're actually compounding the issue here, by invoking jargon from a different field. That's true of the definition of integers you'll find in college level math textbooks, but the word "integer" as understood by normal people (even computer programmers) means "whole number", which is why the type is named that way.
- More languages = more barriers. Gosh we have enough problems with silos within the software dev community as well as languages in real life being one of the main hindrance to mobility. - Learning how to program is a great opportunity to refresh your mind and adopt a new way of thinking, why carrying along the burden of your flawed human language?
Does anyone else know what I'm referring to? It was probably in the late 90s.
Something about VB in German.
Almost 20 years ago I wrote some Excel macros on an even then ancient Windows 3.1 computer with German Excel. I tried for Hungarian notation (as I said, almost 20 years ago) and used d for date. So the end date of some range was dEnde. D is also the first letter of Datei, which is German for file. So when I brought the Document to the boss's newer computer the program got translated but all the variables still had German names except for dEnde, which turned into EOF.
At least the one’s I’ve used, apart from BBC BASIC, and ZX BASIC