Alternative answer: anything else you see being used.
Learning a bit of JS means I can now make interactive reports that run anywhere.
Learning some HTML and CSS means I can throw together an OK website.
Learning some ruby and rails means I can now make certain types of websites really bloody quickly.
Learning some erlang meant I solved an annoying problem very quickly because it was just a set of message queues.
Learning some haskell wasn't all that useful directly, but was interesting. Not everything has to be some huge productive benefit for me.
Learning some GPU coding stuff back in the day let me build what I think might have been the fastest 'deep learning' thing at the time (certainly I was able to train in minutes what was taking Hinton days) and let me perform experiments remarkably faster.
Learning R recently has opened up a lot more avenues for analysis for me.
Learning some shell scripting has had obvious benefits on a daily basis.
---
I wouldn't argue for not learning other things too, but learning new languages can help because it can give you access to a huge toolkit not currently available to you. If you do sciency stuff or data analysis and you don't know any python, you're missing out on a wide range of very advanced tools that can make your life easier. Similarly with statistics and R, and I'm sure a whole host of other similar things are true for other languages.
While I generally agree with your statement, I would avoid learning too many languages as a beginner. I use 2-3 languages regularly which is fine. As long as I start using others at the same time my productivity drops significantly as I have to think more about syntax and names.
I think as a beginner it's great to learn a language in each domain (e.g. HTML, JS, SQL, Erlang). That way you always have a language to solve a task at hand, but don't confuse them. You also avoid spending too much time thinking about which language to choose for a specific task, when it mostly doesn't matter anyway.
For me I think the threshold I'd suggest is learning enough different languages (from multiple paradigms and domains) and familiarity with enough frameworks to have confidence that when you require a language in a particular domain, you know that you'll be able to get up to speed quickly.
In general it pays to know one or two languages deep down to the bare metal as it gives you a basis to reason about other languages.
I would also suggest learning a language without garbage collection: It builds character, or at least the discipline to figure out a consistent practice that ensures every resource has one allocation and one and only one de-allocation. This discipline (of thinking about data flow through your program) will pay dividends as you organize your code even in gc'ed languages.
While you're at it, learning how GC works (at least at a high-level) is useful as depending on the particular GC used in the language at hand you can either be working with it or against it.
Learn your way around basic data structures: Most languages have a significant standard library, and much of the library is usually concerned with data structures. Knowing basic classes of data structures is the important thing here. Lots of stdlibs have hashes, heaps, linked-lists, or arrays even if they call them different things but the important skill is being able to look at the language docs and find the one that meets your requirement (fast look up time, stable ordering, fast sorting, etc) or be able to build a hybrid combination that combines the requirements you do have.
Make sure you know how to use your tools including at least one debugger, a version control system, etc.
I've found it pays to create toy projects in my spare time to gain familiarity with various new software and hardware. I have been surprised how often something I've just been playing with comes up. Someone will randomly ask, "can you set up a website with a CMS and customization," or "I need a hardware timer to sync these two instruments during an experiment." And I have at least a basis to begin to come at those projects even though they weren't things I had been initially employed to do.
Another advantage is for communication. There might be frontend programmers (HTML, CSS, Javascript, templates) and backend programmers (Java, C++, SQL). No matter in which camp you are, you have to talk to the other one. It helps, if you know something about their job. Playing with their tools a little is a good way to learn that.
> And if what I’m truly trying to do is to learn to think about problems in a different way, a week-long effort at dabbling in a side project isn’t going to change my way of thinking.
I'm not sure that's why people try different languages. Certainly what I've gained from messing around with different languages over time (e.g. most recently rust) is exposure to different ideas and ways of doing things. Do I "think about every problem as if it should be a collection of tables in the third normal form"? No, but when I do need to decide how to store data I have a much better idea of how I would do it, or what I needed to look at.
Gaining experience of a range of ideas is a good thing irrespective of whether it changes the way you think. For example, if you know only one language (or one type of language), it can be quite hard to differentiate in your head whether something is a limitation of the language or a limitation of the problem. ("If all you have is a hammer, everything looks like a nail")
That being said, I do take his point that it is worth spending some time learning about things that aren't programming languages: testing, security, business, etc. After all, software development isn't anywhere near just programming. But really it shouldn't be a question of "do I learn this or that?". Read into things that you're interested in, or that would be useful at work, or just something completely different that will broaden your horizons a bit.
I don't think it matters particularly if that is a new language or not.
Programming languages probably have the worst cost/benefit ratio of anything else you can learn. In the end, much of the work that goes into thinking about an algorithm is the same in all languages, as are the components of the problems (you have functions for sorting, and for writing to files, and for getting the time etc.). Yet you have to learn a lot of details, like the standard libraries and popular libraries and all the tooling. I'm not saying a new language can't teach you valuable things, but those things are usually not worth all that overlapping effort. Moreover -- and perhaps partly because there are so many details -- languages are distracting, because people tend to fall in love with formalisms. They have an appealing aesthetic of an ordered structure, whereas the problems they're actually used for are messy.
Of course, some people love programming languages, and as an intellectual pursuit, studying them is as good as any other. But learning about, say, mechanical sympathy, data structures, concurrency, concepts in distributed programming, compilation or pretty much any CS topic which isn't tied to a specific language would have a greater impact for less cost. It's certainly good to know one language at each "level" -- systems, applications and scripting. Other than that, it's a good idea to spend as little time as possible on new languages.
I'd say switching between languages within the same paradigm has a pretty low payoff. But if you switch between paradigms -- say, you learn Prolog when all you knew was C -- the payoff is pretty big. This is because you're not merely learning new syntax, libraries or toolchain (boring!), you're learning a completely different way of thinking about problem solving.
Disclaimer: I'm not a very experienced programmer and I'm probably an idiot.
I think OP missed entirely the point of learning a new language. When I learn a new language, I try to use the language the way it was built to be used, instead of trying to adapt it to what I already know. That's why you'll often see me asking questions like: "What is the Rubyist way to solve this?". I do adapt the language, but only after I've tried their way first.
I started programming by learning C, which taught me how the computer 'thinks'. Oh, and the absolute basics of programming.
I learned C++, where I was firstly introduced to objects and reliable ways do handle resource allocations without leaks (hopefully :).
I learned Ruby, where I was firstly introduced to functional programming and a wonderful implementation of the language using objects. I also learned what expressive your code can be.
I learned JavaScript, which didn't teach me much, but I've used it extensively to practice what I had learned before. JavaScript does everything.
I learned Haskell, which taught me more functional programming, and how problems go away when you use the correct types (or containers).
I learned Scheme, which showed me how simple a language's syntax can be, while still effective. It confirmed what I knew all along: all those different syntaxes mostly don't matter.
Sure I could have learned all those things without learning a new language. But I had no idea they even existed. Now, what will I learn next? Any suggestions?
Erlang/Elixir would be a good bet. Erlang very much has a "model" to it that is hand tailored to a specific niche (reliability), and fits very well in networking scenarios. Adding to that, both languages are gaining adoption and will definitely see an uptick in job postings in the coming years.
If you want to learn a language for the express purpose of expanding your mind, try a postfix language like Forth or Joy. Those are different enough from what you've done so far that it'll be pretty strange to think in that manner at first. I haven't pursued either Forth or Joy beyond messing around with a couple toy examples, but they're very interesting to think about.
Disclaimer: I haven't used any of the languages you list other than C(++), unless you count first-term-student-level Racket as close-enough to Scheme (unlikely), so this might be something that they cover but you didn't feel worth mentioning
I'm finding Lua/Terra quite interesting. Lua [1] is an extremely lightweight fast dynamic-typed interpreted (or JIT-compiled) language (don't forget to get the penlight library, though, because it's batteries-not-included otherwise). Terra [2] is a C-level bare-metal static-typed compiled language specifically designed both to use Lua as a preprocessor and to interleave with Lua code as necessary. I'm pretty sure it ends up as metaprogrammable as Lisp but without the difficulty I had parsing Lisp syntax (might not be an issue for you, given that you've got Scheme listed).
What are the ideas that Lua follows that are different from everything else? I'm not sure it's the language I'm looking for, but I will keep it in mind if I ever need something like it. Thanks!
Minimalism, DSLs, and embeddability. It's got a very good API for binding with C, and is small enough to reasonably be included whole in any project if you don't want to have external dependencies. It's also extremely modifiable due to the minimalism - it's got a few primitive types, basic control-flow, and one structured type, the table (a key-value store) which is used for everything else from lists (integer keys, sugar exists for this) to sets (values as keys, "true" for values) to classes. Dotted attribute access is just sugar on string-key access, so methods are just functions with a "self" parameter (there's sugar to hide that) that you put in the table. Default-values and operator overloading - just specific keys mapping to appropriately-defined functions. I haven't looked much at JavaScript but I think it's a bit like JS's prototypes?
Again, though - unless you need it tiny, you probably want Penlight or something like it to provide all the utilities that weren't quite basic enough to be core. In that case, you've got a good chunk of, effectively, the Python core libraries to work with.
I might be in the minority here, but "fighting unfamiliar syntax" seems like a lazy argument to me. I've played around with many languages, and after getting used to the first non-c family syntax (in my case, Scheme) it never bothered me anymore.
There are valuable lessons I've learned from other languages and I don't think I could have learned them if I would have stayed in the language I was comfortable in at the time. It's much more difficult (in my mind) to try novelty when you have ingrained habits already.
I'm not so sure. I started (technically) with C++ and Java in miscellaneous summer camps and an independent-study highschool class, but my first serious course in a language (instead of just toy problems + messing around) was in Racket... I got the hang of it during the class, but I couldn't hold onto it the way C-family syntax just stuck, and when I last tried to pick up something Lisp-family a few months ago (Common Lisp) it was like I'd never seen Racket.
Unless that actually is "ingrained habits," I suppose, but in that case I had the habits before I ever hit college or knew that other syntaxes existed.
Indeed. Syntax is not an issue beyond your first exposure to a non-C family syntax language (and come to think of it, I learned programming with Basic, so I'm not even sure the C-like syntax thing even applies in the first place).
Unfortunately we don't live in a world where it's possible to know one language and still get hired in a job where a different language is used. To future proof our careers, we quite often have to dedicate ourselves to learning not just the qualities of a language, but also the syntax itself. We need to be able show some evidence that we can hit the ground running.
I also think that if you work in a non-opinionated language, it can be very informative studying some of the concepts used in opinionated languages. Perhaps you could say the language is a medium used for learning higher-order concepts that would be hard to understand in isolation. Quite often those concepts are very useful and can change your thought processes. An example of this is the rise of functional programming techniques in JavaScript.
I agree with the point of not limiting ourselves to just purely technical programming knowledge. It's surely about finding the right blend.
Anything other than programming. Being human is so much more than programming. Division of Labor has sucked the human in me. Learning philosophy from Epicurus, Socrates, Kant, Confucius, Marx has helped me achieve a new perspective on how I should really live my life. Now I think can do better in dealing with people.
Edit: I wonder what is the author's position on free software..
Learning a bit of JS means I can now make interactive reports that run anywhere.
Learning some HTML and CSS means I can throw together an OK website.
Learning some ruby and rails means I can now make certain types of websites really bloody quickly.
Learning some erlang meant I solved an annoying problem very quickly because it was just a set of message queues.
Learning some haskell wasn't all that useful directly, but was interesting. Not everything has to be some huge productive benefit for me.
Learning some GPU coding stuff back in the day let me build what I think might have been the fastest 'deep learning' thing at the time (certainly I was able to train in minutes what was taking Hinton days) and let me perform experiments remarkably faster.
Learning R recently has opened up a lot more avenues for analysis for me.
Learning some shell scripting has had obvious benefits on a daily basis.
---
I wouldn't argue for not learning other things too, but learning new languages can help because it can give you access to a huge toolkit not currently available to you. If you do sciency stuff or data analysis and you don't know any python, you're missing out on a wide range of very advanced tools that can make your life easier. Similarly with statistics and R, and I'm sure a whole host of other similar things are true for other languages.