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 meanwhile, 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]

Sure, compilation may be that, but this side bar is linking to compiler. A compiler is generally considered as a standalone system, not a component. I mean, they exist as components, but that's not normally what people think of, and so is likely to be less useful. And that aside, even a process has to have a system boundary.GliderMaven (talk) 22:07, 1 November 2017 (UTC)[reply]

I seem to be repeating myself: Compilation is first and foremost a process. How and when it is performed is secondary to this fact, and the distinction between "standalone" and "integrated" is all but obsolete (and see the case of Java, where you're expected to work both with a compiler—javac—and a VM—java—both of which perform compilation). Furthermore, it introduces errors into a sidebar which is concerned more with details (eg. modes of compilation) than with "systems"; in fact, the only two "complete" systems mentioned are GCC and LLVM. You have yet to show how you can make this distinction and either keep things simple and useful, or avoid errors. Mind the sidebar wasn't erroneous to begin with; your revision is. François Robere (talk) 08:33, 2 November 2017 (UTC)[reply]

So are you seriously claiming that the 'java' program is (primarily?) a compiler? I mean, I'm very, very familiar with Java, and the type-aware JIT techniques that are used to make it run fairly fast, but I would never normally refer to it that way. You seem to be saying that the sidebar should describe it that way??? GliderMaven (talk) 22:22, 2 November 2017 (UTC)[reply]

I'm saying you're missing the whole point, again. Re-read the above. François Robere (talk) 13:14, 3 November 2017 (UTC)[reply]

Nevertheless, I may have a solution in the works. François Robere (talk) 13:52, 3 November 2017 (UTC)[reply]

You've made changes. "Programs involved in execution", and underneath you've got 'compiler'??? Sorry but a standard AOT compiler isn't involved in execution. You seem to be completely in the 'compilers run stuff' mindspace? They don't run stuff, they prepare stuff to be run?GliderMaven (talk) 16:19, 3 November 2017 (UTC)[reply]

I mean I get that JIT and recompilation techniques are super cool, but the program I'm using to interact with you is simply a compiled program. The OS you're running is almost certainly a compiled program etc. etc. Bending this table to make it look like compilers do stuff that they, in practice mostly don't, doesn't really fly.GliderMaven (talk) 16:19, 3 November 2017 (UTC)[reply]

If you're willing to make constructive changes (eg. rename that section) you're welcome to do so. At the moment I'm mainly trying to accommodate your preferences without introducing errors, as your edits did. But before you do that, take some time and try to understand what this sidebar is actually meant to achieve (and by extension that section). I've iterated and reiterated it above, but you seem to ignore it. François Robere (talk) 19:25, 3 November 2017 (UTC)[reply]

I'd feel a lot happier about this if you could actually define what a compiler is. But I don't think you can. I can, and my definition is the same as the one at compiler. What's yours?GliderMaven (talk) 23:45, 3 November 2017 (UTC)[reply]

It's inaccurate, but satisfactory for the purposes of this discussion (which it does little to resolve). Are you a lot happier now? (If not, have a Tim Tam.) François Robere (talk) 00:09, 4 November 2017 (UTC)[reply]

What do you mean by 'code processing'???GliderMaven (talk) 00:11, 4 November 2017 (UTC)[reply]

Do you have a better suggestion? François Robere (talk) 00:15, 4 November 2017 (UTC)[reply]

The current revision seems reasonable. I'll revisit it tomorrow and see if it still does. François Robere (talk) 01:01, 4 November 2017 (UTC)[reply]

Notable Runtime (Libraries)?

Not to be confused with Runtime System is the point. It opens a more general discussion of whether the use of the word Runtime by itself infers Runtime library instead of Runtime (program lifecycle phase). Have been looking into this in the context of a quote in Windows Runtime

WinRT is not a runtime in a traditional sense

I guess that means not having the functionality of libraries such as CLR, CRT etc. Lmstearn (talk) 21:26, 6 March 2023 (UTC)[reply]

Usage is context-dependent. Here it implies a "runtime library" or "runtime system". François Robere (talk) 10:05, 7 March 2023 (UTC)[reply]

Do you think a distinction should be made for readers who are not sure? As you know, runtime system and runtime are already mentioned in the list:

- Code

...

- Execution
  - Runtime system
    - Runtime

...

- - Interpreter

One might assume Notable Runtimes could just be libraries as the others are included above. An extra complication is that the template category headers such as General Concepts, Types of Code etc. are not linked directly to existing articles. A short article created for Notable Runtimes could then very well explain the difference, but is it worth the trouble? Lmstearn (talk) 12:09, 7 March 2023 (UTC)[reply]

You're on to something, but I think the solution is different. I've started a merge discussion for Execution (computing) and Runtime (program lifecycle phase) at Talk:Runtime (program lifecycle phase)#Merge into Execution (computing). François Robere (talk) 12:24, 7 March 2023 (UTC)[reply]

Notable runtimes, compilers & toolchains

Things listed as notable runtimes, compilers & toolchains seems very arbitrary to me and of little value. Propose to remove all that. Stevebroshar (talk) 03:13, 20 May 2024 (UTC)[reply]