Interpreted vs Compiled distinction

I was made aware of an article on interpreted vs compiled languages

And I think the distinction still matters! And, no, the article's conclusion that sounds so sensible, to me, is not sensibile at all. However, I don't entirely disagree with it, I merely disagree with its most important passages ;-)

Big runtime vs Small runtime is a false dichotomy

When you think about this distinction, you may very well be tempted to agree because it sounds absolutely reasonable; however, it's not nearly as reasonable as you might initially think and I can show you an example: C#. In a lot of ways, C# sits right in between, but I think no one will be arguing that C# is interpreted, right? So, instead of big vs small runtime, maybe if you want to go down that route we should be talking of runtime pervasiveness and ease of install. I'd challenge, for example, any average user not in web development, to argue that you need PHP or Python installed on your machine for the average workflow. .NET instead is installed by default on Windows and it's easy downloadable for Linux/Mac because there are specific distributions for it. But even this is a distinction I don't really like, in general terms, so let's try something better!

Predictability of outcome vs Anticipation of outcome

What, I think, creates a neat division between interpreted and compiled languages is that compiled languages have a predictable outcome. With interpreted language the best you can muster is anticipation of outcome, but with no predictability attached. The reason you have no predictability is that interpreted languages must have certain properties to be practical such as very weak typing. There is a very good reason, also, for wanting very weak typing: weak typing allows constructs that rely on anticipated behaviour to drive a result.

Let's make an example: imagine to have a Javascript code block that queries a REST endpoint and fetches a dynamic JS code block to eval. Now, I think we all agree that this doesn't sound... great... but there are situations where behaviour like this is wanted, desired or even the only way to solve a problem (think for example of bespoke behaviours for particularly large tenants) without affecting the rest of the codebase.

Compiled languages, by and large, don't allow you to do this: the best you can do is some additional engine which will use the language in an interpreted way: and even then, it's not a free for all, you're still bound by the language rules.

Compiled vs Interpreted is a strategic, not tactical, decision

One thing I never see mentioned when the dichotomy is outlined is how this is really a strategic decision rather than tactical: you choose one or the other because you have a clear strategy around how the whole thing is supposed to add value. That's however not to say that you can't have both playing pivotal roles in different ways: you could, for example, have a ASP.NET backend but want to use Python and Django for your frontend. Splitting things has many advantages, one of which being that two completely different sets of developers work from different sides on the same APIs for example. This split will therefore bring a much wider view into focus and allow for much more resilient and easy to use APIs, potentially making a third party market appealing or even at all possible.

I still welcome the traditional distinction - for good reasons!

After all of this, you may be tempted to think that I welcome new ways of looking at the distinction but... I really don't. I think the traditional distinction, at the level at which it is used (i.e. some kind of Programming 101 course...) is perfectly fine, appropriate and educational. That is however not because I agree 100% with it but rather because I do not! I think it's perfectly fine, in a sense, because of how fundamentally flawed it is and how much nuance there is to consider and I strongly believe that it's on the students exposed to this definition to challenge it in order to grow their "programming muscle", because when you really think about it, all programming distinctions are full of nuance and minutiae that only matter in the 0.000001% of cases but in those cases are essential and defining of a choice!

Let people think for themselves around topics such as this

All in all, I think it's important for students of any level to really consider these things and make their own minds up: one day, their vote may cause a sea change in strategy and implementation and the time to think about this stuff is before it weighs on your vote for a decision that might change something forever.

Developers of all levels of experience and from all industries really should occasionally pick up their "philosophy" baton and think about this stuff, because this stuff matters in non-obvious ways and, trust me, one day you might very well be involved in a decision that could change everything - and you want to have your philosophy right by then!

Cheers!