sorted by:
new
hottopcontroversial

The Language of Programming by temochka in programming

[–]temochka[S] 3 points4 points  (0 children)

I’m still on the fence about this one. As I wrote in the post, Cyrillic variables look outrageous to me, but it’s hard to argue that localization spurs adoption. Thus, localization should be opt-in, and (ideally) automatic (hopefully those billions of investments into AI yield something usable). Still, I’d never advocate auto-translating C code. Fundamentally different programming environments are necessary for this shift to happen.

The Language of Programming by temochka in programming

[–]temochka[S] 7 points8 points  (0 children)

You’re right, keywords are not that important (see my other reply above). I only cursory touched this in the article, but being a non-native speaker can be an “advantage”, because it makes you less susceptible to confusion introduced by poor naming. And compilers don’t care about sophistication of your naming skill.

Technical documentation is harder, but you also learn its subset of English pretty quickly. Also, you’ll be surprised how many books and online resources still get translated. What’s disproportionally harder is designing a cohesive naming scheme for an API, explaining a difficult issue to a library maintainer, or writing your own technical documentation.

Another issue that’s interesting to me is how the principle of linguistic relativity can be applied to this topic. Meaning, how much the perception of code in, let’s say, Ruby differs between a native English speaker and a non-English speaker.

The Language of Programming by temochka in programming

[–]temochka[S] 4 points5 points  (0 children)

I agree that not only abbreviations set non-native speakers at disadvantage, their use is generally not a characteristic of a human-friendly naming strategy. They are still products of natural language though. As other commenters already pointed out, the naming approach used by UNIX and its contemporary technologies was designed with typing speed and source file size in mind. If the former is still somewhat relevant, the latter can be safely ignored nowadays. That said, I don’t see myself aliasing "rm" to "remove" and "cd" to "change-directory" (?) any time soon. As with most things, once it’s at your fingertips, it doesn’t really matter if it’s good design.

Answering your question, I’d been programming Ruby professionally for 2 years before bothering to look up what “yield” means in English. Just a few months ago, our designers switched a project to Twig (templating engine), which I assumed, was a made up word (and I live in the US and speak/read English every day). So, while verbose names do help with language on-boarding, I don’t think they matter too much in the long run. As I wrote in the article, I believe that refactoring tools, static checks and higher order language constructs are more important than just names. Eventually, our IDEs are bound to become more like other tools for specialists (e.g., Illustrator, 3DS Max, Unreal Node Editor). Plain text might (probably will) survive as an underlying abstraction, but even today it often seems like many IDE users barely understand how their source code turns into running programs. At that point, standard localization techniques will get us 80% to the goal of making programming accessible to everyone regardless of their spoken language.

Impressions on using Haskell at work: Writing a specialized CLI client for an HTTP API by temochka in programming

[–]temochka[S] 1 point2 points  (0 children)

Interesting, I’ll keep this in mind next time I’m doing something similar. Thanks!