Someone who worked on a non-English environment years ago here: sometimes you do use the local language in some contexts, but, more often than not, you end up using English for the majority of stuff since it's a bit off-putting to mix another language with the English of programming languages and APIs.
Our US company sent me to France to help out with an implementation. The guy I worked with spoke very little English and my French is terrible. Both of us had done Latin, however - so the comments were hilarious as we used that as our common link. One of those projects I'd expect to show on the daily WTF at some point.
I did try my hand at a translation tool, as it was all i18n up proper. Watched one guy blow coffee through his nose when I demo'ed - and the 'BACK' navigation was the French word for a persons back or something like that.
Isn't it true that schoolboys in many countries would learn Latin 100+ years ago? I suppose it would've been used sometimes in international communication?
If you're from Europe knowing Latin definitely gives you a deeper appreciation of a bunch of stuff.
It's a useful way of formalising verb conjugation and tenses which is common across the major European languages. Something they all take for granted but I watch my poor mother's mind melt when she tried learning German as a Chinese speaker. Especially as a lot of these forms are looser and more forgiving in English.
A lot of vocabulary has its origins in Latin and biology and medicine still like to borrow from it.
It's niche but only today I was playing some Mozart on the piano and saw "M. S." where I was meant to cross the hands and I considered for a sec and guessed it must be mano sinistra (forgive the declension) even though I've never learned Italian thanks to Latin.
100+ years is still pretty recent. The immediate predecessor to English as a world language was French. Matter of fact, my country has only dropped French translations from its passport with the most recent design update a decade ago or so.
Latin would have been used pre-Renaissance. Our grandparents might have still had to learn it as a part of an educated person's toolkit, but it was long not intended for communication anymore back then.
> The immediate predecessor to English as a world language was French
From what I remember, there was a divide between Catholicism and Protestantism, where some of the smaller countries that followed Protestantism used German as a common language due to its origins. I think knowledge of German in Norway was something that was expected of students attending the universities until the mid 1900s (due to geopolitical changes)
It's still mandatory (1-2 years) in non-vocational high schools in Croatia, for the stupidest of reasons ("culture" and "you might need it in law or medical higher education").
It was mandatory at the schools I attended from 7 to 14, which was in the 90s, although this was at what British people call "prep/public schools", a group of a few hundred fancy fee-paying schools. Most people dropped it at 14 (GCSEs), and almost everyone dropped it by 16 (A Levels)
Lol, I learned it in the 80s - 90s. If you chose to learn Latin & Greek in high school here in Belgium then you're seen as being a top student. It's still a big thing.
I've been working on a project for the former Polish state telco and the codebase was mostly Java EE as written in the mid-00's. Since you cannot really be productive in Java without an IDE, standard English conventions for naming have been pushed onto the devs from early on - a getter must start with `get` or `is` if the return type is boolean, class names have to contain standardized postfixes corresponding to the design pattern used, such as `AbstractFactoryBean` etc. But since few people spoke English back then, they ended up with awful hybrid names such as `getCennikSluchawkiKeySet` or `OfertaManagerPrzylaczeProxy`.
A lot of software design from the English world centers around "design patterns." And these "design patterns" have advanced nomenclature and often make things more convoluted then necessary. The whole concept of these "patterns" are actually an arbitrary style that got invented in the English speaking world. In non-english countries people program in ways that are more straightforward.
First, we create an AbstractFactory to generate objects that conform to our standardized output structure, ensuring extensibility in case "Hello, World!" ever needs additional variants. The Singleton manages our PrintManager, enforcing a single, controlled point of access to the output stream while Double-Checked Locking ensures thread-safe initialization. Dependency Injection provides our PrintHandler with a flexible logging system, allowing it to notify an Observer whenever "Hello, World!" is printed. The Mediator coordinates between components to ensure the PrintHandler doesn’t have direct dependencies on the OutputStrategy.
To maintain optimal efficiency, a Flyweight is used for the "Hello, World!" string, preventing redundant memory allocation. The Proxy regulates access to the print function, ensuring only authorized modules can invoke it. The Composite structure organizes potential multiple output streams, making it easy to expand the system beyond just console printing. A Factory of Factories, or MetaFactory, oversees creation of our AbstractFactories to maintain consistency and scalability.
Before execution, Encapsulation hides implementation details while Cohesion ensures the PrintHandler remains single-responsibility. Loose Coupling ensures that changing one component won’t break the system. Interfaces dictate behavior, and Abstract Classes provide reusable codebases. Dynamic Dispatch selects the appropriate OutputStrategy at runtime.
To enhance modularity, a Decorator wraps the PrintHandler for additional formatting options, an Adapter ensures compatibility with different logging frameworks, a Memento preserves state in case a rollback is needed, and a Facade simplifies access for higher-level modules. The Chain of Responsibility delegates different logging levels, while the Command Pattern encapsulates the printing request for possible queuing or delayed execution.
By adhering to Open-Closed, we can extend our print functionality without modifying core logic. Liskov Substitution ensures all output strategies remain interchangeable. Interface Segregation ensures smaller, focused contracts. Dependency Inversion prioritizes abstractions over concrete implementations.
Finally, SOLID principles uphold scalability, reusability, and maintainability. UML diagrams map out relationships, Sequence flows depict interactions, and Design Contracts enforce constraints, ensuring the system remains adaptable.
After all this, we simply call PrintManager.getInstance().print("Hello, World!"); and marvel at our masterpiece.
This is very much a Java phenomenon. These things do have value .. when correctly applied. But sometimes it's like seeing someone make a gadget with fifty different types of bolts rather than one or two simply because they want to use all the bits of their socket set.
No it’s from a book called design patterns. It forever influenced a huge number of American programmers to think about programming in a very specific way following very specific patterns.
I’m working for a company that’s doing things in typescript using IOC and dependency injection everywhere. It pervades the minds of Americans such that they walk and talk like a parrot parroting that book.
What Americans don’t realize is that those patterns are arbitrarily made up. It’s as arbitrary and localized as the Japanese having to bow for politeness. There’s nothing intrinsically hugely beneficial for following this style. In fact, modern languages push against it. Languages like golang and rust are examples. Even JavaScript was an example although recent es6 syntax makes patterns more easier now
I think you will find most Java programmers were using these patterns before they came across the book. The language naturally leads you in that direction. The book just put a name on them.
This is a bit environment dependent is my impression. Like France and Japan both have enough people shitty at English to generate either translations or home grown programming learning material to fight against this barrier. But my impression is that, like, a German programmer isn't getting far in life without being comfy reading stuff in English
Many non-English-language countries end up with most people who've been through higher education knowing at least some English, not only so they can handle sources but also so they can talk internationally to any other country as well as consume American media.
It's also a status symbol.
The smaller the language pool is the stronger this effect is. Japan is large enough that it's less guaranteed. Places like India and Indonesia that have a lot of internal languages end up using English as a lingua franca (+) as well.
Not literally required, because languages typically support UTF-8 source files, but it would be difficult to use most popular software libraries without being able to at least read English.
Actually, most "most popular software libraries" have either translated docs, or guides in a non-English language.
Furthermore, modern browsers can translate text on the fly. Some (like Yandex.Browser [1] not_an_ad) can even translate videos on the fly.
Sure, most of them have docs in some non-English languages, but rarely all of them. And things like StackOverflow answers, bug reports and discussions, tutorials, and blog posts tend to be mostly in English. Autotranslate works to some extent but can be misleading or confusing when dealing with specialized terms that aren't well represented in its corpus. My Japanese coworkers certainly need to be able to comprehend written English.
Sure docs for massively popular libraries are translated but think about using autocomplete, reading the actual library code, or even just reading other code in your organization. I have to imagine it would be difficult without any English proficiency.
A lot would probably be loan words anyway, and they're words many English speakers would also need to learn. Array, socket, database, loop, float, function, etc.
If the stack overflow examples are in English, you might as well use it. That's also why JavaScript is maybe a better choice than Typescript even if Typescript is better.
Probably at least some, because most tools’ documentation are not going to be in your language – at least that’s how it is here in Japan. That said plenty of Japanese engineers who have very low English skill.
It’s harder to learn for sure. Majority of the resources are in English and it’s harder to internalise the keywords. But it’s definitely possible to program without knowing English.
You don't need to know that the keywords are actually english words. So to start the first program on a floppy on a C64 you would type
load "*",8,1
and back then I didn't understand what load means any more than I understood what ,8,1 means, I just knew that if I press this sequence of letters it will start summer olympics.
> But like, you can’t program Java without English right?
Sure you can, if you know Java, which is its own language distinct from any natural language.
Conversely, you can't program in Java if you know English, but not Java.
> A for-loop has to be written in English??
No, it has to be written in Java. It's true that Java keywords are mostly themselves borrowed from English (often by way of C++ or other computer languages rather than directly) with a use in Java that has some connection to the meaning in English, so its probably easier to learn Java if you already know English (even before considering that there is probably more and better documentation in English than other languages), but that's not the same as English being a requirement for programming Java.
A for loop and other syntax keywords are barely the only English people have to understand in programming. One could say that these could just as well be arbitrary symbols, and programmers would just memorize them. But think of all the concepts named in English such as exception, factory, facade, adapter, interface, iterator, needle, haystack, constructor, queue... you name it. Not to mention documentation. So yeah, some English is mandatory, even if we're not able to communicate properly. In some projects though it's not uncommon to use local language for the domain while still keeping technical concepts in English, like getAnniversaire() or PersonneTable.
It's like names of Pokemons. Every kids know that Bulbasaur is grass-poison typed and evolves into Ivysaur at Level 16. You have to memorize them all to be a good player and that's a whole load of nonsense! But that's not relatively huge undertaking, and nothing remotely like the full language.
Yes, for Java in particular you need to know the various English keywords. At least I don’t think anyone has written a non-English Java variant that compiles to the JVM just as Java would.
If you know another language than English, try Microsoft Excel in that other language. And even if not, just for fun install a non-English version of Excel.
They translated the keywords. Even if you've programmed in proper programming languages for years without knowing English, all the regular keywords to get stuff done you will know in English. And you won't be able to do a single thing in Excel coz none of the keywords work.
One good thing I guess: You can honestly say when they ask you "hey, you know how to program computers, right? Can you help me with this problem in Excel" and you can honestly say: Nope, can't, no idea how that works. See it doesn't even have a simple IF.
Yes, but you don't need to know what "for" and "while" mean in your language, you just need to know their behavior. The same way Arnold Schwarzenegger was acting without knowing much English - everything was phonetically spelled for him in early roles.
I learned Pascal before I learned many English words like "if". You don't need to know what "if" or "for" mean to remember those keywords or to know what they do.
