Template talk:Program execution

Remove "Javascript engine" from "General concepts"

The section "General concepts" isn't related to a particular language. Shouldn't the link to "Javascript engine" be removed ?

Bastien bellomo (talk) 12:57, 5 September 2016 (UTC)[reply]

You're right it isn't language-specific, but "JS engines" are a major runtime category these days (owing to the ubiquity of JS), and I think they deserve a mention as such (in addition to mentioning node.js under "notable runtimes"). I wanted to add it as a subcategory of VMs, but seem to have forgotten to indent it. What do you think? François Robere (talk) 18:34, 5 September 2016 (UTC)[reply]

PS The ubiquity of JS engines is such that a subset of JS is now being developed as a kind of new assembly, able to run application written in many other languages. This generalizes JS and, in my mind, makes those runtimes worth noting not only as "JS engines" per se, but as a particular category of VMs. François Robere (talk) 19:21, 5 September 2016 (UTC)[reply]

Reordering by role rather than function

GliderMaven Regarding your recent edit: the problem with categorizing the different execution strategies the way you did (and indeed the problem I had understanding them myself, some time ago) is that the compiler/interpreter dichotomy ceased to exist with the advent of VMs. A VM, on paper, is a glorified interpreter; in reality it's part of a complex system that translates, optimizes and executes code using different strategies in different phases of the program's execution. It is neither a compiler nor an interpreter per se; indeed, VMs have completely substituted the latter. So I'd rather the classification be more granular, by the function of specific components rather than the broad categories of "compiled" vs. "interpreted". François Robere (talk) 13:57, 31 October 2017 (UTC)[reply]

I'm perfectly aware of that. There is however, a useful distinction that you can make. You need to draw the system boundaries correctly. Does the system translate, or does it run the code? If it's a VM, then it's not a compiler. Sure it may well *contain* a compiler, but it's formally an interpreter or run time system. Likewise, a compiler may well contain an interpreter for optimisation purposes, but fundamentally, it doesn't execute the code- it outputs code, which has to be run by a second system. They have *different* definitions. GliderMaven (talk) 15:34, 31 October 2017 (UTC)[reply]

But this isn't about "system boundaries", but about components. Both interpreters and compilers perform AOT compilation and transcompilation, yet you list them under "compilation" alone. A single VM can perform any and all of the functions of a compiler at run stages, but you put it under "interpreters" alone. Were we to list all of the programming languages in existence under either "compiled" or "interpreted" you might have had a point (though several language are both compiled and interpreted, both being performed by a single executable), but as it stands this distinction is not only inaccurate and irrelevant (from a theoretical POV as well, by the way), but leads to errors when a more granular analysis is needed, as in this case. François Robere (talk) 21:02, 31 October 2017 (UTC)[reply]

No, a compiler behaves externally completely differently to an interpreter. As I stated, even though some interpreters internally contain components that are compilers and vice versa, they still behave externally as interpreters and compilers respectively. Trying to merge them into one thing gets you nowhere, and is particularly unhelpful to the reader who is trying to learn as well.GliderMaven (talk) 22:58, 31 October 2017 (UTC)[reply]

It is incorrect to describe a system in that way by its components. That's a fallacy of composition.GliderMaven (talk) 22:58, 31 October 2017 (UTC)[reply]

A VM is an interpreter, not a compiler; because of the way it behaves, even if it uses compilation internally.GliderMaven (talk) 22:58, 31 October 2017 (UTC)[reply]

Or, let's put it this way: in our own articles, both Compilers and Interpreters tend to be defined by their external behaviors, not internal technologies.GliderMaven (talk) 23:15, 31 October 2017 (UTC)[reply]

So you admit that a compiler/interpreter can be both a component and a system. We may get back to that later.

and is particularly unhelpful to the reader who is trying to learn as well: you're grouping all but one of the compilation strategies under "compilers" alone, despite all of them being used by interpreters as well. How is that helpful (It's also rather lacking, as your grouping addresses only the compiler/interpreter distinction, rather than the actual phases of execution)? François Robere (talk) 14:01, 1 November 2017 (UTC)[reply]

Because this table is trying to organize something by its primary essential features, and external behaviors that they necessarily have is a really good way to do that. Organizing something by internal components that something may, or may not even have, doesn't go very far at all.GliderMaven (talk) 15:48, 1 November 2017 (UTC)[reply]

Describing an interpreter as a 'translator' is decidedly awkward, and in general, incorrect. The most commonly written types of interpreters, don't do anything that would be generally recognized as translation, at all.GliderMaven (talk) 15:48, 1 November 2017 (UTC)[reply]

No, it's not... and I should know - I created it.

So you're adamant that compilation strategies, for example, have nothing to do with virtual machines, and should not be grouped together? François Robere (talk) 16:45, 1 November 2017 (UTC)[reply]

It's a great sidebar, but you're trying too hard to overcomplicate things. These sidebars are only a thing for people to find the correct articles, not uncover deep connections between them. Those connections are very described well in the relevant articles. Keep It Simple and Stupid!GliderMaven (talk) 17:25, 1 November 2017 (UTC)[reply]

On the contrary: I am trying to keep it simple; and not only simple, but correct. Let whoever is interested go about reading on the exact differences between compilers, interpreters and VMs. In the mean while, let the sidebar reflect that there is no difference between compilation performed by either, rather than confuse the poor reader who wonders how is it that JS can have a compiler, and when did C become an interpreted language. Compilation is first and foremost a process, and this sidebar means to reflects that. François Robere (talk) 19:48, 1 November 2017 (UTC)[reply]