Across different paradigms, sure. But many languages are very similar to one another while only differing a bit in syntax.
If you use a language with a similar paradigm, learning yet another language in that paradigm will not teach you much, it'll mostly just annoy you with its subtle differences (I'm talking to you, stored and mutable default variables of python functions).
Python and JavaScript are at very different ends of the OOP spectrum. JS encourages a functional approach while Py is more procedural. That small difference can - and does - have a profound effect of who you structure your code.
These different designs will teach you different techniques for problem solving that can be borrowed in different languages when you’re trying to solve a problem that isn’t easily solved using its classic idiom.
Python and JavaScript have vastly different idioms, and learning both makes you think different. Learn both still makes you a better programmer, even considering they're both OOP languages
The original comment that is evidently so objectionable mentioned keeping a language (and by implication its libraries) in one's head. It's a known fact that this type of knowledge is use-it-or-lose-it. So drawing on it only occasionally is terribly suboptimal.
I’ve not found that to be the case even after learning probably close on two dozen different languages.
I won’t deny that there is a short upskilling time where you need a quick refresher but that’s no different to picking up old code you’ve not touched in a while in a language you do use regularly. In fact often the time you spend familiarising yourself with an existing codebase or new API also serves as a catch up for the language too.
That said, I have personally found that it gets easier the more languages you learn because you get good at spotting similarities. Much like with spoken languages: people who are multilingual adapt to new languages quicker because they spot patterns to stuff they’ve learned previously.
You’re probably trying to be flippant but you’ve actually made an interesting point.
Americans and Canadians, for example, usually find uncanny-valley differences between their nations that get washed out if you visit somewhere radically different instead. The small-magnitude “it could’ve been something else” realizations are just as important.
1990s Microsoft solved this problem with COM. For example, cscript.exe exposes both VBScript and JS, and they can talk to c++ via the same COM interfaces.
My favourite language is guile scheme which makes me all too familiar with your feelings.
Not only that: embedding python is a shitty experience compared to embedding lua or guile, and you have to work around the fact that python has no threads and that it is borderline impossible to run multiple independent interpreters in the same process.
> Not only that: embedding python is a shitty experience compared to embedding lua or guile...
That's a "feature", they prefer for people to extend python over embedding it in other applications.
That said, it isn't too bad unless you maintain the python c-api binding by hand since there's a lot of boilerplate and they like to change the api often.
Almost all my blender hacking was on the python API and that's crazy complicated compared to a terminal emulator. For example, all of the (context sensitive) operators are callable from python since the UI is controlled by python scripts.
> ...and you have to work around the fact that python has no threads and that it is borderline impossible to run multiple independent interpreters in the same process.
Pretty sure python has threads;P and has had subinterpreters[0] for a long time. Haven't really messed with either one other than making sure my C extensions release the GIL though.
I did attempt to embed lua in an application once and from what I can remember it was...interesting. Having to control the stack took some getting used to and their boilerplate was just as full featured as python's. I also don't remember being able to find useful automation scripts, with python I usually just bang out a quick prototype with pybindgen then hand edit it until I'm happy.
No proper concurrent threads was of course what I meant. In that light the subinterpreter feature is also not very good, since all sib-interpreters share a GIL (but iirc there is a PEP out there that might make python properly multi-core through some kind of CSP-approach and independent subinterpreters).
It seems a waste having to keep a battalion of imperative OO languages in one's head just for incidental use.