20
$\begingroup$

As of today, the [pros-cons] tag has officially been burninated, but we haven’t yet made any decisions about whether pros/cons questions are actually on topic. This has been discussed to some extent in the past, but there did not seem to be any real consensus. Currently, these questions comprise a substantial portion of our site, so ruling them off-topic would appear to be a rather radical move. If we extend our consideration to language design questions more broadly, it seems like it would be patently absurd to call something included in our site name out of scope! However, I would like to make the following case:

  • Open-ended language design questions attract poor answers.

    When people ask questions like “what is the best approach” or “what are the pros and cons of this feature,” it is difficult to evaluate whether answers are even correct. It is not hard to find arguments over typing discipline on the internet, and many claims are easily tossed around, but these claims infamously fail to replicate when studied. Voting degrades to a popularity contest.

  • Uncritically allowing these questions provides the wrong signal.

    Our preponderance of poorly-scoped language design questions provides the impression that language design is largely a matter of personal experience and learned wisdom. However, this is simply not true. Programming language design and implementation is a discipline of expertise that can be learned. We should encourage participation of hobbyists and learners, but we should be exceedingly cautious about amplifying genuinely incorrect information.

  • Our best language design questions can easily be reframed to be more focused and more useful.

    I am not proposing a mass removal of what currently makes up the majority of our site content; quite the opposite. I am suggesting that we identify what’s already working well, make it more explicit, and codify it, and I think doing this will improve our existing questions and answers.

A guiding principle here that I would like to make overwhelmingly clear is that we should always strive to preserve good content. Any policy that would make the good content we currently have off-topic is not a good policy. Therefore, I want to make the case that we can narrow our scope in a way that benefits everyone, without losing what we have along the way.

The dangers of a lack of focus

Discussions of programming languages on the internet are infamously caustic. Programmers have a dizzying number of opinions about what makes programming languages good or bad, regardless of their programming languages expertise. Debates usually cover topics such as “readability”, “expressiveness”, “safety”, “efficiency”, “simplicity”, and “scalability”, but these terms are rarely defined. We have already attracted some answers that make arguments of this flavor. Here are a few examples:

  • This answer makes the case that chained comparison operators are “difficult to understand, especially if you are reading someone else’s code.” However, a commenter on the answer says “I would argue the opposite. […] For me it’s pretty obvious what it means.” Who is right? Most likely both of them, as they aren’t actually in contradiction if we restrict their statements to their subjective experiences.

  • This question attracted a staggering number of lengthy comment discussions, two of which had to be moved to chat by a moderator. And for what? The question itself could be a perfectly well-scoped, objective question—what do you lose if you restrict the scope of C-style UB?—but the presence of “pros and cons” in the title serves only to make it sound as if there is some debate to be had.

  • This answer is essentially a just-so story. It sounds plausible enough, and it is very highly voted, but there is really no evidence whatsoever that it is true. If the question were refocused as a history question, these kinds of answers would be subject to significantly more scrutiny, and I think that would be a good thing.

  • This answer is, frankly, just plain wrong. But it currently sits at +12, and it is accepted. Why? One problem is perhaps a lack of experts who could discern that the answer is incorrect. But another is that we do not have a culture of expecting answers to be well-supported (by either references or personal experience), so we are unable to distinguish answers that sound right from ones that actually are.

Allowing highly-voted yet incorrect content to proliferate on our site is extremely dangerous. It gives the impression that we are simply not very serious about what we are doing, and it makes us unlikely to attract and retain genuine subject-matter experts. This is a real problem in the history of online programming languages communities: so many programmers have such strong (yet ultimately ill-informed) opinions that it becomes too tiresome to argue, and experts retreat to more closed spaces that they can more effectively moderate.

In an ideal world, we would simply have so many experts that incorrect content would be reliably downvoted, but this is difficult to achieve in practice for many reasons. What we can do instead is create policies that make it easier to discern good content from poor content, and that allow non-experts to be more informed voters.

Turning unfocused questions into focused ones

I’d like to now take a look at a few case studies of how I think we can preserve good content by narrowing questions’ scope. I want to make the case that this can actually improve these questions in the process, making our good content even better.

Case 1: Introducing [history] and literature survey questions

As a case study, let’s consider Why do most languages use the same token for `EndIf`, `EndWhile`, `EndFunction` and `EndStructure`?, which is currently quite open-ended. Several of its answers are unsupported post-hoc rationalizations: maybe they’re true, maybe they’re not, we can’t know. However, it also has a number of very good answers that go into some of the history of the subject under discussion, and I think this is an ideal way to make this question more objective.

I therefore propose introducing a tag and making this question a history question. I also propose making more general “literature survey”-type question on-topic: questions that are not about history per se, but are still a request for real, existing examples, whether of language projects or discussions in blogs, forums, or academic literature. We could focus numerous other questions in one of these ways:

I could list many, many more, but I suspect this is sufficient to make my point. The idea here is that we don’t want people to propose their own personal theories—unless, of course, they are a primary source! But we do still want to gather a number of different perspectives, and a look into the history or literature is a fantastic way to do that.

Case 2: Introducing human–computer interaction questions

Next, let’s consider What are the downsides of supporting chained comparison operators? This question sounds incredibly subjective at first glance, but it actually attracted a remarkably good answer. The key thing that, to me, makes this answer so great is that it is based on more than just personal experience—it puts some actual numbers to the topic being discussed:

The reason I say Python got this wrong is that empirically, a lot of people are confused about it. Chained comparisons are one of the most recurring Python questions on Stack Overflow; currently, the canonical question has 145 upvotes and 52 duplicates.

This is an amazingly good way to answer a question like this, and it sets a gold standard that we should all strive for when it comes to answering questions about language usability. It also hints that there really are alternatives to answering language design questions based purely on vibes—there are real, systematic approaches that can do much better.

Indeed, the field of human–computer interaction (HCI) is all about understanding the complex, fuzzy space that arises between humans and machines. HCI has disciplined strategies and approaches to analyzing what it means for something to be “more usable”, and this lens can help to add rigor to questions that are fundamentally about human factors. Here’s a list of question that I think could be improved using this framing:

It’s worth noting that, although rigorous studies and hard empirical evidence are obviously the gold standard for answering these sorts of questions, it would be unreasonable to expect it for all answers. The amount of empirical research that has been done on programming language usability is minimal, and it is infamously challenging to control for the relevant confounding factors. However, even if rigorous studies are not available, we can expect appeals to case studies, external evidence, existing discussions, and expert opinions, and I believe we should. Moreover, several of the questions I linked do concern topics upon which studies have actually been conducted, and it would be amazing to get answers that cite them.

Essentially, we want to encourage answers that step outside the perspective of the answerer and try to provide a broader perspective. This can be informed by the answerer’s personal experiences, but it probably should not be wholly determined by them.

Case 3: Language design questions that are really implementation questions

Finally, I want to look at Pros and cons of "anything-can-happen" UB versus allowing particular deviations from sequential program execution. As mentioned above, I think this question can be significantly improved in a fairly simple, uninvasive way: edit them to make it clear that they are asking a technical question. This one currently asks

What advantages are there to the currently-popular approach of characterizing all executions as either fully specified or "anything can happen" UB?

but it could easily be tweaked to instead ask this:

What prevents C and C++ from constraining what can happen if a program invokes undefined behavior?

The question really doesn’t have to change much otherwise, but this immediately converts a subjective question to an objective one. The existing answers already focus on the objective question, anyway, so absolutely nothing is lost. This is just a net good, and I suspect the reason that these questions are currently phrased as pros/cons questions is simply that we currently have so many of them!

Here is a non-exhaustive list of questions that I think could be improved in this way:

Again, I don’t expect this to be particularly disruptive, but the rephrasing would help to scope the question, and being able to phrase questions this way is a good exercise to demonstrate that the question is objectively answerable.

What to do with everything else

I believe that the above categories I have listed cover the vast majority of our existing language design content. I think virtually all of our old questions that are worth preserving could be reclassified in this way. This paves the way for us to restrict our scope for questions that don’t fit into these categories, and I think we ought to take some inspiration from Software Engineering’s help center:

Some questions, even if they appear to fit into one of the above categories, may still be off-topic:

[…]

The linked question gives a slightly lengthier list of examples:

Questions of the following form are often closed as too broad:

  1. "Review My Design"
  2. "What is the Best Practice?"
  3. "Will my approach work? Is it viable?"
  4. "Is this the correct / preferred / accepted / most popular / better way?"
  5. "What could go wrong?"
  6. "Tell me the name of this thing so that I can Google it."

How can I avoid the problems associated with these kinds of questions so that my post isn't closed as Too Broad?

I think this is a pretty good starting point, though I would adapt it a little to better suit PLDI’s needs. In particular, I might suggest the following phrasing for the bullet in our help center:

Questions asking “what are the pros and cons of this language feature” without providing enough context for an impartial evaluation of the tradeoffs.

Obviously, I am happy to consider alternative wordings, or even alternative scopes! But this seems like a good place to start to me.

A passionate request for feedback

This question articulates my vision for what I believe PLDI can be and how I believe we can best move in that direction. I want to grow this community into a wonderful, respected resource for people interested in programming languages, and I believe doing that requires some earnest reflection on what we expect of our fellow community members to. However, this is only my vision, and what is most important is that we can find a set of values we can all agree upon. Therefore, I would like to hear any and all opinions that people may have about any aspect of this proposal.

Though we are small, we have already accrued an impressive number of exceptionally great questions and answers. I have a great deal of respect for everyone who has participated thus far, so please: chime in! If you think what I have proposed is against everything you stand for, tell me! Let’s find something we can all commit to upholding.

$\endgroup$
9
  • 1
    $\begingroup$ Instead of a generic [human-computer-interactions] I would suggest to name the tag [developer-experience], since those are the humans whose interactions with the language we are interested in $\endgroup$
    – Bergi
    Commented Jul 20, 2023 at 5:18
  • $\begingroup$ I personally dislike a [survey] tag, as that is basically the definition of opinion-based. $\endgroup$
    – CPlus
    Commented Jul 20, 2023 at 17:51
  • $\begingroup$ I agree developer experience is a better name. $\endgroup$ Commented Jul 20, 2023 at 22:52
  • 1
    $\begingroup$ [survey] is not the same as opinion based. opinions vary by individuals whereas a survey would be of different language implementations which are far fewer in number and frequently have features in common. $\endgroup$ Commented Jul 20, 2023 at 22:53
  • $\begingroup$ I have experimentally tagged my newest question with [history] $\endgroup$
    – Seggan
    Commented Jul 21, 2023 at 14:15
  • 1
    $\begingroup$ I'm not sure that that tag should apply. Your question seems to ask an objective question. It is not a survey of current impementations though that could feature in the answer. I don't feel it is about the history of a particular language or set of languages either. Though I note that history does not have any explanatory text yet to say how it should be used. $\endgroup$ Commented Jul 21, 2023 at 15:28
  • $\begingroup$ langdev.stackexchange.com/questions/2498/… this looks like a clear survey question. $\endgroup$ Commented Jul 21, 2023 at 15:31
  • $\begingroup$ I have revised this proposal to remove the [survey] and [human-computer-interaction] tags, since I think people have rightfully pointed out that such things are not useful as tags. But I think they are still useful as topics, so the proposal is mostly the same. $\endgroup$
    – Alexis King Mod
    Commented Jul 21, 2023 at 22:59
  • $\begingroup$ At first I agreed that the 'Why do some programming languages choose to have a dedicated keyword for elseif instead of using else + if like in C?" question "could be improved" by tweaking it to ask about the technical issue. But then I thought, this isn't natural; you wouldn't think to ask about technical issues if you didn't already know about the one specific technical issue that is addressed by the choice. $\endgroup$ Commented Jul 25, 2023 at 7:29

4 Answers 4

4
$\begingroup$

There is a quite a lot to break down there. It should probably be several different meta questions.

I like the suggested history and survey tags.

Should we be more aggressive with suggested edits to questions (and answers)? The suggestion part being key. It is most unpleasant to be edited wrongly.

That does mean a lot of moderation work however.

Dealing with highly voted wrong answers is hard. I don't think the stack overflow system allows for that very well.

Perhpas you can add a comment or a moderator sledgehammer edit to add a title "this answer is popular but considered wrong by experts in this community - see XYZ"

The real concern is your point:

"This is a real problem in the history of online programming languages communities: so many programmers have such strong (yet ultimately ill-informed) opinions that it becomes too tiresome to argue, and experts retreat to more closed spaces that they can more effectively moderate."

I feel like https://ai.stackexchange.com is at risk of going that way. We may be saved by being less popular and more niche despite "writing a programming language" being a thing lots of less experienced developers do as part of their journey.

Another way to combat that is with canonical question and answers maybe. But again this places a burden on experts to write them in the first place rather than say writing a blog post or an academic paper.

If we were to just harvest and curate such efforts you could argue we might as well be a search engine or an LLM rather than an effective SE community.

$\endgroup$
1
  • $\begingroup$ I feel like any survey question would be opinion-based. $\endgroup$
    – CPlus
    Commented Oct 18, 2023 at 1:41
3
$\begingroup$

It would be good to establish a norm of more focused questions like this. That would also result in more questions as the overly-broad ones were able to air their constituent facets individually.

It would also be helpful for giving a stronger impression of seriousness to visitors. I know that there's been some doubt expressed about whether this is a real issue, and whether it really will put people off, but—as Alexis said here, and in other conversations—it is, and it will (and it does and it has). At the least, both of us have seen it.

That doesn't mean that the range of subjects the site covers is wrong, or that people are doing it wrong, but that by consciously tweaking the structure of questions and thus the sorts of answers they lead to we can set people up for success. The very broad questions don't do that well, and they end up with lots of very different answers crammed into them, user confusion, and still giving a confounding view of the site.

There is also a significant strain in the PL community that feels that "programming languages" means "type theory", and maybe stretches to compiler optimisation, and that's it—I don't want this site to be that. There is a continuum that spans theory and applied PL, another that spans academic, industrial, and hobbyist work, and another spanning design, implementation, and environs. There's scope for the Stack Exchange model to create a constructive mixed community that has been hard to find elsewhere, and to document knowledge that exists, but the site needs to attract and retain the full range of users for that to work.

I want to be able to make use of the expertise we have here, which is pretty wide-reaching precisely because there are many users outside of the "PL as type theory" milieu — for example, we have expertise here in 2D languages that just doesn't exist at all in academic literature, while concatenative languages are another area that has very little work of that sort. Esoteric languages are often pure explorations of a particular point in the design space that can be useful to inform wider language-design work. Similarly, we can all learn from people with domain expertise in other parts of the field, and it's great to draw more of them in. This blending is the real promise of the site, and picking a more constructive scope for each question is going to help that.

I have a few points to address specifically. These are somewhat recapping discussions from the chat.

A tag

This would be great, and gives a useful focus to what I think can be useful questions about how and why things ended up as they did. Answers should be required to address the concrete history being asked about, and ideally have some backing references — though sometimes we'll be lucky enough to have primary-source answers, which are great too.

A tag

Survey questions have been controversial and suggested to be unsuited for the Stack Exchange model. I think it's plausible that there is a constructive scope for them on this site, for providing concrete instances of design or implementation patterns. To be useful, the question would need to circumscribe the PL technique being asked about and answers would identify previous instances.

This would be a meta-tag that doesn't describe what the question is "about", so it starts out with points against it, but several sites on the network make healthy use of tags like this to specify rules for the kinds of answer that are expected. We don't necessarily need this, but I don't think we should dismiss the idea either. The associated rule would be something like

Answers to this question must identify existing notable programming languages and how they incorporate the subject of the question. Speculative concepts and theories will be deleted.

It's possible that this isn't the best name for the tag, even though it's the most accurate one, because people don't know and won't learn what a survey is. I don't think fits either, because it wouldn't be purely literary. The tag excerpt & wiki, and enforcement, should be able to stop it being treated as an opinion poll.

Human-computer-interaction questions

I am a big fan of taking account of human-factors elements of language design. I don't want to call these , because that's an enormous field of its own too, but questions explicitly directed at this area would be good. There are actually multiple dimensions within this: ergonomics, effectiveness, and programming interfaces all have good questions, and sometimes there can be the same topics addressed from multiple avenues. The static-or-dynamic typing question is one example of that: there are studies like the Hanenberg one you cited about how effective and efficient users are with one or the other, but also those focusing on the programmer experience, or on tooling that is enabled by type annotations. Questions about all of those things should be encouraged.

While answers should provide evidence rather than reckons, there are many forms that evidence can take, and we should be open to all of them. It's also the case that in many real-world situations the evidence is contradictory or contingent on other circumstances. We should expect better than guesswork, though.

Implementation questions masquerading as design

There are definitely plenty of questions that ask both, which is probably too broad. Often there are both design and implementation elements that are worth asking about: the static typing question again has meaningful parts on both sides. This part I'm probably the least convinced about—I think there are probably some cases, but more of these questions seem to fit into other buckets or can have their scope reigned in without changing the nature of the question.

I'm not keen to force everything into an implementation-shaped box.

Restructuring existing questions

I am uncertain about changing existing questions into these forms. Their current answers mostly won't address the new form of the question — some will, particularly the more comprehensive answers that the goal is preserving — but the thing about these broad questions is that they get lots of answers from different directions. In many cases, there are a couple of comprehensive answers that we definitely want to preserve (and so make the question match), and a lot of others that would no longer be answers to it. When there are two good directions to take the question, this is intractable. Perhaps we would delete them, perhaps they're fine just left there, or perhaps we'd want to historical-lock the old questions and let the (likely multiple) more focused versions emerge separately.

"What are the pros and cons of ..."

This form has been very popular, but is just not a good structure for a question in general. It's inviting lists of ideas labelled "pro" or "con", but that is not how language design works, is a false dichotomy, and doesn't admit the sorts of analysis that actually matter. We've all seen the evident LLM-generated answers to these passing by, but they're not so different.

Most of the time they are really multiple questions in one, that would better be split out as above into different versions for the different dimensions of the question: the history question, the survey question, the human-factors question, the implementation question, etc. Some however might be tightly-scoped enough that dividing them further doesn't help, but the structure of the question just doesn't set the answerer up to succeed.

I don't expect that there will be many questions left after taking a more principled take on them, but if there are some then at the least a better framing is "What are the trade-offs in ...": it explicitly seeks analysis and doesn't force answers into an artificial contrast that may not really exist. It also doesn't push towards the answers that currently end up listing something like "Readability" as both a pro and a con.

However, in most cases I think refocusing the question to what it's really asking about is going to lead to better questions, and more questions, and will also ensure that the asker understands what they're asking about. This shouldn't take on the same memetic form of pick-a-term-and-ask-for-its-tradeoffs, but some real questions about specific concrete problems may genuinely come down to this sort of informed analysis.

Substantiating answers

As well as questions that are too broad, another issue you identified is that there isn't a culture of expecting answers to provide evidence or rationale, and so answers are upvoted without any reason to believe they're true. Some of this is probably due to the nature of questions, where the breadth of them means there's just too much to talk about, and so answers stray outside what they've got support for; this part probably tidies itself up when the questions are more focused.

Others don't fit in this camp, though, and there are even answers that explicitly disclaim any knowledge or backing. We don't need every point to have a citation attached, but we do need something beyond guesses, wishes, and reckons, and we should ask that of our answers and our answerers. In the first instance that is voting from all of us, and careful thought given to our own answers we post.

There are other tools like NAA flags, post notices, and deletion policies, but before resorting to those we can collectively improve things ourselves. Often this will just mean doing a little research before submitting the answer and won't be a big disruption at all.

Personal experience on matters of readily-observable fact, like what features a language provides, or even primary-source comment on implementing some construct, is probably fine, while personal experience on matters of opinion generally won't be. Answers that just disclaim all relevant knowledge on factual questions shouldn't be encouraged. Questions should be posed to invite answers that have substance—again, setting the answerers up for success.


I think we will need further meta posts to sort out details on these things, and whether we really do want to change them, but at the high level getting to more focused questions would be a plus.

$\endgroup$
1
$\begingroup$

This discussion has been open for quite some time now, and it’s gotten some good feedback both here and in chat. This answer is intended to collect what appears to be the general consensus and to suggest some next steps.

Broad support for the tag

People seem to generally agree that a tag is a good idea. Michael Homer writes:

This would be great, and gives a useful focus to what I think can be useful questions about how and why things ended up as they did. Answers should be required to address the concrete history being asked about, and ideally have some backing references — though sometimes we'll be lucky enough to have primary-source answers, which are great too.

This perspective seems fairly representative. Since it seems to be unanimous, I have gone ahead and added a bullet explicitly mentioning history questions as on-topic on the relevant page of our help center.

Moderate support for survey questions, but also some concerns

People generally seem to agree that certain types of survey questions—such as literature survey questions explicitly seeking citations—are a good fit for the site. However, there are definitely some concerns as well. Michael Homer again writes:

Survey questions have been controversial and suggested to be unsuited for the Stack Exchange model. I think it's plausible that there is a constructive scope for them on this site, for providing concrete instances of design or implementation patterns. To be useful, the question would need to circumscribe the PL technique being asked about and answers would identify previous instances.

I agree that we ought to be cautious about these questions, as it is important to make very clear what requirements we expect these questions to uphold. I will commit to posting a followup question on meta to specifically discuss how we want to define those requirements and how we ought to moderate them.

No clear consensus on what to do about existing questions

On the subject of what we should do with existing questions, Michael writes:

I am uncertain about changing existing questions into these forms. Their current answers mostly won't address the new form of the question — some will, particularly the more comprehensive answers that the goal is preserving — but the thing about these broad questions is that they get lots of answers from different directions. In many cases, there are a couple of comprehensive answers that we definitely want to preserve (and so make the question match), and a lot of others that would no longer be answers to it. When there are two good directions to take the question, this is intractable. Perhaps we would delete them, perhaps they're fine just left there, or perhaps we'd want to historical-lock the old questions and let the (likely multiple) more focused versions emerge separately.

Bruce Adams raises some similar questions:

Should we be more aggressive with suggested edits to questions (and answers)? The suggestion part being key. It is most unpleasant to be edited wrongly.

That does mean a lot of moderation work however.

In the case where the question does not invalidate any answers, and they clearly fit the discussed format, people seem to mostly agree that editing them is reasonable. After all, in that case, we’re really just making what was already there more explicit. But we’ll need more meta discussions to decide what to do about existing questions that don’t fit so cleanly into the categories we want to include.

Limited agreement that we should expect more substantiation from answers

Michael writes at quite some length about how we might handle substantiating answers:

As well as questions that are too broad, another issue you identified is that there isn't a culture of expecting answers to provide evidence or rationale, and so answers are upvoted without any reason to believe they're true. Some of this is probably due to the nature of questions, where the breadth of them means there's just too much to talk about, and so answers stray outside what they've got support for; this part probably tidies itself up when the questions are more focused.

Others don't fit in this camp, though, and there are even answers that explicitly disclaim any knowledge or backing. We don't need every point to have a citation attached, but we do need something beyond guesses, wishes, and reckons, and we should ask that of our answers and our answerers. In the first instance that is voting from all of us, and careful thought given to our own answers we post.

There are other tools like NAA flags, post notices, and deletion policies, but before resorting to those we can collectively improve things ourselves. Often this will just mean doing a little research before submitting the answer and won't be a big disruption at all.

Personal experience on matters of readily-observable fact, like what features a language provides, or even primary-source comment on implementing some construct, is probably fine, while personal experience on matters of opinion generally won't be. Answers that just disclaim all relevant knowledge on factual questions shouldn't be encouraged. Questions should be posed to invite answers that have substance—again, setting the answerers up for success.

Bruce also notes that this is a tricky thing to deal with:

Dealing with highly voted wrong answers is hard. I don't think the stack overflow system allows for that very well.

Further discussion is required to decide what precisely to do, but there does seem to be consensus that we ought to hold answers to higher expectations going forward. Comment on answers if you do not think they are sufficiently substantiated, and if other mechanisms (mostly editing and voting) do not resolve the problem, feel free to flag the post, and we can take a look at it and decide what to do.

Next steps

Already, we’ve been continuing to have conversations—both here on meta and in chat—about what we’d like to do to answer some of the questions left open by this discussion. I’ve opened a couple of questions since this one seeking to refine our scope, and they seem to have produced a weak consensus, albeit with some dissent.

Broadly speaking, finding consensus on some of these issues seems challenging given we are still so small. Very often we just don’t have enough people participating on meta to have a healthy number of votes, but that seems okay for now. We can take this slowly and iteratively refine things as the site continues to grow.

$\endgroup$
0
$\begingroup$

I don't have a strong opinion, but some considerations:

If something could be clearly defined, it is not different from it has already existed

The details in language design might be important, but not that important. Many problems are solved in an ad-hoc manner, which may have some annoying consequences, but may not really break anything. As long as it is Turing-complete, people may find workarounds to the deficiencies. Stability is often preferred to improving the details. As a result, one developer of a serious practical language may choose to stick at one design, and live with it for the rest of their life. It would be too slow paced if we depend on them for acquiring the necessary experience. It would cost another developer of another similar language for any feedback of the previous developer's opinion of how it could have been done.

If it's not restricted to serious practical languages, it sounds less clever to require answerers to firstly publish their work as a complete language before posting the answer.

So I don't think it is a good idea to turn a general question that is not already about history to a question about specific or existing languages.

Language design itself is still open-ended

I believe there are still ideas like monads, coroutines, rvalues... not being invented. People would try various ways experimenting how to solve a problem. I myself asked a question, but ended up reinventing "multiple dispatch" and got the question closed. My bad for not doing prior research and / or not formulating the question well. But I don't think it's my bad for thinking about the less common situation. If I don't, there wouldn't be further questions on top of the idea of multiple dispatch.

It may require some thinking about how to make such things fit in the QA format. But even if we rely on outer approval for what has significance and what is esoteric, it's still open ended on the outer part. It could only make us one level worse for being less consistent, like public opinion and commitee. It doesn't really solve anything. The other places don't actually have another standard, so if we make a standard, we actually seem to have better expertise to the eyes.

I think it's difficult to know what is appropriate until we get a good question on this direction. But there are not only technological subsites on SE. There are also something like WorldBuilding. I'm not familiar with their exact rules, but feel one clear idea is more welcome than listing the options there. We may lie somewhere between WorldBuilding and a traditional technological subsite.

Languages are more permissive than the general what-is-best questions

For the question "Spaces and tabs for indentation, which is better?" in other places, it looks like an endless argument. But in PLDI, I suppose the best answer would be: It doesn't matter. It's better you don't add restrictions on that, and give the choice to the programmer. It might be subjective, and trivial, but is not open-ended.

Some questions might be on the borderline, to attract open-ended bad answers without someone making the conclusion. We may need some samples of bad answers to discuss how to deal with them. But if it is that case, the lack of a good answer might be important information to the asker and anyone interested in the topic, as an indication of "doesn't matter" or "do them all". It doesn't look good if we allow the bad answers without an "I didn't find anything better" disclaimer to be the apparently best received answer, but if it happens, I don't think the problem is from the main question body.

$\endgroup$

You must log in to answer this question.

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