6
$\begingroup$

There has been some significant disagreement over whether or not Why target an existing VM? ought to be closed. Here is the timeline as I understand it:

  • The day the question was posted, I believed it to be too broad to be answerable as-written. After a discussion in chat, I decided to cast a binding close vote.

  • A user voted to reopen the question, but it failed to be reopened in review. Three users, including a fellow diamond moderator, voted to leave it closed; one user seconded the vote to reopen.

  • Two days later, the question attracted a third reopen vote. It attracted two more reopen votes in review, and it was reopened.

  • Today, I discussed this question again in chat with one of the reopen voters and successfully convinced them it ought to have remained closed.

All told, this means four users, including two diamond mods, voted to close, while five users voted to reopen, one of which was later convinced this was a mistake. I also happen to know from discussion in chat that the third diamond moderator agrees that the question should be closed. This is a substantial split in opinion, which isn’t a great situation to be in.

I would like to find some consensus about whether this question should be closed or remain open, and I would like that consensus to be based on actual discussion of the question and its answers rather than a simple popular vote. Please weigh in: do you think this question deserves to be closed, and why or why not?

$\endgroup$

3 Answers 3

2
$\begingroup$

I strongly believe this question deserves to be closed. Here’s the executive summary of my reasoning:

  1. I do not understand the question as-written, and both the question’s answers and extensive discussion in comments and in chat suggest that almost nobody interpreted it the way the OP had intended.

  2. Every answer on the question answers a different question from the one the OP apparently intended.

  3. The existing answers do not support any obvious reinterpretation of the question to make it clear.

  4. None of the existing answers are particularly high quality.

Elaboration of each of these points follows.

The question is unclear as-written

The most essential point to my case is that I believe the question is simply ill-defined. It asks “why target an existing VM?”, but a “VM” in the context of programming languages is not, on its own, a well-defined class. The border between a bytecode interpreter and a VM is often very fuzzy, and many interpretations of the term would include such a varied set of implementations that it would be impossible to discuss them as a uniform whole.

A potential interpretation of the question that would at least define the class of VMs would be to narrow it to VMs intended to be targeted by other languages. However, elaboration in the comments and in chat by the OP make it unambiguously clear that this was not their intent. Instead, the question is apparently intended to include “all internal VMs”.

However, this itself is not a well-defined class. Does it include, say, the GHCi bytecode interpreter? I have to imagine it must, but lumping the JVM, CPython, and GHCi into one bucket seems wildly too broad to attract a useful answer. Indeed, if someone told me they were writing a language that targets GHCi bytecode, I would wonder if I were hallucinating, while targeting the JVM is an eminently reasonable thing to do. OP has not explicitly clarified whether or not these examples fall into the intended scope of their question, but discussion in chat suggests that they do.

What’s more, the question text even considers LLVM as a potentially legitimate VM, something most people would agree it is not in the sense of the JVM (despite its name). At this point, I have to wonder what isn’t in the intended class.

Every answer fails to answer OP’s question

If we accept that the OP’s intended question includes “all internal VMs”, every single answer on the question is wrong. They mostly discuss interoperability, ease of implementation, access to an existing toolchain that is easier to understand and debug, and free optimization or JIT compilation. These points very obviously do not apply to all internal VMs.

Given that not a single answer manages to adequately answer the question OP intended, it seems like a pretty open-and-shut case that the question is insufficiently clear.

The answers do not agree on the question’s interpretation

Even if it was not OP’s initial intent, we could theoretically salvage the question by updating its text based on the answerers’ interpretation. That way, the answers would no longer be wrong, and given that there are no answers to the intended question, we wouldn’t lose anything. Unfortunately, this is not obviously possible in this case.

The highest-voted answer assumes broad platform support and states the VM is “VM is likely to have good JIT optimization.” Another highly-voted answer says “people are more likely to have that VM installed already”. How do we define this class of VMs with JIT optimization that have a broadly installed userbase? What are the members of this class? Are there any members of the class other than the JVM and the CLR? (Note also that the original question explicitly excluded the CLR.)

Perhaps the question could be narrowed to be about the JVM specifically. That seems to essentially preserve the intent of all of the answers except for the single negative-scoring one. However, these would be relatively poor answers to such a specific question, and many of them discuss other things in passing. This brings me to my final point.

None of the existing answers are very good

None of the existing answers contain anything terribly insightful. Many of them could serve equally well with little modification as answers to the question “why use a framework rather than rolling something yourself?” They are short, lack detail, and uniformly contain zero references.

These poor-quality answers are a symptom of an unhelpfully broad question. The class of “programming language VMs” is simply too big to discuss as a single class, so it is nearly impossible to say anything interesting about the general class. Moreover, there is no obvious, generally accepted taxonomy of VMs, so the class cannot be easily divided into representatives that may each be individually discussed. It also does not function as a survey question, so a variety of answers that cover individual implementations fail to adequately answer the question.

Verdict: the question should be closed

I do not see any path to salvaging this question, and I plan to close it a second time. If you disagree with my arguments and believe this is in error, please post an answer with your reasoning. Perhaps there is a path to a good question here that I have not seen.

$\endgroup$
1
  • $\begingroup$ What non-bytecode-interpreter "VM"s do you have in mind, exactly? $\endgroup$ Commented Aug 1, 2023 at 2:11
-2
$\begingroup$

I disagree, and I think the question is fine. I'll address Alexis's points directly, since otherwise I would be trying to prove a negative.

  1. I do not understand the question as-written, and both the question’s answers and extensive discussion in comments and in chat suggest that almost nobody interpreted it the way the OP had intended.

I don't see it. The question is clear enough to me, and the answers look like they answer the question as I understand it. Perhaps people in the chat room did not, but I'll instead go by the comments on the question asking for details or clarity. Of the comments which do seek improvements:

  • Michael Homer questioned the suitability of the tag, which was subsequently edited out.

  • Alexis King wrote, "I think this question is too broad. The reasons to compile to a VM specifically designed to supports lots of different languages (like the JVM/CLR) are totally different from the reasons to target a VM that is essentially just a runtime for a specific language." That may be so, but the question asks about the latter and specifically excludes the former.

    The point of contention seems to be that the OP cited the JVM as an example, and Alexis argues that the JVM is "specifically designed to support lots of different languages". But the JVM was designed specifically for Java, so it makes sense for the OP to include it in the category of VM that the question is about. It may be that the design goals of the JVM have changed since other languages started targeting it, but this happened after those languages made the choice to target the JVM, so the rationales for those choices are in scope for the question.

  • Karl Knechtel asked, ""Given all that, why would you want to target another language's VM?" - what alternative are we contrasting this with? Compiling to native code? Creating a new VM specific to the language? Something else?" ─ the OP clarified that the question is about the latter, i.e. using an existing VM as opposed to creating a new VM.

I can understand why these commenters thought the question to be unclear, but I think the OP has adequately responded to clarify all of these points. Perhaps this information from comments should be edited into the question, but that can be done without closing it.

What’s more, the question text even considers LLVM as a potentially legitimate VM

The question only names LLVM to exclude it from consideration, on the basis that it is designed to support lots of different languages. The fact that it can also be excluded on other grounds (i.e. that it is not really a VM) perhaps seems more obvious, but either way it's not unclear to me ─ the question excludes LLVM.

  1. Every answer on the question answers a different question from the one the OP apparently intended. [...] If we accept that the OP’s intended question includes “all internal VMs”, every single answer on the question is wrong.

I disagree, and I do not accept that the OP's intended question includes that. The question doesn't use the words "all internal VMs", and only refers to "internal VMs" when describing the alternative choice of writing your own VM. Quoting from the question:

Some languages, instead of using their own internal virtual machine, compile to target another virtual machine instead.

The question does not say that the other virtual machine targeted instead must be an "internal" one. It says that targeting another virtual machine is an alternative to writing an internal one. That said, I'm not sure the word "internal" here is even that significant; clearly, the other language's virtual machine has to be "external" enough that it can be targeted by a third-party compiler.

  1. The existing answers do not support any obvious reinterpretation of the question to make it clear.

I believe the question is sufficiently clear that we don't need to read the answers in order to interpret the question.

  1. None of the existing answers are particularly high quality.

Several of them have decent scores from upvotes. I think that matters more than any other argument I could make in defense of the existing answers, because such an argument would count for only one vote (my own). I do also think this answer in particular is pretty good.

That said, I do see your points, but nonetheless I don't think having bad answers is a reason to close a question when the question itself is fine. I think most of the answers can be improved by adding details and references, so it would be much more productive to write comments on those answers requesting those improvements rather than hash it out here.


Verdict: the question should be edited to include the details given by the OP in the comments, and the question should not be closed. Feedback about the quality of answers should be given in the comments on those answers.

$\endgroup$
10
  • $\begingroup$ I am not saying that the question is specific to “internal VMs”. I am just saying that OP clearly intends for all of them to be included in the class, and no current answers account for that at all—they answer a different, more specific question. If you believe that the class under consideration can be defined in a way that is both clear and does not invalidate existing answers, please give a definition. $\endgroup$
    – Alexis King Mod
    Commented Jul 31, 2023 at 21:47
  • $\begingroup$ @AlexisKing To be honest, the question is clearer to me than the distinction drawn between "internal" and "non-internal" VMs, and I don't know how that term should be defined. But as I said, if a language can be targeted by third-party languages at all (as the question supposes) then it must be external enough for that to be an option. $\endgroup$
    – kaya3
    Commented Jul 31, 2023 at 21:57
  • $\begingroup$ I don’t think that “if a language can be targeted by third-party languages at all” really restricts the question at all. Sure, it is technically possible to target GHCi bytecode or Racket 3m. You very clearly shouldn’t do this, but it is possible. You may dismiss these as ridiculous, and I’d say that’s essentially fair, but the real issue is that there are lots of implementations that lie somewhere in between (like Lua), and the tradeoffs of targeting them is not adequately covered by any of the answers because they’re completely different from the tradeoffs of targeting the JVM. $\endgroup$
    – Alexis King Mod
    Commented Jul 31, 2023 at 22:01
  • $\begingroup$ On the history tag: I think the response that it was asking for history all along supports the idea that the question was unclear, and given that the question text hasn’t changed that it is still unclear. That was the point that sold me on closing the question at the time. $\endgroup$
    – Michael Homer Mod
    Commented Jul 31, 2023 at 22:01
  • $\begingroup$ As for a definition of the category of VM included by the question, based on the comments it seems clear to me that OP is asking about virtual machines which were designed for a specific other language, as opposed to virtual machines which were specifically designed to be targeted by multiple languages. Here "virtual machine" means "process virtual machine" in Wikipedia's terminology, since this is PLDI and "system virtual machines" aren't relevant here. $\endgroup$
    – kaya3
    Commented Jul 31, 2023 at 22:02
  • $\begingroup$ @MichaelHomer I don't see that the question is specifically asking about history, and therefore it was fair for OP to remove that tag without making an additional edit. I think the tag was originally included to indicate that answers about the decisions made by real languages would be welcome. $\endgroup$
    – kaya3
    Commented Jul 31, 2023 at 22:04
  • $\begingroup$ I do agree that the answers are a separate matter and only relevant as far as the prospect of editing the question to match. The votes are not strong support for their being right, though; lots of poor answers have many votes, especially on questions that hit HNQ. $\endgroup$
    – Michael Homer Mod
    Commented Jul 31, 2023 at 22:06
  • 1
    $\begingroup$ @kaya3-supportthestrike Of course, I am already assuming the definition of VM being used is the one you mention; anything else would be absurd. But that category is still much too broad. Again, without further restrictions, it includes things like Racket 3m and the GHCi bytecode interpreter. A question lumping those in with the JVM cannot receive comprehensive answers because it is asking about a truly vast category of implementations, many of which have little resemblance to one another. $\endgroup$
    – Alexis King Mod
    Commented Jul 31, 2023 at 22:07
  • $\begingroup$ I think I would be okay with "why target the bytecode of a documented existing VM rather than designing a new bytecode specification?", but then it seems trivial. $\endgroup$ Commented Aug 1, 2023 at 2:15
  • $\begingroup$ @KarlKnechtel I don't think it seems trivial, there are decent reasons for both options, and different languages do choose each option. To be honest, I don't see much difference between your phrasing and the OP's phrasing ─ the same way that "targeting the x86 architecture" vs. "targeting x86 assembly" are practically synonymous ─ and it goes without saying that one would probably not consider targeting an undocumented third-party VM or bytecode language. That said, if your phrasing makes sense to more people then it could be proposed as an edit to the original question. $\endgroup$
    – kaya3
    Commented Aug 1, 2023 at 10:28
-2
$\begingroup$

When there are cases like this where a question is closed and re-opened but there are lots of positive votes for both questions and answers I would always err on the side of keeping it open.

The question and answers have attracted significant votes by the community and whatever people on meta might think about upholding quality that ought to count for something.

(Some might even view it as an abuse of privilege to forceably close a question against that pressure.)

These cases are relatively rare so I think it is also not a case of one bad apple spoiling the whole batch.


Better answers may be possible but the answers do not strike me as being completely without value.

I disagree with the "I do not see any path to salvaging this question,". If @Alexis is correct and the question is being interpreted in multiple ways then it would be helpful to the original poster to point those out and ask them to clearly select which interpretation was the one they intended.

Hopefully this deliberation has not caused the OP to abandon the question or worse scared them away completely.

$\endgroup$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .