Hacker News Reader

Comment by aasasd | Hacker News Reader

Seeing a programming language in your native language after working with English ones, you discover that it looks and sounds pretty ridiculous. My belief is that the native language is ingrained on a low level in the brain, so it's decoded ‘in the hardware’ and directly invokes meanings and associations, whereas a second language goes through at least some level of conscious processing. The very same way, I'm physically unable to shut off the brain's frantic search for meaning when I hear some inane song lyrics or advertisement in my native language—which causes suffering whenever I get near television. Meanwhile, I'm completely comfortable reading or hearing total drivel in English until I consciously try to interpret it. Similarly, I can't skim in English as fast as I do in my language.

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.

КОНЕЦ ЕСЛИ

View on HN

French here, that's my experience as well. I want to emphasize that the huge majority of the non-english native programmers I know are pretty opposed to translating programming languages.

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.

That's a great point. And that combined with the cryptic nature of many error messages could easily make debugging a nightmare for people who don't speak English...

I speak English natively and Japanese fluently, and in my experience error messages (and other messages) that were translated into Japanese are often of rather questionable quality.

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)

I don't quite get the reasoning where you talk about the quality of Japanese error messages, then talk about making it even harder to decipher. Sure you can compress meaning into short strings of kanji, but readability definitely takes a hit when you do that, even to a native speaker. It's not like we're displaying this on paper; there could be better ways to show errors to non-English speakers, eg. more descriptive messages like "エラー: 配列の範囲外へアクセスしています" can be shown by default and perhaps the original error message can show up when you mouseover on it or whatever.

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.

> Japanese is one of the languages where technical information written in the language is fairly abundant

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.

Cannot agree on error messages, had opposite experience with them. I always require all team members to install English versions of runtimes because it is easy to search non-trivial errors on the internet. Many translations are automatic or done by not very technical people and they sound weird in local language, e.g. many terms in Russian, even such simple as "heap allocation", are really weird. An English error that you see for the first time is usually solved via quick search with the first result usually linking to StackOverflow with the correct fix, but with the local language it's often difficult to understand where to start. (But basic English knowledge is assumed)

I guess this is where error codes come in handy.

Not actually unless it's a native OS exception with a well-defined hex code. I was talking in .NET context, and when you get e.g. some SocketException related to setting up UDP multicast parameters only textual description helps for highly relevant search with double quotes. Often there are just no results at all in local language for highly specific complex conditions.

Maybe error messages should just point to pre-prepared StackOverflow questions*

(* which would probably get closed by s.o. mods)

> But basic English knowledge is assumed

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.

I learnt my basic English while programming. Definitely not a prerequisite !

No way. I hate localized error messages. At least in modern times as software vendors stopped putting error numbers into the message.

It's very hard to find solutions online when you only get a localized error message.

> Learning IF, FOR, RETURN is not hard. There are 20 words max to learn.

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

Programming uses the same words as regular English, but it is a completely different linguistic register, so there is never any conflict. It’s like working in any field with its own jargon — you use the meaning that is relevant to the context. In linguistics this is called the Relevance theory of meaning and interpretion, which explains why we do this contextual interpretation easily and mostly without thinking about it.

I am a native English speaker and former ESL teacher with a masters degree in applied linguistics, as well as veteran developer.

> Programming uses the same words as regular English, but it is a completely different linguistic register, so there is never any conflict.

That's debatable. It's impossible for me to say "if" in any context without thinking about programming now. I can't help it.

That's a good point: "never any conflict" describes the final state rather than the growth process.

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.

By the way... has or in English a different meaning than in code?

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.

Yes, "or" in English often is more similar to xor in code. For example if someone says "I want pizza or a burger", that person probably does not want both pizza and a burger for the same meal, whereas in programming an equivalent expression would be satisfied if both are true simultaneously.

But "or" in English doesn't always mean xor in code. Sometimes it is the same as or in code.

There's another way that or_English is different, as illustrated by this frustrating "joke":

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

English "or" is ambiguous between inclusive and exclusive meanings. Most of the time, the intended meaning is inferred based on context, but one can make it explicit by using phrases such as "but not both", "exactly one of", etc.

There exist languages which lack this ambiguity. Latin has two different words for "or" – "vel" (inclusive) and "aut" (exclusive).

It depends on the intonation: / = rising, \ = falling

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

In most programming languages the boolean operation 'or' is actually 'xor'.

But in type system the disjunction concept represents 'either', the concepts are more like how people refer to 'or'.

> In most programming languages the boolean operation 'or' is actually 'xor'.

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.

> has or in English a different meaning than in code?

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

The old classic:

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.

> Programming uses the same words as regular English, but it is a completely different linguistic register, so there is never any conflict.

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

Alternatively, oaks do not have any nodes at all in winter

It depends, do they have any branches?

An oak without nodes? Pretty sure that's just a seed.

There's the old joke about the programmer who was told to go to the store for bread, and while they were there, to get eggs. Still at the store, getting eggs.

While some things are arguably vaguely close in meaning, e.g. `loop`, there are plenty of things which are essentially meaningless (or only coincidentally are words in English) like `car`, `cdr`, `cons`.

Yep. Virtually no word has a concrete meaning without a context. For example the word “guys” which may mean a group of males or just a generic collection of people irrespective of gender depending on the context in which it is used.

It can also mean ropes that are anchoring an object. "When camping, I enjoy pegging the guys" for example.

"When camping, I enjoy pegging the guys" can also have a wildly different (sexual) meaning.

Our friend @inopinatus was certainly making that joke.

Not sure what you mean. In this example, I’m just pitching a tent.

During nice weather, I usually like to open the fly.

> Programming uses the same words as regular English

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 ;-)

> The good news is that machine code and punch cards have no language

Aren't most instruction names are English abbreviations?

Maybe we can internationalize those too. Just to be consistent of course.

> Aren't most instruction names are English abbreviations?

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.

yeah, indeed i was

I think what this question exposes is that the primary consumers of code are humans. Code is only incidentally written for computers.

So really, this is exactly the same problem human language exists to solve. There's no getting away from it.

I remember the english associations of programming words being pretty confusing, to be honest. Generic, for instance, means a standard or non-descript object. Abstract, for another, means something without concrete existence. Static means something that doesn't move, or electrostatic charge. Void is a pretty archaic/unusual word for a space. All these things are a little bit like how they are used in programming languages, but I imagined it would have been easier for me if I'd started out knowing I don't know, rather than trying to figure out how stillness, motion, concrete and abstract, relate to functions.

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?

These are all somewhat sloppy versions of the definitions of these words in common use.

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

>which has no lower 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.

Take it up with Émile Baudot? https://en.wikipedia.org/wiki/Baudot_code

I feel when something becomes so ubiquitous, even though it's obviously inferior, it takes a bit more push than one patent - especially if the patent is mainly about encoding, and barely incidentally about typography. And I don't think it's the case that nobody knew capitals were hard on the eyes. The whole reason why lower case letters exist is because roman allcapswithnospaces are horrible.

The people doing professional book design or handwriting long letters and the people designing systems for transmitting occasional short messages long distances had different priorities.

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.

> And I don't think it's the case that nobody knew capitals were hard on the eyes. The whole reason why lower case letters exist is because roman allcapswithnospaces are horrible.

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.

All caps means no ascenders or descenders, so actually less vertical space per line.

This is a good point, actually. I'm still not sure it works, though - at the lower bounds of visual resolution, are capitals easier to distinguish than cursive letters? Because otherwise, any size capital can be compared to an equivalent box cursive, and I think the capital would be less legible. Perhaps the typically smaller eyes of cursive letters would swing the pendulum the other way, with smeary ink? I think with simply low resolution, cursive would always win out.

The explanation I've always heard was that writing "god" with a lowercase G would have been unacceptable in the 1850s. To a lesser extent, writing personal names without a capital is still seen as a bit odd and potentially an insult.

> Morse code, which has no lower case.

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.

I’m not sure if the early TTY codes, punch card codes, etc. should be considered to have a case either.

It was just the convention to transcribe them using all upper case.

Capital letters didn't mean shouting until after the internet - or at least texting, BBSs and such - became popular.

I think the same for programming languages. For example, all old LISP programs were capitalized. Nowadays we call it lisp and everything is primarily lowercase (Not Even CamelCase). It's pretty rare to see capitalized lisp code these days.

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

Older versions of FORTRAN where upper case though you could use Mixed case for Hollerith statements (used for Mixed case output)

It was considered a bit flash to use this but for interactive programs input prompts looked a lot nicer.

I used to program in assembler. You can't imagine the glee that erupted within me the day I discovered you didn't have to write all caps. It changed my coding aesthetics immediately.

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.

This article has examples of SHOUTING going back to the 1800s

https://meh.com/forum/topics/capital-crimes-part-1--shout-sh...

> Isn't lower case more legible?

No, it isn't.

Lower-case words have a wider variety of shape, as so many letters have markings extending above and below the horizontal lines that bound the letter o. UPPER-CASE WORDS ARE BASICALLY ALL RECTANGLES OF VARYING WIDTH AND FIXED HEIGHT. BUT THEY USE MUCH LESS WHITESPACE, WHICH IS WHAT LOWER-CASE WORDS USE TO CARVE OUT SHAPE.

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.

Word shape is not a well-supported theory of reading. Very skilled and practiced readers are still going letter 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.

Your ideas seem a bit counter-intuitive, so I'll assume they're coming from some literature, and I guess I can't really comment on literature I haven't read. All the stuff I've found (partially what motivated my interest in the first place) were studies showing the opposite, written in the days when ALLCAPS was the normal form of written communication.

I second the neighbor's request for references, since your claim goes against the accepted ‘wisdom.’

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.

> I second the neighbor's request for references

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.

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

If we ignore your advice and use capitalized text only for programming in, while books are still published in mostly lowercase, capitals will be so common for programmers that lowercase text will have no advantage over capitalized text.

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.

Note: I'm not a native speaker.

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>)
   }

etc.

[1] Well, it does have those, but not in the same capacity as other languages.

https://en.wikipedia.org/wiki/Analytic_language https://en.wikipedia.org/wiki/Isolating_language

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.

Interestingly, Perligata (a module that allows writing Perl programs in Latin) attempts to use case endings in variable names to denote their roles in expressions:

http://users.monash.edu/~damian/papers/HTML/Perligata.html

Many years ago, in elementary/primary school I went to a computer camp when I was living in Belgium. We used Logo in French on Macs. I don't remember much, but the keyword for random was 'hazard'.

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.

Interesting, I hadn't thought about"random" much, but hazard kinda makes sense even in English. Like "allow me to hazard a guess."

hasard is in fact the French word for random chance.

Hazard in English comes from that, via the sense of gambling: https://www.etymonline.com/word/hazard

Probably it was the false friend "hasard" which, in French, means: chance, randomness.

It might well have been "hasard". It's been, uh, 20-something years? Thanks for the French lesson!

Couple of times I saw programs written in Russian versions of Basic and some other, forgot which one. Never mind programming even trying to understand it blew my brains out. Russian being my native language I could never imagine writing software in it. I also have the same feelings about the songs as you just described. So all in all completely agree with you.

Seeing anything in computers using my native language feels wrong. I think it’s because I learned how to use computers before I learned English well.

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.

Same here. I still remember feeling pretty dumb the day I realized that "if" and "else" were also English words.

I'm a native English speaker, and so the reason for names like "if", "while", etc. were clear to me when learning. On the other hand, your experience learning programming was similar to mine learning to use a Unix-like OS. Although I do know their etymology as a bit of useless trivia, for the most part "cat", "grep", "vi", "diff", "sed", "dd", "df", "tar", and so on are just arbitrary symbols to me.

> the thought that native-English speakers probably have a rather different experience with programming languages

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.

As a native-English speaker, when I compare e.g. python's "x and not y" to a more formulaic "x && !y", it really doesn't seem to make much of a difference. I'm curious if you were using a syntax highlighter, that may affect your experience.

But it’s easy to forget how concepts you understand so well they feel natural and are burned in your muscle memory are foreign and difficult to others, beginners in particular. A way to measure that is to teach. When you try to explain simple programming concepts, you often realise what millage you have behind you.

On the other hand, python gives us 'x is not y' which is equivalent to 'not(x is y)' and not 'x is (not y)'. Which can surprise even native English speakers

I tend to think of "is not" as an binary operator and my assumptions based on this hold true. I prefer to think of it as entirely separate from "not". I don't know if the compiler rewrites it to not(x is y) behind the scenes.

I can't imagine programming with ESL and having to deal with code where some english speaker thought they were super clever and named various classes and variables after things that are super referential or punny. I see a lot of classes at my current job named after 80s TV shows or inside jokes. Maybe having ESL would make that type of thing easier to deal with actually since it drives me up the wall.

Classes named for inside jokes are an example of horrible programming practices which should never get past code review

Well that would assume such practices were around when that code was created.

Programming as an English speaker in code mainly written by foreigners is strange too. Misspelling words doesn't matter to them. Having several classes using the same name template ("GhostFactory" / "GhoulFactory" / "ZombieFactory") is fine... and it's also fine if one of them happens to be spelled differently ("PumpkinFatcory"). They're just arbitrary letter sequences that you type via autocomplete.

I remember having to look up what foobar meant back when I started learning programming. "What do you mean it doesn't mean anything? It has to mean something, otherwise what does this code do!?"

Oh boy. Phabricator was _terrible_ with this. Native English speakers thought ridiculous button UI names like "Clowncopterize" were so funny. Fricking no.

I think you're completely right, though I see from the comments that others have different experiences. But to me, the "language" of programming can drive me crazy.

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!

One thing that's felt weird to me is Mockito & friends, and some badly-implemented builder APIs. They're trying to read like natural language, but when the order matters and it's unclear what the order is really supposed to be, the natural language metaphor breaks down and you're better off having it made clear what 'parts of speech' each call is and what the required order is.

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.

Native English speaker, very interested because I find my brain caught when I hear background noise in other (human) languages.

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.

https://en.m.wikipedia.org/wiki/Wolfram_Language

"That Japanese Man Yuta" on youtube mentioned on one of his videos that Japanese-y/Chinese-y roman alphabet fonts completely break his brain when he sees them, and he can't see them as English, just horrible nonsense.

Well can confirm. I prefer pure English than romanization pinyin ANY time.

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.

"Seeing a programming language in your native language after working with English ones"

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 КОНЕЦ ЕСЛИ.

Not saying you're wrong about the hardware analogy. But I think it's no different than learning to drive or play a sport. Eventually it just becomes automatic.

Been reading and writing English almost exclusively, every day, for the past ~six years, out of ~twenty years of learning it—still waiting for it to become automatic.

Childhood does things to your brain. And language recognition doesn't work the same way as motor skills.

This is irrelevant to your point, but mad props. Your written English is superb-I would absolutely assume you’re a native speaker.

Reply on news.ycombinator.com