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!

要查看或添加评论,请登录

Andrea Raimondi的更多文章

  • What I learned by using Claude AI

    What I learned by using Claude AI

    Introduction After playing a bit with the free version, I went all in and got a subscription. Here are my findings when…

  • Memory safety does not exist and we shouldn't pretend it does

    Memory safety does not exist and we shouldn't pretend it does

    Preface There is a rather interesting, and misleading, discussion going on about memory safety in programming languages…

    3 条评论
  • LinkedIn users and poor profiles

    LinkedIn users and poor profiles

    Introduction I took an example from a real profile and decided to discuss it because it shows immediately all that is…

    11 条评论
  • Strategia Digitale per le PMI - Una introduzione

    Strategia Digitale per le PMI - Una introduzione

    Introduzione Una domanda che vedo spesso in giro (su Quora, ad esempio, ma non solo: anche gruppi su FB per esempio) e'…

    2 条评论
  • A tale of 1500+ views

    A tale of 1500+ views

    What is this about? About 2 weeks ago, maybe slightly more, I made a social experiment. I had an hypothesis that I…

  • Resume photo: yes or no? My take

    Resume photo: yes or no? My take

    Introduction If you haven't, then you should definitely read this article on whether to have a photo on your resume. I…

  • Cross Platform code with VCL and FMX

    Cross Platform code with VCL and FMX

    The problems with trying to recycle the code Before we lay out a solution, we need to figure out what the problems are…

    4 条评论
  • 5 comments don'ts - My take

    5 comments don'ts - My take

    What is this about? I have found an article online that you can find here talking about what not to put into comments…

  • Here we go again: TIOBE and Delphi

    Here we go again: TIOBE and Delphi

    TIOBE has had another dig at Delphi Every so often, the TIOBE Index likes to have a raid on Delphi and, as usual, there…

  • Response to "RTL Generic vs Traditional Collections" by Marco Cantu'

    Response to "RTL Generic vs Traditional Collections" by Marco Cantu'

    Introduction I know what many of you are thinking: "Seriously, dude!? An online debate on this!?" Yes. I very rarely…

    1 条评论

社区洞察

其他会员也浏览了