<p>A practical example of this is the Tic Tac Toe computer made out of Tinker Toys at the Boston Science Museum (originally made by a team of MIT students).  Of course, this is much simpler than Microsoft Word.</p>

<p><a href="http://www.rci.rutgers.edu/~cfs/472_html/Intro/TinkertoyComputer/TinkerToy.html">Here</a> is a 1989 article from Scientific American describing it.</p>

<p>There have also been Turing machines made out of <a href="http://www.legoturingmachine.org/">legos</a> (this cheats a bit because it uses electricity---indeed a computer---for movement, but I think the design could be modified to avoid this) <a href="http://hackaday.com/2011/03/25/mechanical-turing-machine-can-compute-anything-slowly/">scrap metal</a>, and more.</p>

CC BY-SA 3.0
2012-10-31T21:09:12.673Z
I enjoyed the article and the lego machine, thanks.
Alex Nye
CC BY-SA 3.0
2012-10-31T12:37:06.507Z
2012-10-31T12:43:07.350Z
2012-10-31T12:43:07.350Z
SamM
<p>Trying to address specifically your example of creating an editor in hardware, there was an early experimental computer built which implemented both the operating system and the editor entirely in hardware. Later the editor was replaced with software, which substantially reduced the hardware needed. This was described in a book on computer architecture and history. Unfortunately I've forgotten the name and haven't found the keywords to track down the original source.</p>

CC BY-SA 3.0
2012-11-03T21:31:48.543Z
2012-11-03T21:31:48.543Z
Bill Simpson
<p>Yes.</p>
<p>In fact, I think a tougher question might be: can any program be implemented <em>non</em>-mechanically?</p>

CC BY-SA 4.0
2023-01-20T14:49:24.190Z
2023-01-20T14:49:24.190Z
Trev
<p>Yes, it is. Here's how you do it: </p>

<p>You can compile basically any program you like to circuits. See for instance the work of Dan Ghica and his collaborators on the Geometry of Synthesis, which shows how to compile programs into circuits.</p>

<ol>
<li>Dan R. Ghica. <a href="http://www.cs.bham.ac.uk/~drg/papers/popl07x.pdf">Geometry of Synthesis: A structured approach to VLSI design</a></li>
<li>Dan R. Ghica, Alex Smith. <a href="http://www.cs.bham.ac.uk/~drg/papers/mfps10.pdf">Geometry of Synthesis II: From Games to Delay-Insensitive Circuits</a>  </li>
<li>Dan R. Ghica, Alex Smith. <a href="http://www.cs.bham.ac.uk/~drg/papers/popl11.pdf">Geometry of Synthesis III: Resource management through type inference.</a></li>
<li>Dan R. Ghica, Alex Smith, Satnam Singh. <a href="http://www.cs.bham.ac.uk/~drg/papers/icfp11.pdf">Geometry of synthesis IV: compiling affine recursion into static hardware.</a> </li>
</ol>

<p>Circuits then turn out to reappear over and over in engineering. John Baez gives a big table of analogies of concepts, and works out a lot of connections, in This Week's Finds 288-296. So the circuit diagrams Dan's compiler generates could be instantiated as mechanical or hydraulic systems, if you really wanted to! </p>

<pre><code>╔══════════════════════════════════════════════════════════════╗
║                 displacement  flow      momentum     effort  ║
╠══════════════════════════════════════════════════════════════╣
║ Mechanics      position      velocity  momentum     force    ║
║ (translation)                                                ║
║                                                              ║
║ Mechanics      angle         angular   angular      torque   ║
║ (rotation)                   velocity  momentum              ║
║                                                              ║
║ Electronics    charge        current   flux         voltage  ║
║                                        linkage               ║
║                                                              ║
║ Hydraulics     volume        flow      pressure     pressure ║
║                                        momentum              ║
╚══════════════════════════════════════════════════════════════╝
</code></pre>

<ol>
<li><a href="http://math.ucr.edu/home/baez/week288.html">http://math.ucr.edu/home/baez/week288.html</a></li>
<li><a href="http://math.ucr.edu/home/baez/week289.html">http://math.ucr.edu/home/baez/week289.html</a></li>
<li><a href="http://math.ucr.edu/home/baez/week290.html">http://math.ucr.edu/home/baez/week290.html</a></li>
<li><a href="http://math.ucr.edu/home/baez/week291.html">http://math.ucr.edu/home/baez/week291.html</a> </li>
<li><a href="http://math.ucr.edu/home/baez/week294.html">http://math.ucr.edu/home/baez/week294.html</a></li>
<li><a href="http://math.ucr.edu/home/baez/week296.html">http://math.ucr.edu/home/baez/week296.html</a></li>
</ol>

CC BY-SA 3.0
2012-10-31T17:37:23.067Z
Corollary: software patents make no sense.
András Salamon
CC BY-SA 3.0
2012-10-31T21:08:42.127Z
Fantastic answer for a question I barely knew how to ask.  Thanks for the added chart!
Alex Nye
CC BY-SA 3.0
2012-10-31T08:16:42.930Z
2012-11-01T08:10:56.207Z
2012-11-01T08:10:56.207Z
Neel Krishnaswami
<p>Is it possible to build a single purpose (non Turing complete) mechanical implementation of say, Microsoft Word?  Is it possible to implement such things as iterators, first-order functions, the whole gamut of programming techniques?  Could gears and other mechanical parts represent data structures or even program objects?  At a certain point does this necessitate building a general purpose Turing-equivalent machine, or can each function, variable, etc, have its own unique mechanical construct in the form of flywheels and/or gears, ratchets, what have you?  In summary I wonder if any given piece of software on a standard computer could be compiled to a mechanical blueprint.</p>

CC BY-SA 3.0
2012-11-04T04:07:11.360Z
I think, something that runs Microsoft Word doesn't even need to run on a Turing Machine, since all procedures in Word should be known to (provably) terminate (except if there is a bug ofc), aside from the main event loop.
Realz Slaw
CC BY-SA 3.0
2012-11-05T07:13:10.403Z
[Yes sir](http://www.youtube.com/watch?v=E3keLeMwfHY)!
Pratik Deoghare
CC BY-SA 3.0
2012-11-08T13:35:40.630Z
If this is possible - which seems likely - then it should be possible to create a non-turing-complete machine that acts as a compiler, creating blueprints for other machines from source code. Machines which may or may not themselves be turing complete.
Nick Johnson
CC BY-SA 3.0
2015-12-11T08:56:47.593Z
@Realz Slaw: not if you include I/O, VBA macros, or extensions.For instance, I doubt Word would complain if you fed it an infinite Word document. It's probably the underlying OS that would reach a limit.
reinierpost
CC BY-SA 3.0
2015-12-11T14:39:39.353Z
@reinierpost but each routine does not need to be turing complete; they would either provably terminate or provably not. I.e if you fed it an infinite document, it would provably not terminate. My point was that most programs that we make do not have to use a Turing complete language, because we can limit it to programs that *we* can prove terminates, given non-infinite data, and does not terminate if given infinite data; and if you can do this, there is no issue with the Halting Problem. TLDR; if you can't prove your routines terminate or not, you are a terrible programmer.
Realz Slaw
CC BY-SA 3.0
2015-12-14T13:42:53.843Z
@Realz Slaw: I see your point and you're probably more or less correct when it comes to what you call the *routines*: built-in functions executed in response to use input (such as selecting a menu item); but at the same time, Office programs are programmable ("extensible") using a Turing-complete programming language (e.g. VBA or a.NET language), which means it is not possible to prove whether all responses to user input always terminate, even if this is the case for all built-in primitives.
reinierpost
CC BY-SA 3.0
2015-12-14T14:22:13.900Z
@reinierpost in my analogy, "VBA" doesn't need to be Turing-complete either; in other words, it should be a version of "VBA" that the programmer knows if it terminates or knows it does not, based on the input, in the same way the original programmer does. This does not have to be a skill per se, one can design a language that forces this, see [epigram](https://en.wikipedia.org/wiki/Epigram_(programming_language)) for example.
Realz Slaw
CC BY-SA 3.0
2015-12-14T15:03:00.420Z
@Realz Slaw: It depends on how faithfully you want to reproduce Microsoft Word.
reinierpost
<computability><pl.programming-languages><machine-models><ar.hardware-architecture>
Can any program be implemented mechanically?
Alex Nye
# Can any program be implemented mechanically?

(Asked by: username_0 on 2012-10-30)

Is it possible to build a single purpose (non Turing complete) mechanical implementation of say, Microsoft Word? Is it possible to implement such things as iterators, first-order functions, the whole gamut of programming techniques? Could gears and other mechanical parts represent data structures or even program objects? At a certain point does this necessitate building a general purpose Turing-equivalent machine, or can each function, variable, etc, have its own unique mechanical construct in the form of flywheels and/or gears, ratchets, what have you? In summary I wonder if any given piece of software on a standard computer could be compiled to a mechanical blueprint.

**Tags:** computability, pl.programming-languages, machine-models, ar.hardware-architecture

> **Comments:**
> **username_1**: I think, something that runs Microsoft Word doesn't even need to run on a Turing Machine, since all procedures in Word should be known to (provably) terminate (except if there is a bug ofc), aside from the main event loop.  
> **username_2**: [Yes sir](http://www.youtube.com/watch?v=E3keLeMwfHY)!  
> **username_3**: If this is possible - which seems likely - then it should be possible to create a non-turing-complete machine that acts as a compiler, creating blueprints for other machines from source code. Machines which may or may not themselves be turing complete.  
> **username_4**: @username_1: not if you include I/O, VBA macros, or extensions.For instance, I doubt Word would complain if you fed it an infinite Word document. It's probably the underlying OS that would reach a limit.  
> **username_1**: @username_4 but each routine does not need to be turing complete; they would either provably terminate or provably not. I.e if you fed it an infinite document, it would provably not terminate. My point was that most programs that we make do not have to use a Turing complete language, because we can limit it to programs that *we* can prove terminates, given non-infinite data, and does not terminate if given infinite data; and if you can do this, there is no issue with the Halting Problem. TLDR; if you can't prove your routines terminate or not, you are a terrible programmer.  
> **username_4**: @username_1: I see your point and you're probably more or less correct when it comes to what you call the *routines*: built-in functions executed in response to use input (such as selecting a menu item); but at the same time, Office programs are programmable ("extensible") using a Turing-complete programming language (e.g. VBA or a.NET language), which means it is not possible to prove whether all responses to user input always terminate, even if this is the case for all built-in primitives.  
> **username_1**: @username_4 in my analogy, "VBA" doesn't need to be Turing-complete either; in other words, it should be a version of "VBA" that the programmer knows if it terminates or knows it does not, based on the input, in the same way the original programmer does. This does not have to be a skill per se, one can design a language that forces this, see [epigram](https://en.wikipedia.org/wiki/Epigram_(programming_language)) for example.  
> **username_4**: @username_1: It depends on how faithfully you want to reproduce Microsoft Word.  

---

## 4 answers

### Answer by username_8 on 2012-10-31. Score: 25 | Accepted answer

Yes, it is. Here's how you do it: 
You can compile basically any program you like to circuits. See for instance the work of Dan Ghica and his collaborators on the Geometry of Synthesis, which shows how to compile programs into circuits.

Dan R. Ghica. Geometry of Synthesis: A structured approach to VLSI design
Dan R. Ghica, Alex Smith. Geometry of Synthesis II: From Games to Delay-Insensitive Circuits 
Dan R. Ghica, Alex Smith. Geometry of Synthesis III: Resource management through type inference.
Dan R. Ghica, Alex Smith, Satnam Singh. Geometry of synthesis IV: compiling affine recursion into static hardware. 

Circuits then turn out to reappear over and over in engineering. John Baez gives a big table of analogies of concepts, and works out a lot of connections, in This Week's Finds 288-296. So the circuit diagrams Dan's compiler generates could be instantiated as mechanical or hydraulic systems, if you really wanted to! 
╔══════════════════════════════════════════════════════════════╗
║                 displacement  flow      momentum     effort  ║
╠══════════════════════════════════════════════════════════════╣
║ Mechanics      position      velocity  momentum     force    ║
║ (translation)                                                ║
║                                                              ║
║ Mechanics      angle         angular   angular      torque   ║
║ (rotation)                   velocity  momentum              ║
║                                                              ║
║ Electronics    charge        current   flux         voltage  ║
║                                        linkage               ║
║                                                              ║
║ Hydraulics     volume        flow      pressure     pressure ║
║                                        momentum              ║
╚══════════════════════════════════════════════════════════════╝


http://math.ucr.edu/home/baez/week288.html
http://math.ucr.edu/home/baez/week289.html
http://math.ucr.edu/home/baez/week290.html
http://math.ucr.edu/home/baez/week291.html 
http://math.ucr.edu/home/baez/week294.html
http://math.ucr.edu/home/baez/week296.html

> **Comments:**
> **username_9**: Corollary: software patents make no sense.  
> **username_0**: Fantastic answer for a question I barely knew how to ask.  Thanks for the added chart!  

---

### Answer by username_5 on 2012-10-31. Score: 5

A practical example of this is the Tic Tac Toe computer made out of Tinker Toys at the Boston Science Museum (originally made by a team of MIT students). Of course, this is much simpler than Microsoft Word.

[Here](http://www.rci.rutgers.edu/~cfs/472_html/Intro/TinkertoyComputer/TinkerToy.html) is a 1989 article from Scientific American describing it.

There have also been Turing machines made out of [legos](http://www.legoturingmachine.org/) (this cheats a bit because it uses electricity---indeed a computer---for movement, but I think the design could be modified to avoid this) [scrap metal](http://hackaday.com/2011/03/25/mechanical-turing-machine-can-compute-anything-slowly/), and more.

> **Comments:**
> **username_0**: I enjoyed the article and the lego machine, thanks.  

---

### Answer by username_6 on 2012-11-03. Score: 1

Trying to address specifically your example of creating an editor in hardware, there was an early experimental computer built which implemented both the operating system and the editor entirely in hardware. Later the editor was replaced with software, which substantially reduced the hardware needed. This was described in a book on computer architecture and history. Unfortunately I've forgotten the name and haven't found the keywords to track down the original source.


---

### Answer by username_7 on 2023-01-20. Score: -3

Yes.

In fact, I think a tougher question might be: can any program be implemented *non*-mechanically?


---

