I think if you know in deep at least 1 programming language then you already know how others will (or probably) behave/work. Of course there are exceptions, because older languages have different workflows or elements. But that's the fun part: go test yourself!
Now referring to programming languages I really feel comfortable with and knowing exactly how they work... I'd say 3 and a half!
Full-time web dev; JS lover since 2002; CSS fanatic. #CSSIsAwesome
I try to stay up with new web platform features. Web feature you don't understand? Tell me! I'll write an article!
He/him
I agree with you in general that understanding a single language at a very deep level will let you easily pick up many, many others, but I don't think one is enough to cover everything, because I think there are a few different fundamental threads in programming languages that different enough that being deeply familiar with one will not prepare you for the others.
I'd probably argue that there are three major threads:
imperative languages — Languages in which the main thing you do is write down a list of steps for the computer to follow in order. This is probably the 75% case. This covers everything from low-level C or Go, to Object Oriented languages like Ruby or Java, to more scripty languages like Python, Perl, or JavaScript.
functional languages — Languages in which the main thing you do is define how to solve very small problems independent of the main task of the program, then wire these smaller problems together to solve bigger problems. It is certainly true that many of the imperative languages above have functional aspects to them and can be used in a functional style, especially flexible, interpreted languages like Ruby, Python, and JavaScript. However, in my experience there's a big difference when you step into a purely functional language like Lisp or Haskell, and writing imperative code in a more functional style won't fully prepare you.
declarative languages — Languages in which you don't really give the computer a list of instructions, but instead you describe the problem for the computer to solve, or sometimes the outcome you desire, and let the machine fill in the blanks. This is a rare breed of language and is often found as an ability of languages that otherwise fall under one of the two above categories, though explicitly declaritive languages do exist. My main exposure to this paradigm is through Prolog, a Turing-complete logic-based language in which you feed the system a set of facts and relationships then ask it questions. Constraint programming, in which you hand the system a set of rules or conditions that must be followed in solving a problem then let the system work out a satisfactory solution, would fall under this label as well, and Oz seems to be a popular language choice, though I haven't used it.
Of course, as I alluded to above, many (most?) languages fall at least somewhat into more than one of these categories, and they are probably better thought of as "paradigms" or "approaches" of programming rather than "types of language". What I'm really trying to get at is that I think it's super valuable to pick a language or two from each of these different categories or paradigms and spend some free time digging in deeply and really wrapping your head around each of these very different perspectives.
I took a course during college called "Programming Languages" in which we had three big programming projects: one in Java, one in Racket (a flavor of Lisp), and one in Prolog. This was, in my opinion, one of the most valuable courses I ever took, and probably one of the most valuable coding-related experiences I've ever had, because it forced me to really lean into these three different perspectives and actually use them enough to make something substantial. It showed me how much variety there can be in how we talk to computers.
I highly recommend this as a personal project for anyone who wants to broaden their mind. First, go through a tutorial for some flavor of Lisp (Racket is a nice introductory one, though everyone has their fav) and write something non-trivial, like a Tic-Tac-Toe player or something. Next, go through a tutorial for Prolog and write something else non-trivial, like a simple chatbot based on Markov chains or something. It's a wild ride.
I totally agree with your point, thank you for your response, but only if we speak for those who actually have many directions in their professional profile.
For example in my experience I wouldn't need to know more than 1 language to master the languages that are connected to my area, however, I usually explore many other languages that are not necessary for my work just for fun. If I wouldn't that wouldn't affect my job or my performance. I mean, I know people earning a lot of money only knowing and working in PHP (haha).
So as we always say, it depends on what you're working on, where you'd like to be working or what you have fun developing.
Full-time web dev; JS lover since 2002; CSS fanatic. #CSSIsAwesome
I try to stay up with new web platform features. Web feature you don't understand? Tell me! I'll write an article!
He/him
Oh yeah, absolutely! Sorry, should have been more clear on that point: for practical purposes, if you learn Java to a super deep level, you should be well equipped to pick up Ruby, Python, JavaScript, C#, or any number of similar languages.
My main point was really that learning these other paradigms is good for expanding your problem-solving perspective. Especially functional programming: since dipping my toe into Lisp, the way I think about problems in JavaScript and the other mostly-imperative languages I actually use has changed a lot.
Almost every language!
I think if you know in deep at least 1 programming language then you already know how others will (or probably) behave/work. Of course there are exceptions, because older languages have different workflows or elements. But that's the fun part: go test yourself!
Now referring to programming languages I really feel comfortable with and knowing exactly how they work... I'd say 3 and a half!
I agree with you in general that understanding a single language at a very deep level will let you easily pick up many, many others, but I don't think one is enough to cover everything, because I think there are a few different fundamental threads in programming languages that different enough that being deeply familiar with one will not prepare you for the others.
I'd probably argue that there are three major threads:
imperative languages — Languages in which the main thing you do is write down a list of steps for the computer to follow in order. This is probably the 75% case. This covers everything from low-level C or Go, to Object Oriented languages like Ruby or Java, to more scripty languages like Python, Perl, or JavaScript.
functional languages — Languages in which the main thing you do is define how to solve very small problems independent of the main task of the program, then wire these smaller problems together to solve bigger problems. It is certainly true that many of the imperative languages above have functional aspects to them and can be used in a functional style, especially flexible, interpreted languages like Ruby, Python, and JavaScript. However, in my experience there's a big difference when you step into a purely functional language like Lisp or Haskell, and writing imperative code in a more functional style won't fully prepare you.
declarative languages — Languages in which you don't really give the computer a list of instructions, but instead you describe the problem for the computer to solve, or sometimes the outcome you desire, and let the machine fill in the blanks. This is a rare breed of language and is often found as an ability of languages that otherwise fall under one of the two above categories, though explicitly declaritive languages do exist. My main exposure to this paradigm is through Prolog, a Turing-complete logic-based language in which you feed the system a set of facts and relationships then ask it questions. Constraint programming, in which you hand the system a set of rules or conditions that must be followed in solving a problem then let the system work out a satisfactory solution, would fall under this label as well, and Oz seems to be a popular language choice, though I haven't used it.
Of course, as I alluded to above, many (most?) languages fall at least somewhat into more than one of these categories, and they are probably better thought of as "paradigms" or "approaches" of programming rather than "types of language". What I'm really trying to get at is that I think it's super valuable to pick a language or two from each of these different categories or paradigms and spend some free time digging in deeply and really wrapping your head around each of these very different perspectives.
I took a course during college called "Programming Languages" in which we had three big programming projects: one in Java, one in Racket (a flavor of Lisp), and one in Prolog. This was, in my opinion, one of the most valuable courses I ever took, and probably one of the most valuable coding-related experiences I've ever had, because it forced me to really lean into these three different perspectives and actually use them enough to make something substantial. It showed me how much variety there can be in how we talk to computers.
I highly recommend this as a personal project for anyone who wants to broaden their mind. First, go through a tutorial for some flavor of Lisp (Racket is a nice introductory one, though everyone has their fav) and write something non-trivial, like a Tic-Tac-Toe player or something. Next, go through a tutorial for Prolog and write something else non-trivial, like a simple chatbot based on Markov chains or something. It's a wild ride.
I totally agree with your point, thank you for your response, but only if we speak for those who actually have many directions in their professional profile.
For example in my experience I wouldn't need to know more than 1 language to master the languages that are connected to my area, however, I usually explore many other languages that are not necessary for my work just for fun. If I wouldn't that wouldn't affect my job or my performance. I mean, I know people earning a lot of money only knowing and working in PHP (haha).
So as we always say, it depends on what you're working on, where you'd like to be working or what you have fun developing.
Oh yeah, absolutely! Sorry, should have been more clear on that point: for practical purposes, if you learn Java to a super deep level, you should be well equipped to pick up Ruby, Python, JavaScript, C#, or any number of similar languages.
My main point was really that learning these other paradigms is good for expanding your problem-solving perspective. Especially functional programming: since dipping my toe into Lisp, the way I think about problems in JavaScript and the other mostly-imperative languages I actually use has changed a lot.
Totally agree!
For me, learning JavaScript and C# made Python almost a piece of cake, more than learning it from scratch with a weak knowledge of any other language.
I always encourage everyone to explore even if it's not connected to what they're doing, who knows where we'll be in 5 years!
Especially languages of the same paradigm!