Hacker News Reader

Comment by probably_wrong | Hacker News Reader

> it never caught on, even in Francophone countries

I started programming at least 4 years before I started learning English. In my experience, not knowing what "if" means doesn't change anything because I never thought of code as prose. Whether it's called "if", "si", or "wenn", all that changes in my head is "what's the magic word that I have to insert before I can branch my code?".

This, I believe, it's why localized programming languages never catch on: because it solves a problem I don't have while bringing a new problem I do have, namely, not being able to find support for my niche programming language.

Variable names and comments? Sure, those are definitely prose. But I doubt anyone suffered too much when Python chose "elif" instead of "else if" (other than developers trying to remember whether a particular script should use "else if", "elsif", "elif", or "|").

View on HN

Agreed. I started to program in BASIC some 7 years before I started to learn English. I had no idea what PRINT or LET meant and was able to program without any problems.

Hm, even today, I have not idea why "for" is used for loops (?) and I'm using it without any problems.

Native English speaker and I also don't really get what "for" was meant to mean. At this point it's probably just something that everyone has memorised and part of history.

I'm not a native speaker, but "perform this task, for i in {1,2,3}" seems to make sense as a prose. At least it does in French, when translated literally.

The same in Polish.

personally as a native speaker it has alwaus made sense to me in the sense of saying "for these given constraints, loop while they are maintained" for the arithmetic style for loop, and "for each of these elements" for the more iterator based style.

In python it makes sense but when you have `for(let i=0; I<length; I++)` it makes less sense

"for all i smaller than length, starting at 0". It doesn't really map perfectly because in math you usually don't care about the order, so a for loop actually contains more information than the statement it's trying to mimic.

Also native English: For me it's always made sense only with the loop body, as "for these do that"

Or more straightforwardly, in a way that can be applied to other English constructs, "do that for this group"

It's the same "for" in my head in both those versions.

Huh? It's pretty common even in basic college math courses to use language like "for every p in Q". It's not like programming invented this usage.

My high school teacher had a very legit explanation for the meaning of “for” in that context. But I can’t remember it now. Nowadays I write it because it’s expected, not because there’s a hidden deeper meaning.

Hmm, never thought about it either. I'd guess a contraction of "for each value..."

Could it really be anything else? I always assumed that was the obvious intention there. Never crossed my mind that it could mean anything too different.

Originally it was a Anglicization of "für" in German first used in a programming language called Superplan which was then picked up upon by FORTRAN and then it just stuck

Well, that doesn't really solve the mystery. The German "für" doesn't have any closer connection with loops than English "for".

e.g. in Sums or Products, with

$$ Σ_(i=0)^(20) x² $$

you'd actually pronounce that as "summe für i = 0 bis 20 von x²", which is a good argument for where it might be from.

Yes, though isn't that the same when pronouncing math in English? (So it's a good explanation, but doing the detour via German doesn't give us any extra enlightenment?)

Well I don't know how it's pronounced in English, so I didn't know that, good to know though:)

https://en.wikipedia.org/wiki/Heinz_Rutishauser

I don't think it's much more intuitive in German than in English, probably goes back to the "for each" quantor.

The for loop is the most unintuitive variant of the possible looping constructs. The others (while do/do while/endless loop) are much more straightforward. We could easily have ended up with another version.

I always read it as inspired by "for values of" which at least in German is a common phrase heard in mathematical courses.

Fortran has «do» loops, no «for» loops (to my knowledge). do i = 1, N ...

I always translate “for” in my head to: for each item x in...

In python is pretty direct: “for x in a” translates for for every x in the collection a, do this code...

In C it’s a bit more abstract: “for (i=0; i<10; ++i)” for every i in the range starting at i=0, while it’s less than 10, incrementing... Basically the body establishes a set or collection and the for loop executed the loop body “for” every item in the collection.

Modern languages often use foreach or some other slightly more descriptive name.

I would guess it comes from calling the universal quantifier ”for all” in logic

You have high hopes!

When I was 10, the Dutch language manual for the Commodore 64 explained the pronunciation of "input#", but not that of just "input". So I (unfamiliar with foreign languages) thought that "input" was pronounced as we would in Dutch, while "input#" sounded like what I now know is English.

A class mate said his father said they were both pronounced as in English.

We had a fight over this in the playground, and I beat him. So I was right. "input" on the Commodore 64 is pronounced like in Dutch.

My brain is parsing how a Dutch input would sound different in Dutch? "in de put" vs "input" sounds the same, no? What is different?

There is definitely a difference. If you don't hear it, you might be saying one of them incorrectly? Wiktionary has audio files for input (English) and put (Dutch) if you need a comparison. In IPA the difference is ʊ vs ʏ. In terms of describing it to a Dutch person I would say the English u is somewhere between the Dutch u and the Dutch oe sounds.

That's how I pronounced it. English input sounds more like Dutch "inpoet", the manual said input# was pronounced "inpoet-nummer".

(edit: long live the Internet, it's on page 135 of the manual here: https://docplayer.nl/11208014-Gebruikershandleiding-nederlan... . Nostalgia).

In-poot vs in-puht, roughly.

A long time ago I did some VBA work without any real understanding of the underlying language and even though I had no idea that "Sub" or "Dim" was supposed mean "Subroutine" or "Dimension" my brain just approximately mapped it to "function" and "var" without ever needing to spend time trying to decode the "English" meaning.

Oh so that's what Dim meant :D

Yes, it's only like 20 keywords to learn.

I wish people who come up with all these inscrutable icons would realize that.

Why is learning 20 inscrutable icons harder?

You're wording is interesting and has me thinking. Why think of these words individually, with their individual characters, as a burden of the English lexicon, and instead think of the words as an image in their entirety. So thats it's almost programming by picture.

Because they are tiny and can be unreadable at perfectly normal font sizes.

It's hard to reason and talk about something until you name it. With named keywords, you already have a name for it, even if you say it different than the English pronunciation.

Unless the script is so foreign to you (ex. Latin vs Arabic) that the keywords look like inscrutable symbols anyway.

For a perfect example, try learning APL without having any background or reference names for its symbols: http://xahlee.info/comp/unicode_APL_symbols.html

1. cannot look up an icon in a dictionary

2. cannot google an icon

3. icons are not standardized - companies copyright their icons and sue anyone else who uses them

4. icons do not have a sort order

5. cannot type an icon into a text editor /word processor

6. fonts don't support icons

Could a localization be implemented in a header file with #defines to turn the localized keyword to the real one?

Very good point. While non-english programming languages haven't caught on I have experienced German documentation, comments and variable names in a codebase.

One of the more well-known examples, and one that made me double-take when I saw it - from PHP 3 onwards, when a pair of Israelis rewrote the parser, a common and confusing syntax error was "unexpected T_PAAMAYIM_NEKUDOTAYIM". Which is Hebrew for T_DOUBLE_COLON.

In PHP 5.4, they helped the situation somewhat by changing the error message to "unexpected '::' (T_PAAMAYIM_NEKUDOTAYIM)" - I suspect national pride was involved in their refusal to completely remove the internal token name from the error message.

This choice is also good for search optimization.

This rings true, but I imagine the difference is higher if you can't read the Latin script or if your keyboard doesn't have Latin characters.

Reply on news.ycombinator.com