[userbinator]

One who has a true mastery of programming should be able to write any program in any language, or at least see how to do so, because one thinks in terms more abstract than language-specific constructs yet is able to map them to any language.

Relatedly, here's TLS 1.3 in VB6: https://news.ycombinator.com/item?id=35882985

[benj111]

But you still need to know the language specific constructs.

I can't magically speak German because I know a load of abstract language theory.

And this can work the opposite way. If I know small talk, and then read that C++ can do OO code, I could then think about writing X in C++ and OO being the best model. But I then hit problems when the limitations of OO in C++ become apparent.

In my experience, programming in a language is finding what works in that language, not trying to make the language fit what is in your head.

[thesuitonym]

That's true, but the point the GP was getting at is, if you want to make a program that does xyz, you can do that in any complete language provided you have the mathematical reasoning to figure out how to make it happen. Whether you do that in an object-oriented manner because the language you're using makes that easy, or with some other paradigm.

Programming in a language is finding what works in that language, you're right, but programming at all is trying to get what's in your head into the computer.

[benj111]

I suppose it depends how we define 'true mastery'

Yes you have to understand the problem and state the solution, and that is a prerequisite to 'mastery' but I don't think that's everything that's required.

And this is just talking about the algorithm level. Is Ed equivalent to Emacs? They both do the same thing. Is a complicated solution that demonstrates your mastery better than a simple solution?

[utopiah]

What's interesting about it precisely that despite the equivalence (Turing machines and all that) the difficulty to do one thing is a language versus another is what make it prohibitively hard.

If one is "just" translating something that is idiomatic to a language to something that is not in another, it might take 100x for lines for codes in a way that is terribly hard to understand.

[consp]

I've had the unfortunate exercise of copying an API from pure android java to typescript because "they are similar". It goes against best practices and creates all kinds of weirdness resulting in a finished product which is almost the same but far enough away you could just as well have designed a better API in a few hours from scratch (the real complexity is in the backend of the code, not the interface fortunately). But requirements must be met.

[utopiah]

Funnily the conclusion is precisely why the whole idea of "just" giving specs and let <insert here trendiest marketing slang which tries to replace actual experts, developers or not> do the work is risky. If nobody challenges requirements from a manager or client who "just to get it done" you end up with actual work done... that is totally inefficient, potentially dangerous or just irrelevant.

PS: the <> used here could be the next HN thread I opened, https://news.ycombinator.com/item?id=48047826

[suprjami]

Just because you can doesn't mean you should.