6 ms·

Agree with the spirit of this, but it assumes a human is still looking at the code, and human inspection of code is vanishing faster than people are willing to

Agree with the spirit of this, but it assumes a human is still looking at the code, and human inspection of code is vanishing faster than people are willing to admit (especially when coding in a language said human doesn’t know).

Zambyte 1mo ago
I have always found "not knowing" a programming language to be such a fascinating failure mode for professional software engineers. Especially as someone who learned to program with all programming documentation available online. Like, sure, there are some wildly different paradigms that can be difficult to switch between, especially if you don't have any prior exposure to that paradigm. But there are way more programming languages than there are paradigms, so odds are high that using another language will primarily use a paradigm you're familiar with. So the main difficulties are in using a new standard library (where "using a new library" is a skill software engineers exercise every time they pull in a new library as a dependency), and some syntax quirks (of which tend to be extremely minor differences in the scope of languages used for industry). It's hard for me to see "I'm not an X language engineer" as anything other than directly rejecting the task that using X language would enable. Especially now, when we can directly ask "what does this line / block of code do?" and get a detailed breakdown of exactly what's going on, on demand.
- bluefirebrand 1mo ago
  > I have always found "not knowing" a programming language to be such a fascinating failure mode for professional software engineers This is how you wind up with code riddled with vulnerabilities and anti-patterns, with extremely bad performance imo It's so easy to say "I know Java and C# is basically the same" and then wind up using built ins that are deprecated, using libraries that contain vulnerabilities, or whatever other mistakes Maybe that's "good enough" for your usecases, but I've never found that it's a good idea to just assume I can switch languages for anything reasonably complex without some growing pains. Sometimes very big ones

Zambyte 1mo ago

I have always found "not knowing" a programming language to be such a fascinating failure mode for professional software engineers. Especially as someone who learned to program with all programming documentation available online. Like, sure, there are some wildly different paradigms that can be difficult to switch between, especially if you don't have any prior exposure to that paradigm. But there are way more programming languages than there are paradigms, so odds are high that using another language will primarily use a paradigm you're familiar with. So the main difficulties are in using a new standard library (where "using a new library" is a skill software engineers exercise every time they pull in a new library as a dependency), and some syntax quirks (of which tend to be extremely minor differences in the scope of languages used for industry). It's hard for me to see "I'm not an X language engineer" as anything other than directly rejecting the task that using X language would enable. Especially now, when we can directly ask "what does this line / block of code do?" and get a detailed breakdown of exactly what's going on, on demand.

bluefirebrand 1mo ago
> I have always found "not knowing" a programming language to be such a fascinating failure mode for professional software engineers This is how you wind up with code riddled with vulnerabilities and anti-patterns, with extremely bad performance imo It's so easy to say "I know Java and C# is basically the same" and then wind up using built ins that are deprecated, using libraries that contain vulnerabilities, or whatever other mistakes Maybe that's "good enough" for your usecases, but I've never found that it's a good idea to just assume I can switch languages for anything reasonably complex without some growing pains. Sometimes very big ones