Should we rehash Add A Language To A Polyglot?

Question

Add a language to a polyglot was fun while it lasted. However, it's kinda stagnated due to the difficulty of running all the languages. I propose that we repost this challenge, maybe with stricter rules on what types of languages can be used but otherwise exactly the same.

The current consensus on this is that the original poster must consent, however their account's been deleted. Some people have reposted answer-chaining challenges with a different task to complete, however in this case I think the original challenge is perfect.

This wouldn't replace the original, which I understand people are still working on, but rather be a second attempt where more people can try.

Proposed rule changes:

Languages must have a freely downloadable crossplatform implementation that can be run from the command line (feel free to create / set up one yourself). Programs must terminate in less than five seconds.

Thoughts?

Answer 1

I was the original poster of the original challenge, and have had some thoughts about what I'd change if doing it again. (Note: these are only thoughts, not directives or requirements, and it's quite possible that some might make the challenge worse if implemented, but I feel like I should let people know what my ideas in this direction are.)

• The first answer: The choice of language for the first answer can have a big effect on how this sort of polyglot goes. I would suggest writing it in Lua. This is a practical language, which is fairly good for polyglots, and yet is not part of the current polyglot, despite being compatible with almost everything in it. This means that we'd be likely to see different solutions to how to fit a large number of languages together, helping to keep the challenge fresh.

• Ease of editing: One of the stumbling blocks on the original challenge was the use of non-printable characters, which we eventually mostly solved with the help of the test driver script. Like it or not, non-ASCII and non-printable characters are very likely to be involved in a large polyglot eventually, even though some people have problems with, say, the literal ESC character. One possible solution is to ban non-ASCII characters and all whitespace other than space/newline, but I think that would reduce the scope for interesting language combinations (most notably, some languages treat carriage returns as starting a line and some don't, and this difference gives a lot of power when combining languages). I think a better solution would be to have a test driver script in place from the start, allowing people to say "put an ESC character here" and having the driver automatically run the program in every language with the appropriately placed nonprintable.

  This was a particular problem in the original language because a highly control-code-dependent language (V) was added early on – although the original answer didn't need a control code to function, the polyglot would quickly have been stuck in a dead end if the control code wasn't added.

• The task: "Print a number" is a very simple task, which doesn't act as much of a barrier to entry for languages. As a consequence, the polyglot ended up being purely about language syntax, and not about language logic. There are several languages in the original polyglot that aren't powerful enough to do nontrivial programming in, and most of the languages there are esolangs which rely on unusual syntax as their only interesting feature.

  Changing the task to something more complex would be quite a change to the nature of the challenge, and would likely create a smaller polyglot in terms of the number of languages available, but it'd also create one which is in some sense "more interesting" (as well as redressing the balance between practical languages and esolangs – esolangs are easier to fit into a polyglot but practical languages are easier to write nontrivial code in).

  There's also a precedent for using a more complex task when doing the second run of a popular cross-language challenge (I'm thinking of "The Programming Language Quiz" series).

  One issue with changing the task is that you would want the program to halt, and all deterministic halting programs that don't take input are in effect "print this string literal" programs. As such, implementing a more complex task would ideally mean taking input, which is going to make things tricky because not all languages take input the same way.

There's one further issue with restarting the challenge. One of the best resources for test drivers for polyglots is Try It Online!, but @Dennis is no longer around to update it. That means that, unlike the first time the challenge was run, if someone picks a new or unusual language, we can't simplify the driver by installing the language on TIO – either we test it manually or we have to embed an implementation of the language into the driver. Likely the best solution to this is to have two versions of the test driver, one running on TIO and one running on a newer TIO-clone; this would mean each answer would have to be tested in two places, but at least it's only two and not hundreds.

Answer 2

I have long supported making a second run. Due to the answer chaining nature I think the challenge would be very interesting if we pushed it in a different path.

However I don't like the proposed rule changes. If we look first at

Languages must have a freely downloadable crossplatform interpreter that can be run from the command line

I think this is a good idea. Contributing to the polyglot is hard because a lot of the entries are system specific or non-free. However we already had a rule for this in the challenge and it was lifted only after the challenge officially ended. So this doesn't represent an addition only a change

And if we look at the original wording:

As this challenge requires other competitors to post in the same languages you are, you can only use languages with a free implementation (much as though this were a cops-and-robbers contest).

The change does not seem to me to be a positive. Besides the implementation with interpreter which I will assume is unintentional (surely you are not proposing compiled languages to be banned). The existing rules link to a established consensus on how to approach the issue. I think it's better to go with what the community has agreed upon rather than something ad hoc.

The other rule:

Programs must terminate in less than five seconds.

I don't think is an improvement either.

For one I don't think there is a big issue with languages taking more than five seconds to run. To test all 300 odd languages does take a while, but the bulk of that is just because you are running 300 programs in 300 different languages. In order for the test handler to be fast the time limit would have to be very low. Likely below the spin up time on a lot of interpreters and compilers.

A long test time for high numbers is just going to be a reality for the challenge.

On top of that this adds all the ambiguities that come with time limits. What takes 5 seconds on your machine is not the same as what takes 5 seconds on my machine. I mean, even, what takes 5 seconds on my machine isn't always the same.

We could specify it further and try to get it nailed down and clear, but for what. I'm not really convinced that there is anything wrong with the rules as they are that this is fixing.

---

I'm not opposed to rule changes, however the original challenge was fun and worked well. I don't see much reason to change the rules.