Are physical analogs of programming legitimate?

Question

By physical analogs, I mean solutions written via objects in the physical world. Specifically, I am referring to a couple solutions to this challenge (including my own and a couple others).

• Should we allow solutions like this?
• If so, where is the cut off?
  • Should they publish a language specification first?
• If not, why not?

---

TL;DR

I ask because I would like a ruling from the community before posting more domino solutions in case my other solutions aren't as well received. I also think it will be helpful to have distinctions on what is allowed and what isn't. For instance, if someone thought to solve a problem with some set of physical analogs, what criterion should they consider before posting the solution here? On the flip side, what criterion should we point to if we downvote a solution like this?

Answer 1

To be acceptable as a programming language, a digital simulator must exist.

Photos of dominos are great fun and all, but by themselves they don't really meet the definition of programming language. The basic problem with programming languages 'implemented by the physical world' is that the results of running programs cannot be reliably reproduced. They suffer from nondeterminism: the real world is full of noise and a program that's intended to be deterministic may not be. It's impossible to set up dominos in exactly the same configuration and push them with identical force every time; the mechanics may be affected by air currents or vibrations from a passing truck.

Precision in copying the program is also an issue as a program can only be approximately reproduced from a photograph. Are you willing to specify tolerances for domino positions, shapes, and masses; the smoothness of the table; and the local gravitational field?

The only way to fully address these issues is by writing an interpreter on a computer. This also solves the problem of scoring, since the interpreter can use some file format.

Answer 2

Native vs Logical

TL;DR :: logical -> esolangs

I think there is an important distinction to be made between different types of physical analogs. There are Native analogs and there are Logical analogs.

• Native
  • Written in the real world
  • Directly executed in the real world
  • eg Dominoes
• Logical
  • May be written in the real world
  • Executed via logic
  • Not executed in the real world
  • eg Chess

Native

This code has to be executed in the real world or a simulation of the real world. For example, dominoes can get complex and require the real world in order to execute. You can simulate dominoes or you can simulate the real world but these simulations are simplifications. Whereas for Logical analogs you can actually have an exact implementation in the real world.

Logical

These Logical analogs can be written in the real world, but the are not executed in the real world. They are compiled via a series of rules/constraints/assumptions into a sequence of executable steps. What makes this different from Native is that these executable steps could be executed via a normal everyday interpreter and are independent of the real world. I think we should encourage Logical analog solutions to create a normal esolang.

Example

Lets make a physical analog from tic-tac-toe. Rules:

• The opponent is a perfect logician
  • If two squares are equally strategic, he will choose the lower and then the left most
• A win is equivalent to ...
• A loss is equivalent to ...
• A cats game is a ...
• Input is given by ...

Is this Native or Logical? The first bullet point tell us that the logician is the compiler, he executes the program and not the real world, so this is a Logical analog. Since the logicians steps have to be precisely laid out, we could write a Python interpreter to act as the logician and run the code for us. Instead of taking input and giving output in the real world, it is much easier to create a normal esolang for tic-tac-toe. Give the interpreter input like this:

 a | b | c 
---+---+---
 d | e | f 
---+---+---
 g | h | i 

and Python will execute the logical steps and return some output.

Conclusion

Logical analogs should be implemented as esolangs. It makes verification easier and it just makes sense. Thus the set of problematic physical analogs has been reduced to Native ones.

Answer 3

Dominoes

It seems to me that it would be a bummer to discard all of mechanical computing because it might be problematic. I personally am a huge fan, but I can't think of a general argument. So here is a case for allowing Domino solutions. Note I don't think it is my goal to dot i's and cross t's, I am trying to make a case that domino computing could meet the concerns that have been raised (ie not necessarily how we should meet those concerns).

Problems to Address

I propose that if the following issues are adequately addressed, domino solutions are valid.

• Sharing :: how do we share domino layouts so that they can be reproduced?
• Scoring :: how do we calculate bytes for a domino solution?
• Testing :: how do we verify solutions?

Sharing

This isn't rocket science, setting up dominoes and knocking them over is literally something a child can do. While we could provide distances, angles, weights and details until we are blue in the face; I propose that a clear photo (or set of photos) that unambiguously displays how the dominoes line up is sufficient for someone to replicate the layout.

Scoring

Scoring dominoes in terms of bytes is currently not doable. But consider:

1. Minecraft didn't have a standard way of measuring bytes until recently
   • there is precedence
   • someone might invent a reasonable byte conversion
2. There is a micro-competition within each language
   • the shortest answer for each language de facto wins
   • dominoes can compete with dominoes
3. We are trying to document best solutions in every language
   • this includes esoteric/golfing solutions
   • domino solutions are a similar novelty
4. Number of tiles is unambiguous

Testing

Vids or it didn't happen! It seems like it would be reasonable for domino solutions to include video confirmation of the test cases. Given the effort involved in creating a video, this requirement should be flexible for trivial solutions. The reason we have test cases is to verify that a solution probably works. So if there is video evidence of a solution working for the test cases, the solution probably works.

Conclusion

Domino solutions are shareable, score-able, and testable so they should be considered valid.