I was one of those who disagreed with that, but then I was forced to learn several new languages for work. Now I agree with it wholeheartedly.

my favs:

-clojure for processing deeply nested data

-rust for general stuff

-java for concurrency support and general stuff

-c for easy pointer manipulation and "tricks"

-sql

-bash for scripting (I'm that weirdo who would rather make a huge shell script rather than using python)

I still need to find something good for arrays/ matrices. MATLAB was kinda fun I can't see it being used in production in anger too easily

For arrays/matrices I'm falling back to Fortran. It has builtin support to matrix/vector multiplication (and other operations of course). There's no need to install other libraries, or to deal with virtualenvs, or package managers. Fortran is not that sold creepy thing from the 70s anymore, Fortran90 (and later) is pretty elegant IMO.

Cheers to that! Fortran introduced me to “:” syntax, back before I’d ever heard of numpy. (Or expression templates for that (somewhat tangential) matter)

Python's NumPy library deliberately emulates much of the functionality of Matlab's core (similarly, fundamental plotting with matplotlib follow similar design cues). As a lapsed long-time Matlab user, I think they're just as fun to use.

There is also Octave, an open-source Matlab alternative, but when I last used it (admittedly quite a while ago) it had limited support for toolboxes (e.g. signal processing). I imagine it has only improved since.

For elegant matrix syntax I like julia or fortran better, if I need a lack of a license or more speed. Octave is good too, but it is much slower than Matlab. Numpy is in a weird spot. Its still slower than Matlab, but its everywhere, but all the versions and environments are different so you need containers to be portable.

APL is awesome for matrices.

https://en.wikipedia.org/wiki/APL_(programming_language)

Careful with Bash... https://mywiki.wooledge.org/BashPitfalls

I write huge scripts with bash. I know many of the pitfalls referenced on that list (and more), but this a great resource for teaching others. Thanks for sharing it!

> I still need to find something good for arrays/ matrices

R?

MATLAB, if you can get a license would likely be better. Name literally means "matrix lab". Has excellent matrix manipulation features.

And Octave(https://www.gnu.org/software/octave/index) if you can't get a license.

I actually had one hectic weekend porting our whole departments MATLAB code over to Octave due to a hardware failure of our licensing server and some stonewalling from Mathworks, Octave is pretty close to fully MATLAB compatible.

Worth a mention, but it's not comparable in terms of feature set and execution time, sadly. I'd love someone to come along and make a MATLAB (Modern Fortran) knockoff that kills MATLAB.

The biggest advantage of bash over scripts is parallelism. It's not bad at job control, and if you write your scripts so they communicate well with streams, you can scale them up with a little bit of bash, xargs -P, parallel, etc.

Even more important than different languages is to learn about different execution models. For instance, the difference between Java and C++ is relatively minor from that perspective, compared to (e.g.) understanding how Prolog works. That will open entirely new horizons if your previous experience was based on C(++)/Java(Script)/Python (just to mention a few of the usual suspects). Just look at how the addition of FP features to “OOP” languages considerably widened the field of possibilities.

Learning (very basic) Prolog indirectly caused me to learn to write parsers, AST transformations and symbolic derivation - I picked up a book on Prolog and was mystified by how simple the examples of symbolic derivation were in Prolog, a subject I was struggling with. So I sat down and figured out how to do an expression parser just so I could write a solver that mimicked how Prolog did it to understand how it worked. And in the process I learned a lot more.

It was transformational in a way my maths teacher was not...

Yeah i agree, I was a bit clumsy about it but this is really what i was digging at in my examples.

I see a lot of conversation on here dedicated to whether you’d like your data with your functions (objects) or your functions with your data (closures). Rarely see array, logic or constraint programming paradigms mentioned.

FP has been rediscovered again and it’s the hotness right now but it’ll die out again like it did before OO stole its lunch, i can almost write the blog post headlines just now “arity considered harmful”, “OO and side-effect management not mutually exclusive after all!”

I’ve got a fiver on the next big one being a re-visit of structured programming.

> a re-visit of structured programming.

God I hope so, probably the worst time I have teaching junior developers is helping those who have only used for-each write a loop with a useful invariant and not a garbage fire of breaks/continues.

I’m surprised you don’t mention Perl in this list. It’s the de facto Unix scripting language and frankly more suitable to the task than others.

Perl on the command line is beautifully concise; it’s easily embedded into CI/CD pipelines because the q, qq, etc escaped quotes; it has best-in-class regex support; calling external utilities equally concise with qx or back-ticks; etc etc.

Personally I tend to favor C/C++ for the main event and Perl for everything else on the systems side.

JavaScript is obviously ubiquitous on the front-end but it feels very clumsy. Not a huge fan of that on the back-end system it’s just too weird to do simple stuff like “parse a file” or “rip through a directory tree” or call a shell command.

Ruby is a better Perl; it's closer to Perl than e.g. Python, it has fewer footguns but is also very expressive. It also has alternative quotes, backtick, shellescape etc. for ad hoc shell integration though you're better off learning IO.popen and others to take the shell out of the equation.

Subjectivity aside: the fact stands that Perl is the most ubiquitous scripting language on Unix and the de facto standard. You’ll find it by default on many container environments as well—but hell if you’ll find Ruby. ;)

On most of my Linux systems Perl is only installed as a dependency of debconf or git.

I’m sure the Linux kernel community is still using it, but FreeBSD even managed to remove it from the base system.

It’s still ubiquitous… “standard”?

Perl is frustrating. Having variables in scalar, hash and arrays is not do bad. But having the strange syntax to use them is so annoying. Coming from other languages it always takes me a day to get back in the habit. I'd gladly never touch Perl again.

I think it's fine to "learn" lots of languages, but you're going to be pretty bad at most of them. And I personally wouldn't be comfortable with building a system that will reach hundreds of thousands of LOC in the majority of the dozen or so languages I've "learned" over the years.

If you're really going to learn a language - as in, build idiomatic programs - its a constantly moving target and requires a lot of effort to maintain.

I think it's better to learn 2-3 languages, and have passing familiarity with others. People like to pretend that language choice solves all your problems, but usually you're talking in percentages: one language is a 80% fit for your problem, another is an 85% fit... there is never a 100% fit - are these differences worth working in a language you barely have any experience in?

I think it depends on the language and background. Learning Go is maybe a 20 hour enterprise. Learning C++ if you're coming from Rust? Maybe 20-40 hours, not sure. Learning C++ coming from Python? Well....buckle up.

Same in reverse btw. Going from C++ to Python is probably easier than Python to C++, but it's still not going to be as easy as, let's say, java -> C# imo.

I mostly agree, but I think 2–3 is too few. I think I'm pretty good at C, bash, Python, make, and JS, and also (if we're counting languages that aren't programming languages) SQL and HTML. I used to be pretty good at Perl, but the language has moved on since then. I think I have more than "passing familiarity" with i386 assembly, PostScript, OCaml, Java, C++, BASIC, Bicicleta, Scheme, Lua, and Brainfuck; that is, I can figure out how to write things in them without constantly looking stuff up, and I'd be comfortable writing hundreds of KLOC in them, but what I write is surely not fully idiomatic. And there are another 32-64 languages I have passing familarity with, meaning that I've written useful complete programs in them, including Golang, Rust, Excel, Smalltalk, PV-WAVE IDL, Prolog, Common Lisp, Scala, Octave, Elisp, Ruby, Pascal, Clojure, Forth, R, and Tcl, but I can't think of most of them right now.

I guess in the context of your comment this sounds like bragging, but that's not my intent; I'm trying to rebut your comment, using myself as an example, because I think this level of polyglot programming is pretty close to normal, at least after you've been at this stuff for a few decades. Maybe if you're getting into a rut of only knowing 2–3 languages well, you'd benefit from putting more effort into exploration. Unless you're about to stop programming, in which case you won't have time to take advantage of your newfound powers.

I don't think percentages are a good way to think about language fit. I think it's more like an effort multiplier. In theory I can solve any programming problem in C, but when the problem isn't huge and performance isn't much of a challenge, I can usually solve it about with about a tenth of the effort in Python. There are problems where solving them in SQL is about three times easier than in Python, and problems which can barely be solved in SQL, so solving them in Python is about a hundred times easier.

As an example, in my experience it's pretty common for Python to be about half as much effort as Scheme, but there are much better Scheme implementations out there, so when performance is a challenge, solving them in Scheme can be a hundred times easier than solving them in Python. But if you know Scheme and not Python, you can often get twice as much done by learning Python, even for problems where you might say Scheme is a pretty good fit. But it's true that at the beginning, when you have barely any experience in Python, you won't be faster; you'll be slower. And you won't know if that will ever change.

Most commonly, though, people use the language that is best integrated with their chosen platform, because that saves them the effort of writing a bunch of integration code in addition to the actual application code. If you're writing DHTML, for example, use JS, not C. If you need to invoke JVM libraries, reasonable options include Python, JS, Kotlin, Clojure, and Java, but not Perl, C, or C#. If you're writing a Minetest mod, do it in Lua.

So, if you only have more than passing familiarity with 2–3 languages, I think you're going to frequently run into cases where that ignorance costs you a factor of 2 or 3 in effort.

I certainly agree, though, that choosing the right language won't solve all your problems, and it's easy to have exaggerated hopes for it.

Languages evolve and it takes time to learn all the quirks. Usually you need a systems language, a scripting/shell language, and a front-end language. Sure you can get good at the entire stack, but that take time. I would say spend 70% of your time to get shit done, then 30% learning/researching.

I could write a backend in Elixir, Go, JavaScript, Python or C#, and language choice alone will lead me to very different architectures. Knowing multiple languages from the same category broadens your horizon, and choosing the right one helps you to work with the language and its ecosystem instead of constantly fighting against it

This is a great strategy to have but I would reformulate it as “make sure you know enough languages to solve system, scripting, frontend and backend problems efficiently”.

You don’t necessarily need a separate language for each domain.

Incidentally, ASAN / MSAN / TSAN are part of Clang and GCC, not C++ itself, so they're available for other languages, e.g. Rust (https://github.com/japaric/rust-san describes how to use them) and Golang (well, TSAN and MSAN at this time).

Related: MSAN is made so much better by -fsanitize-memory-track-origins. I can't count how many times MSAN caught an error, and with that flag enabled, it directly pointed to the exact line of code at fault.

I like the general purpose GC languages like Java JS c# python lisp for most tasks though, and then go with something a bit wilder or low level like Go Haskell Rust Erlang c++ c when needed. Or R/apl for a mathy problem.

Since I enjoy high level programming and the natural experience chicken/egg I never do the low level stuff. Not since Acorn Electron assembler! But I know of it.

JS isn‘t a general purpose language, even though is has been shoehorned to be one.

What does that even mean? I've pretty much gotten away with using JS for just about everything for the last 4 years. The evolution of a language to make it compete with other languages isn't necessarily "shoehorning". Am I not a true developer because I like JS and haven't found a need to write code in something like Rust?

EDIT: Do you mean that it lacks certain features without a runtime like Node or the browser? For instance, it doesn't have a language construct for opening files like Python or Ruby. If so, I don't think that's a good argument.

I would say it is. It didn't start as one but over the decades it sure has become a general purpose language.

I can't find a domain where JS wouldn't fit the description. While it may be a bad fit for certain problems, it can still be done.

Safety-critical controller for manned or unmanned aircraft, ground vehicles, etc. High frequency trading. Tiny embedded devices. System libraries.

I’m sure I could come up with more. JavaScript is a tool, just like c, go, rust, python, lisps, etc. I’m going to give you the benefit of the doubt and hope you just didn’t consider all of these other domains when you made this comment.

Cheers!

The domains you listed are not really disproving my point. I'm certain that programs could be made in JavaScript for these domains but, like I said in my first comment, it's probably a bad fit.

For example: Espruino is a platform for embedded JavaScript.

I just think about it this way: Just because you wouldn't doesn't mean you couldn't

JS is incredibly versatile, though I would agree that that's mostly JavaScript being equally bad in nearly every domain :)

I wonder how much of the horizontal scaling trend is driven by JavaScript's horrible threading story.

You might be confusing the JavaScript programming language and the browser runtime.

The former is a general purpose programing language that favors prototypical object oriented programing paradigm but supports multiple other paradigms such as imperative and functional.

The latter uses the JavaScript language and adds on a bunch of specific APIs (such as the DOM) for specific purposes. This includes APIs for DOM manipulation, playing audio, validating inputs, parsing forms, handling key presses, etc.

I'd be curious to hear some examples where JS doesn't fit as a general purpose language. In my arrogance I suspect it would be hard to give examples that don't also disqualify other scripting langs like python and ruby. Perhaps you don't consider those to be general purpose either?

For example, without something like Node, you cannot even open a file. I consider this a very basic requirement for being "general purpose".

it sounds to me like you're talking about a particular implementation (the browser) not the language itself. The browser intentionally has that limitation. The language itself has no problem with it.

Yes I mean JS with node

Haskell is also garbage collected

Well, this advice is from 1998 and still got some truth to it.

In 1998 languages did not have that many features and were in my opinion easier to grasp. Just have a look at modern C++ or Java's cadence of new features.

In 1998 Java and JavaScript were new. Now they evolved into widely adopted general purpose languages.

I remember 1998 pretty well - mostly for Linux distros becoming mature enough to be accessible for “normal”-ish people but it was a pretty exciting year for languages too. There was an absolute ton of hype for Eiffel, every month dr dobbs mentioned it at least once and Ada95 was enjoying a renaissance too - i forget the specifics but something changed in licensing and GNAT was integrated more with the GCC. Haskell was a hive of activity and Python was starting to gain widespread attention but it was no where near to dethroning the favourite language of people who signed their emails “JAPH” :-)

Your comment reminds me how much i miss dr dobbs journal. I learned so much on those pages.

The thing, in my opinion, is to avoid spreading yourself too thin.

I started using C/C++ more than 20 years ago and even if I feel really comfortable with the language (except the latest revisions) I am still learning and improving.

I don't think I could achieve the same level of mastery on half a dozen languages.