This one might be a bit controversial, but has rung true in my general experience. Probably a lot of exceptions to these rules, but here goes:
You don't really know a programming language until you understand a fair amount of the standard library and how packages/modules/dependencies work. Syntax is pretty easy, and any mainstream language will work just fine for solving basic leet-code style problems. But when you really spend a lot of time working with a language, you're going to spend more time learning about common libraries and how to manage dependencies. If you're working with a language like C++ or Java, this could also include build systems and how to use them.
Another precursor to being able to say that you know a language is that you should also be familiar with best practices (ie. how to name modules, how to write documentation, etc.) and common pitfalls (undefined behavior, etc.). This is one of the hardest parts about learning a new language in my opinion, because the language may not necessarily enforce these things, but doing them the wrong way can make your life very difficult.
That's what I hate about javascript, it doesn't warm you about undefined behavior, it just throws.
I used to not really care about that, but after learning C and Rust, damm, I wish there where result types everywhere
Some small nits to fix:
C has it's own undefined behavior.
JS has confusing behavior, not undefined behavior. Its specs are well defined and backwards compatible to a fault, making some things unintuitive and harder to learn if you don't learn the history of the language.
Problems with both should be avoided by learning and using standard practices. (Don't pretend C is object oriented, always use === instead of == in js, etc...)
In complete agreement:
Result types are awesome, all future languages should be designed around them.
thank you very much.
By undefined I meant the usage of undefined in the language, however you phrased it way better :)
Counterpoint: knowing a programming language doesn't matter if you can solve problems. A competent programmer can pick up a new language and be productive within a few months. That is, a new language within the same paradigm - going from a imperative language to a functional language can be a drastic shift, but going from one imperative language to another is easy. If you can't do that as a intermediate to senior developer, you're not a competent programmer IMO.
The real skills of a good programmer are things like problem solving, debugging, understanding how to write readable and maintainable code, etc. Having deep knowledge of a specific programming language or languages is helpful and enables you to work faster, but if you're only a skilled developer in the languages you know - if you aren't capable of pivoting those skills to another language - you aren't a skilled developer IMO.
Agreed overall, you will still be competent switching from one language to another, but intricacies and nuance matter a lot here. You may have enough knowledge to solve problems, but will you have enough knowledge to avoid creating new ones too? Like performance issues, or memory leaks, or other unwanted behavior? C++ is a great example here: someone that's smart but inexperienced might just be dangerous enough to start writing classes with dumb pointers without overriding the copy constructors, and this is just a recipe for disaster.
I think it would take more than a few months to develop the kinds of experience that you need to be aware of these issues and avoid them. And while C++ is a very easy example to point out here, pretty much all languages have their share of footguns to be aware of, and it just takes time to learn them. A "deep knowledge" of a language is not just about being faster and more productive; it's also about not creating more issues than the ones your solving.
I think the degree of footgun danger depends a lot on the language and the application. I agree that C and C++ are dangerous until you really know what you're doing, though IMO most of the danger comes down to memory management and that's a portable skill, once you've learned it. That being said, I don't have a lot of experience with C++. C was my first language so I'm used to plain old normal boring pointers (are those "dumb pointers"?) and I've never understood why C++ needs 9 billion types of pointers.
Go has one particular footgun - loop range variables. Other than that, IMO high-level, garbage collected languages don't have major footguns like that. My first job was writing a bespoke inventory system for a manufacturing company, and I wrote it in a language I'd never used before - C#. In five years the only major issue that had was due to my inexperience with SQL and had nothing to do with C#. And though I haven't written nearly as much code, I'd say the same about Java, Ruby, Python, and JavaScript.
This one might be a bit controversial, but has rung true in my general experience. Probably a lot of exceptions to these rules, but here goes:
You don't really know a programming language until you understand a fair amount of the standard library and how packages/modules/dependencies work. Syntax is pretty easy, and any mainstream language will work just fine for solving basic leet-code style problems. But when you really spend a lot of time working with a language, you're going to spend more time learning about common libraries and how to manage dependencies. If you're working with a language like C++ or Java, this could also include build systems and how to use them.
Another precursor to being able to say that you know a language is that you should also be familiar with best practices (ie. how to name modules, how to write documentation, etc.) and common pitfalls (undefined behavior, etc.). This is one of the hardest parts about learning a new language in my opinion, because the language may not necessarily enforce these things, but doing them the wrong way can make your life very difficult.
That's what I hate about javascript, it doesn't warm you about undefined behavior, it just throws.
I used to not really care about that, but after learning C and Rust, damm, I wish there where result types everywhere
Some small nits to fix:
C has it's own undefined behavior.
JS has confusing behavior, not undefined behavior. Its specs are well defined and backwards compatible to a fault, making some things unintuitive and harder to learn if you don't learn the history of the language.
Problems with both should be avoided by learning and using standard practices. (Don't pretend C is object oriented, always use
===instead of==in js, etc...)In complete agreement:
thank you very much.
By undefined I meant the usage of undefined in the language, however you phrased it way better :)
Counterpoint: knowing a programming language doesn't matter if you can solve problems. A competent programmer can pick up a new language and be productive within a few months. That is, a new language within the same paradigm - going from a imperative language to a functional language can be a drastic shift, but going from one imperative language to another is easy. If you can't do that as a intermediate to senior developer, you're not a competent programmer IMO.
The real skills of a good programmer are things like problem solving, debugging, understanding how to write readable and maintainable code, etc. Having deep knowledge of a specific programming language or languages is helpful and enables you to work faster, but if you're only a skilled developer in the languages you know - if you aren't capable of pivoting those skills to another language - you aren't a skilled developer IMO.
Agreed overall, you will still be competent switching from one language to another, but intricacies and nuance matter a lot here. You may have enough knowledge to solve problems, but will you have enough knowledge to avoid creating new ones too? Like performance issues, or memory leaks, or other unwanted behavior? C++ is a great example here: someone that's smart but inexperienced might just be dangerous enough to start writing classes with dumb pointers without overriding the copy constructors, and this is just a recipe for disaster.
I think it would take more than a few months to develop the kinds of experience that you need to be aware of these issues and avoid them. And while C++ is a very easy example to point out here, pretty much all languages have their share of footguns to be aware of, and it just takes time to learn them. A "deep knowledge" of a language is not just about being faster and more productive; it's also about not creating more issues than the ones your solving.
I think the degree of footgun danger depends a lot on the language and the application. I agree that C and C++ are dangerous until you really know what you're doing, though IMO most of the danger comes down to memory management and that's a portable skill, once you've learned it. That being said, I don't have a lot of experience with C++. C was my first language so I'm used to plain old normal boring pointers (are those "dumb pointers"?) and I've never understood why C++ needs 9 billion types of pointers.
Go has one particular footgun - loop range variables. Other than that, IMO high-level, garbage collected languages don't have major footguns like that. My first job was writing a bespoke inventory system for a manufacturing company, and I wrote it in a language I'd never used before - C#. In five years the only major issue that had was due to my inexperience with SQL and had nothing to do with C#. And though I haven't written nearly as much code, I'd say the same about Java, Ruby, Python, and JavaScript.