Ask HN: What does it mean to learn a new programming language?

Code is code. With rare exceptions it doesn’t matter.

Over the last several years I've been switching languages a lot and tend google very basic coding syntax, so I often see questions on Stack Overflow asking for the idiomatic way to do a task in a language. I think it's a pretty typical attitude that you could say a programmer hasn't truly "learned a language" without learning its idiomatic usage and performance characteristics but you'd still say you learned a language after using it for a year or so even if you haven't "truly" learned it.

I find talking about languages with other programmers can be challenging, because there's a class of coders who seem to have a belief that all programming languages are similar to mainstream imperative languages and therefore their strong opinion about all of them is valid and it's as if there's no point in learning more. Paul Graham mentions this in his Blub Paradox essay (http://www.paulgraham.com/avg.html): "You can't trust the opinions of the others, because of the Blub paradox: they're satisfied with whatever language they happen to use, because it dictates the way they think about programs.". In discussions with other devs in 30+ years as a professional coder, I've seen that over and over and it's kinda shocking to someone like me who partitions knowledge into the ol' known-knowns, known-unknowns, and unknown-unknowns.

Your question mentions carrying over a coding style from Python to C. True, you can do that and not really learn the new language. But for some languages, the compiler can force you to use a certain kind of programming style.

For example, in a lot of languages (say, Python, Ruby, Typescript) you can use higher order functions (like map, filter, reduce, zip, etc) but you can also write large codebases without ever using them. They're like an optional language feature that you can adopt depending on your preferred coding style. In Swift I noticed that there's no real difference in conciseness when comparing the syntax for map() or forEach against an equivalent loop, so that's not even a compelling reason to switch styles. But in a language that prohibits loops and early returns (e.g. ML-based langs like Ocaml, Elixir) then you're forced use those higher order functions to avoid having to write loops as custom recursive functions. It wasn't until the compiler forced me to code this way that I truly learned it.

Likewise, if your language enforces Option/Optional/Maybe (e.g. Swift, Scala, Rust) then you're forced to write code to deal with nulls. (Typescript is also like this, but you can bypass it by setting the type to `any` or using the `as` operator.) I worked through some chapters in an old tech interview book (Leetcode-style problems) in Swift and compared the functions to their equivalent in C, and was a little surprised at how many lines of code were dedicated to optionals. However, it was just a line or two more than the equivalent in C if it checked for null pointers. (Swift has a lot of nice syntax sugar for dealing with it; I wasn't as pleased with how Rust does it.)

You've probably heard of people talking about "fighting the borrow checker" in Rust. But the borrow checker struck me just like the above language features. You had to give up a style of coding and adopt a new one.

In short, to "learn a new programming language" is the same as "learn a new spoken language"

When you can communicate above the level of a total novice with "native speakers/users" of the target language, you have "learned" it

I can read tons of programming languages (ultimately, it's all manipulating truth tables to get massage data from one form into another)

I can only write a couple (in any kind of proficient manner)

My first exposure to FORTRAN77 was after learning BASIC, Turbo Pascal, and C++ (from a C/FORTRAN programmer)

I brute-force translated from procedural FORTRAN77 into procedural C

It worked: but it was ugly, inefficient, and didn't look especially "C-like", but that wasn't a surprise - idiomatic programming, like idiomatic speaking/writing, can't be fluidly converted into a different language without interpretation on the part of the translator

A real-world example of this happened to me when I went to London England several years ago for a couple weeks on a project. One of the guys I was working with announced he was gonna go downstairs and light a fag. As an American, I found the cavalier nature of this declaration shocking! Until I asked him what he was actually going to do. In England, "fag" is slang for "cigarette". In the US, it's [vulgar] slang for "homosexual".

When you can idiomatically communicate/read/write (even in limited form) in the target language, you have "learned" it

There is no one standard that fits all cases e.g., I've written useful code in Groovy/Java but I wouldn't dream of claiming I know the languages (or want to know), on the other hand I have a lot of experience with Python code but I see there is much to be learned (the more you know, the more there is to learn).

You can learn something useful in a few ours. It is arrogant to claim you know everything even after decades of experience.