My honest opinion is that it doesn't matter.  Just write code. Pick a language and write some code.  However, you want to develop the skill of writing clean code as you work towards learning how to be efficient in whatever language you are writing in. This is what will set you apart from casual and less skilled developers.

More importantly, one's focus should be on architectures. Whatever language you are learning to code is pretty much useless if you can't grasp how to use effectively apply it within the architectures or frameworks it's used in.  

A language is simply a tool, something that is pretty much second nature like a carpenter grabbing a hammer. That said, the carpenter is not hired because he can hammer. He is hired because he can read blueprints, and diagrams and the end result via that hammer is what everyone expected.

If you get a job in the professional realm you'll be asked at one point to develop a solution from scratch. It happens. You'll be expected to know how to develop that solution within the framework or current architecture, i.e., game engine,  proprietary subsystems, .net, angular, <insert whatever is the main platform here>.  Your ability to come up with an implementation that passes the smell test from a lead architect is just the first phase. The language bit only comes into play during implementation when you are attempting to write clean, fast, readable, and efficient code. See what I did there?   A well-rounded programmer is just more than a coder..... he/she is an Engineer.

Books like this should be on your reading list:
Code Complete 2
The Clean Coder
Clean Code
The pragmatic programmer
etc, etc....
 

You rather should understand the design decisions behind all these languages and paradigms.

A nice book for starting: FRIEDMAN P., MITCHELL W.: Essentials of Programming Languages.

On 9/19/2017 at 8:16 PM, Alpha_ProgDes said:

I'm not counting languages like Julia, R, Perl, or Erlang, because they are languages, AFAIK, that seem to solve a very specific problem.

Erlang is very similar to Scheme, Racket and Haskell. The message-passing parallelism between nodes is a nice feature, but not necessarily used in all Erlang programs.

From my own experience, I would group the general purpose languages I know in the following coarse groups (independent of programming paradigms, but rather gut feeling):

• C, C++, C#, CUDA, Java, J#, Python 2 & 3, JavaScript, TypeScript, CoffeeScript
• Haskell, Scheme, Racket, Erlang, Elm
• Prolog, IDP

After elimination, the following languages remain that I find useful to have in your toolkit (I rarely create web apps...):

• C++, C#, CUDA, Python 2 & 3
• Haskell, Erlang
• Prolog

3 hours ago, ericrrichards22 said:

I chuckle a little bit whenever I see that the next big thing in the front-end world is something that existed 10, 15, 20, 30 years ago...  We keep reinventing Java applets, Flash, UI paradigms that are old enough to order a beer, and even makefiles.  But in Javascript!

This quote is from another thread.

However, this very idea (actually long overdue "discovery") is what informed my list in the OP. Smalltalk, IIUC, pretty much created OOP, MVC, VM, and GUIs. Again, I don't believe that any OOP language has done anything (new) in the last 37 years that Smalltalk hasn't already done.

I remember that my professor teaching the "design of software systems" (code metrics, design patterns, etc.) considered Smalltalk, one of the most beautiful programming languages ever created (though, we have never seen Smalltalk code  ).

3 hours ago, matt77hias said:

I remember that my professor teaching the "design of software systems" (code metrics, design patterns, etc.) considered Smalltalk, one of the most beautiful programming languages ever created (though, we have never seen Smalltalk code  ).

Maybe you didn't earn the privilege of looking at such code

1 hour ago, Alpha_ProgDes said:

Maybe you didn't earn the privilege of looking at such code

Fair point!

1 hour ago, Oberon_Command said:

"Beautiful" has more than one meaning. Being a beautiful language from a theoretical perspective doesn't mean code written in the language is beautiful...

That is partially up to the programmer as well. So the practical perspective is always a bit ambiguous and biased.

It's a common saying that programming is not about the languages but the way of thinking, but every new language I tinkered in taught me new things. And I agree that a shallow knowledge is not enough.

Just an example: on a glimpse Javascript looks very similar to C (the basic syntax is almost the same) and LabView looks very different to them (graphical-like programming where you don't have direct control on execution order (things run "parallel")), but having done some programming in Javascript taught me that it's much farther from C than LabView from C. Labview and C can almost be translated to each other 1:1, but Javascript is very different. Variable scoping , asynchronous execution (it doesn't have anything like "halt execution till something else finishes" (no delay function, no busy loops) etc.); requires different architecture. I guess I will see that it''s not really different from other programming, but certainly it will teach me some new patterns (asynchronous programming).

EDIT: okay, it's actually pretty easy to halt execution in Javascript with a busy loop.... Anyhoo, you shouldn't. Maybe I shouldn't do programming only in the night and morning hours...

EDIT2: it's actually the task/circumstances that taught me new things, so forget everything I said