> I don't know if I'll ever be able to master any language anymore

Even with just a handful of languages in my toolbox, I feel this way too. A mixture of unease and anxiety.

In addition to syntactic variations, I find that the notion of writing idiomatic code in a given language amounts to more thinking overhead which eats into productivity. I'd need to be programming in the same language over a long period of time for idiomatic code to come more naturally. Can't seem to just instantly switch like some talented folk out there.

I run into the idiomatic, or even "regional dialect", issue all the time. I've had many coworkers look at me like I'm stupid when I ask them how they like to implement a certain, basic algorithm. It's not that I don't know how to get it done, I'm just wondering how they like to structure their code, as I find it more important to match style than impose my own, generally speaking.

If I don't have to match styles, and can just write the code as I feel like it, I can work so much faster.

I don't care so much about writing idiomatic code anymore. For example I tend to write python like javascript. Mostly only use lists and dicts (JSON basically), while ditching the whole OOP/class concepts for the most part. What I prefer is more or less a language-independent style, which makes it easy to port code at least between languages with similar paradigms.

> For example I tend to write python like javascript. Mostly only use lists and dicts (JSON basically), while ditching the whole OOP/class concepts for the most part.

that is exactly how you are supposed to write idiomatic python

Surely that depends on what you are writing.

Try clustering similar languages into groups centered around shared features, then try to come up with high-level statements which hold true for all the languages in a group. Then try to derive the individual differences within the group from these statements. Use mnemonic techniques as required and prepare cheatsheets if needed.

One thing to realize, though, is that syntax - outside of a few special cases - is the most trivial part of any language. It's 100% acceptable to forget the syntax of a `for` loop in one language, as long as you still know that, in that language, the `for` loop is actually a for-each construct working on sequences of some types and additionally it's an expression which returns a sequence of results, making it equivalent to `map` higher-order function. Now, I described the `for` loop of (for example) Elixir, CoffeeScript, Racket, Common Lisp (`loop` with `collect`) and F# and Scala (with `yield`). As long as I know that a language I'm using right now belongs to this group, I can plan my implementation around the semantics outlined above. Then, when it comes to writing the code, I can just look up the syntax, or more commonly - just make my editor autocomplete and snippet-insert the relevant bits for me.

So, my advice would be to first learn and understand as many programming language features as possible, focus on their semantics, and then group the languages you know around the features. The syntax is really a trivial matter, and "mastering it" (ie. having the whole grammar constantly in your head) is not actually necessary in my experience.

I agree, I don't really sweat it, and the seasoned engineers I respect totally get it. But mastery can be fun, and while I'm developing a kind of "meta-mastery" (I touched my first Go production codebase two weeks ago, and was able to fix a bug in it without really cracking the books except for Interface{}), I miss plain-old mastery that other fields can achieve.

I'm this way with foreign languages: Spanish and french. I know french very well, and learning/speaking Spanish is significantly harder because I'm always using french words by mistake. sure it'll get better with practice, but interlingual dyslexia is real.

Interesting, I feel like I have the opposite issue. Coming from Portuguese, learning Spanish was a breeze and I can usually surprise French speaking people with “hard” words in my basic French sentences — just because I reached out to a Portuguese word and “frenchyfied” it.

Going from native Portuguese, then French, and only then Spanish (yep, I've gone to a crazy school), I got much of the problem the GP was talking about. I don't think I've ever spoken so much French as the time when I was leaning Spanish.

There's something with those two languages in that they interfere badly.

Spanish and Portuguese seem to be unusually close. Studying one helps me with the other.

Portuguese and Japanese on the other hand...

The OP wasn’t talking about Japanese. They were talking about European languages- many of which share a common heritage

Not all of them do, but the ones mentioned were all very similar Romance languages.

I’m aware not al of them do. This is why I said “many” and not “all”.

There are roughly 3 main groups of European languages: Italic (or Romance as you described it) for Western Europe, Germanic which is predominantly Central Europe, Scandinavian countries and the UK; and Balto-Slavic for Eastern Europe. Generally speaking of course.

However there is still a fair amount of cross pollination even with the Germanic and Italic languages, not to mention shared characteristics (not least of all a shared alphabet) that doesn’t exist with Japonic languages such as, well, Japanese.

I think this dyslexia happens more with non native languages.

Like when I was trying to speak german, after just some time in France. My native language is Portuguese

German and Portuguese differ significantly more than French and Portuguese, so that might be affecting your experience…

I’m not too familiar with the Southern European languages, but I am quite familiar with the Northern European languages. That is where I find the opposite of your difficulty happen, where all those languages look like a different flavour of German to me, so they were very easy to pick up, because I could just read Swedish slowly without ever looking at a textbook or dictionary, and over time I found myself quickly able to write it.

Differences between people, or differences between cultures perhaps. Having grown up in the Netherlands I did already come across Frisian and Limburgs, which are also slightly different but if you keep reading or listening you just pick it up. So I don’t know, keep practicing I’m sure you’ll get Spanish!

It's true that learning one Latin language (like French) makes it easier to understand another latin language (like Spanish), and the same is true of learning similar programming languages. But the point isn't that it's easy to approximate what is being said, it's that when you are speaking, all your prior knowledge confuses you.

For example, if you start speaking (not listening to) Frisian and Limburgs, you might find yourself throwing a few Swedish or German words in the mix.

I have walked up to a shop keeper and asked [french(Can I have a loaf of)][Chinese(bread)]

I'm white so I'm sure this was even more confusing for him

When I started learning Mandarin (my fourth language) I became totally unable to speak French (my third language) as the Mandarin words would pop up first in my mind. I think by now they've been sufficiently separated in my mind but I haven't had any use for my French so it as atrophied anyway. I'm now learning Cantonese which is similar to Mandarin and I'm only occasionally mixing it up with Mandarin. It seems to me the distance between languages isn't so important, you can mix up any two languages or not. It probably depends more on how much your brain has to rewire itself to acconmmodate the new language?

Perhaps try learning sufficiently different languages? For me it's hard to make cross-language mistakes except within the {} groups:

C, {all kinds of assembly}, {C++, Java, C#}, {Python, Ruby}, {Haskell, OCaml}, Prolog, {VHDL, Verilog}

One really striking thing is going between {Go, C++, C#, Java} and getting the sources of documentation confused between each one. Not even the languages themselves, but the ecosystems, can be really confusing.

{CL, Scheme, Clojure}, {all kinds of shell scripting, maybe Perl}

Know all those except Prolog, plus a couple of Lisps - it just makes it worse ;) I agree that the more disparate the languages, the easier it is. And if I use one language consistently for a year or so, I get pretty keyed into it and only rarely try to figure out why it isn't working because I randomly typed "if not X {}" in Go ;)

I thought I was the only one. Also class and method names : is it array.length(), array.len(), array.Length, array.size(), len(array), Len(array).

Thank goodness for Intellisense style autocomplete, and hover documentation.

This is one reason I love PowerShell's design that everything is case insensitive.

For casual scripting, it's so nice to not have to care if it's length or Length. At least memory can help me if it's len/length but length/Length is no distinction at all.

(Case sensitivity is one of my pet hates, for anti-human UX).

Interesting. I've come to basically the opposite conclusion and find case insensitivity to be counter intuitive. "Foo" and "foo" are not the same set of ascii characters; why should they map to the same thing?

"Dog" and "dog" are the same word, they are read the same, and pronounced the same. "D" and "d" are the same letter of the English alphabet, an alphabet with 26 characters not 52 characters. Why should they map to different things just because of some implementation limit behind the scenes in a computer?

Why should the ASCII table be the defining characteristic, over and above the way humans have used English for decades? ASCII "Foo" and UTF-16 "Foo" are not the same set of bytes, should they map to different things? "Foo" and "Foo" are not displayed with the same set of pixels, should they map to different things? "Foo" and "Foo" are not stored in the same memory address, nor were they typed in the same number of milliseconds over the same USB packets, why should the ASCII table internal detail matter and those details not matter?

As a fun counterpoint about case sensitivity in English, consider:

- The man spoke to God, saying he had made poor decisions.

- The man spoke to God, saying He had made poor decisions.

IDEs are useful for this. Let them keep track of minutia like syntax rules and names of common but differently-named methods. I find also find that it only takes me about a day of picking a language back up to remember which way they've gone on most of these things.

This kind of gets at what I think is the big advantage of learning a bunch of languages: it gives you instincts for which things are minutia and which aren't. The things you listed that every language has but does differently, which are annoying to figure out and remember, that's the minutia.

I only know 5 or 6 but have the same problem. Dropping in semicolons into python. Forgetting brackets in JavaScript.

Too similar to keep them apart and too different to treat them the same. I don't see a solution apart from regular repetition, do you?

At the end of the day it's more about applying the right patterns. A language is just a hammer. But you won't make good furniture without design skills. So it does not matter that you need to Google up things and forget things.

> Mmmmaybe C

Lol - I remember years ago bouncing through javascript, python, lisp, prolog and others, all using ";" differently; then coming back around to C, and despite once knowing the spec by heart and having written C parsers, writing some one-line test programs... because I just could not believe that semicolon was a statement terminator - it looked so "this just isn't right". :)

> [syntax]

But when swapping languages, I had more trouble with cognitive interference on higher-level constructs. Syntax can go in cheat sheets[1], and idioms gathered in example files. Badly organized and incomplete documentation (once common before the programming community exploded in size) can be overlaid with tables of contents and notes. Because remembering how to find things in each languages' documentation was for me a major pain. But for designing say large apis, you have to remember things like some type-system path does look pretty... but only until you hit some language-misfeature monster that lives on it. And also not shy from some approach because of a misremembered or misattributed gotcha from another language. Though maybe that's easier now with so much discussion of best practices, and so much code available to read.

> cheeseburger and lasagna [...] they all get your belly full.

Or alternately, that they're all shambling toxic wretchedness, but you choose the one which seems likely to poison the customer the least, cooking it as well as circumstances permit. Cockroach popcorn and fried millipedes can be tasty. And even with swill milk... gypsum plaster is non-toxic... it's the other adulterants, little nutrition, and absence of sanitation that burn you. I do love programming, but I so look forward to less crippling languages.

[1] http://rigaux.org/language-study/syntax-across-languages.htm...

The best technique I've found for staying sane when working in a large number of languages is to configure your editor to highlight errors based on language. If you use perens where you're not supposed to, your editor should tell you right away. No need to go find an example.

This becomes less useful when it's "which library do I use" or "what is the idiomatic way to do this in X language".

I know a bunch of languages too, or at least I claim that I know, because I've used it for some time in the past. And I do not remember the most of them, in the sense that I cannot right now start writing in those languages. But I can start to write C or rust without need to take a look into a tutorial or something like, because I use them routinely.

After lisp I've lost the idea of syntax as of an inherent part of language. You know, all that stuff, that lisp's s-expressions and their memory representation are mapped into each other seamlessly lead to a conclusion that any of them is not important, there is an abstract idea of a lisp object while conrete representations of lisp objects are just some practical ways to deal with them in different situations.

So the official language syntax is a one of the practical ways to represent ideas using that language. The most of languages do not bother to have a second representation, but it doesn't matter. Syntax doesn't matter. You can learn it on a whim in a half an hour of leizure reading.

I wrote a working compiler (learning type exercise level) effectively in pseudo-code resembling Java once because I didn't know the syntax very well, then commented it all out and translated it to Java line by line. Surprisingly, it had no bugs that I ever knew of. It definitely freed me up to think purely about the logic.

You might just throw down whatever and let the next compile/interpretation cycle let you know if you didn't get the syntax right.

Yes, esp some languages are deceptively similar: if you know C, then PERL, Javascript, and PHP looks very similar, but it is hard to remember the differences.