What languages should a person learn to be a well-rounded programmer?

Based on what I've heard from top devs - Lua (supergood for devs), C# and C++ are three. Then learn SQL, XML, etc to support your projects. Also (if you're a gamedev) learn at least 1 game engine, like Unreal Engine or Unity. Even Gamemaker is worth it, at least for prototyping. But again, that's coming from others not me. I'm no expert.

It depends on what you're programming. Knowing a language is one thing, but knowing how to code is quite a different thing. There's abstractions and paradigms you need to understand, clean code, proper commenting, architecture, etc etc. Don't worry though, it'll all come in due time. Just keep at it.

Learning a new language after you learned your first one is proportionally easier. Especially after learning something comprehensive like C++ or even C#. I'm guessing a "functional language" (like (edit:) F#) is also nice to know, depending on your specific field. But don't take my word for it.

2 hours ago, Madolite said:

I'm guessing a "functional language" (like D) is also nice to know, depending on your specific field. But don't take my word for it.

D is not a functional language by any stretch of the imagination. It is much more procedural/OO in the vein of C++.

2 hours ago, 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. They can be general purpose, but again, AFAIK, they're not meant to be.

R, maybe. Julia I could argue about, but Perl and Erlang are both perfectly capable for general purpose development. But just because a language doesn't do "everything" doesn't make it less valuable to learn. Domain-Specific Languages are everywhere and any good architect should be comfortable pulling the DSL tool from the toolbox when it makes sense to do so.

I don't particularly feel that there is a magic set of languages that will make you a better programmer. I think it's more the case that you should learn many different tools for solving problems - and sometimes new languages are a good way to learn those tools. A programming style is like any algorithm or data structure: it will be well suited to some types of problems, and ill suited to others. Learning when to use certain tools is the biggest part of being a great programmer IMO.

That said, if there's one major language family to learn to blow your mind, it's Lisp. The sheer elegance of erasing the code-and-data distinction is revelatory and valuable even if you never write a line of Lisp once you've learned it.

1 minute ago, ApochPiQ said:

D is not a functional language by any stretch of the imagination. It is much more procedural/OO in the vein of C++.

Sorry, I guess I meant F#. My bad and fixed.

Learn Haskell. It's great and gives you a new perspective, that you don't often have when working with impreative / strict languages.

C++ is a multi-paradigm language. From wiki:

Even if it does not support (yet) paradigms like aspect programming, or will never go into the imperative paradigm, or its syntax is not as cleaned as some "theoretical-oriented languages", to my opinion, this is a language one must know.

Quote

What languages should a person learn to be a well-rounded programmer?

Languages don't really make you a better programmer, concepts, techniques and algorithms do. Different languages are a proxy for this, as they bundle up opinionated implementations of a selection of concepts, techniques and algorithms.

What you want to look for are different languages that espouse complimentary sets of concepts and techniques, and solve challenging problems using similar algorithms in them—so that you get a sense for how different languages (again, as proxies for concepts and techniques) occasion different implementation strategies.

Good question, though.

My general recommendation is that to stay relevant developers should learn one new programming language every year. Even better if it is a departure from things already comfortable with, but the key factor is that you keep learning.

Right now as a general recommendation, new programmers should first learn ALL of these languages: C++, Java, C#, C, JavaScript, Python, and SQL, and also learn markup languages including HTML, XML, and JSON. In all these languages a programmer should be fluent enough that if handed some code they could read it and expand on it, even if it isn't their primary programming language.

In practice an entry level programmer will probably know two or three of them, but they should still learn those they don't know, and continue learning at about one per year. I see it as much the same a doctor must stay current on medical research, or the way a lawyer must stay current on new laws and new precedent, or the way an architect must stay current on architectural codes.

@frob yes, developers especially entry-level developers should know the languages you listed if they want a job. But I just mean the languages that make you a better programmer period, regardless of employment status.

How many or which languages you know is not what makes a good programmer though- it's about how you employ those languages to accomplish whatever your task or goal is.

And learning extra languages is an effective way to understand how to do that better.

Yeah, it definitely can be. I just mean that it's not the only way. And knowing lots of languages doesn't mean necessarily that you can do any of them well. IMO a deep understanding of a small number of languages is better than a shallow understanding of a huge number of languages.

Like if I was going to hire a guy for javascript- I'd rather hire the guy who says "I've been using javascript for years, I don't really know any C++ though", than the guy who says "I know 100 languages! Javascript is just one of them!"

I think it's fair to say that continuing to learn is always a good thing, but I personally wouldn't focus on something like the number of languages. You could also spend that time learning new ways to use the languages you already know. Or learning how to use a new engine, package, library, etc. you've never used before. Or learn how audio works. Or learn how ECS works. Or learn how to use Windows API instead of using something like SDL or what have you to manage windows for you. As long as you're learning something at all.

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, . 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

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 ).

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

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