Impossible Machines: A Declarative Programming Prototype for the Physical World (Show HN)

Impossible Machines is a browser prototype that applies declarative programming to the physical world: the user describes the behavior a mechanism should produce, and the system generates a mechanism that produces it. It was submitted to Hacker News as a Show HN post by @bhaprayan and reached 36 points and 9 comments at the time this page was scraped.

What Impossible Machines actually does

Impossible Machines is a design canvas where desired physical outcomes are specified first and the mechanical design is derived from them. The prototype's own description states the premise directly:

A prototype of what declarative programming may look like for the physical world. Show the system what you want, and watch a mechanism appear. Move the sink, place an obstacle, change the shape. Describe the world, not as it is, but as you wish it to be.

The same page attributes the work as "A thought experiment by @bhaprayan."

The vocabulary of the world: sources, modifiers, obstacles, sinks, and targets

The interface exposes a parts-and-targets vocabulary rather than a code editor. The labels visible in the scraped page snapshot are:

Sources and moving parts: Crank, Weight
Modifiers and constraints: Block, Brake, Guide
Environment: Obstacles, Sinks
Targets: Bell, Door

Desired behavior is declared by selecting a target object and telling it what to do. The page instructs the user to "Tap the bell to show what you want it to do," and offers "Ring bell" as a selectable goal. After a goal is set, the page presents a "Working design" as well as a set of alternatives under "Other designs."

This is the core observable behavior of the prototype: the user sets intent on an object, and multiple candidate mechanisms are offered to satisfy that intent. The scraped page does not document the semantics of each individual part, so the exact role of Crank versus Weight, or Guide versus Block, is not specified in the available source material.

Challenges and the freeform bench

Impossible Machines ships with three named challenges plus an open sandbox. The challenges are listed as:

Make a detour
Beat the brake
Guided turn

Alongside them is a "Freeform bench" for building without a challenge objective. The challenge framing suggests the system is being positioned as an explorable puzzle space rather than a professional CAD tool: each challenge isolates a specific mechanism behavior the user has to achieve by describing a goal and accepting or rejecting the generated designs.

The interface requests landscape orientation

The site renders in portrait with a restriction. Its orientation notice reads:

Impossible Machines works best in landscape, where there's room to explore the mechanism.

A "Continue in portrait" option is offered, meaning the layout is designed around a wide canvas where mechanism parts, obstacles, and sinks can be placed and inspected side by side.

Why "declarative" is the interesting claim

Declarative programming means the user states what should be true rather than how to make it true. Impossible Machines applies that framing to moving parts: instead of dragging linkages into place by hand, the user declares an outcome — ring the bell, reach the sink, avoid the obstacle — and the outcome is translated into a mechanical arrangement.

The scraped page does not describe the underlying method, and no technical write-up was linked in the Hacker News thread at the time of scraping. What is observable is that the tool presents a primary "Working design" and additional "Other designs," which is consistent with a search over candidate mechanisms rather than a single hardcoded solution per puzzle. That distinction matters for anyone evaluating the prototype, because generating multiple valid designs is a materially harder problem than solving one.

What Hacker News commenters compared it to

The thread's most substantive contribution was situating the prototype in a lineage of prior work. Commenters identified three reference points.

The Incredible Machine. Commenter @pshc gave the shortest and most recognizable comparison:

The Incredible Machine vibes.

The Incredible Machine was a 1990s puzzle series in which players assembled Rube Goldberg-style contraptions from parts. The comparison frames Impossible Machines as the inverse proposition: instead of assembling the machine and watching what happens, you state the outcome and the machine is assembled for you.

Disney Research linkage synthesis. Commenter @mcphage pointed to academic work on generating linkages that trace a drawn path:

Disney's research lab did something along these lines some years ago for making a point follow a path. You draw a path, and it generates the linkages required to match that path as closely as possible. They've had a lot of follow-up work since, but I remember this video for it: https://youtu.be/DfznnKUwywQ?si=F-5NZxKu4hP_mand

This is the closest technical precedent raised in the thread. Drawing a target path and having the system solve for a linkage that approximates it is the same inversion of the design workflow that Impossible Machines applies to bell-ringing and sink-reaching goals, and @mcphage notes that the line of work has continued since.

Microsoft Research motion work. Commenter @jdw64 cited a Microsoft Research publication, writing that a past project that inspired them "also had a similar implementation" and linking to a Microsoft Research publication page whose URL begins with "motion-". The URL in the scraped comment was truncated, so the specific paper cannot be confirmed from the available source.

Taken together, the thread's position is that declarative or inverse mechanism design is not new research, but that the browser-based, immediately-playable presentation of it is what distinguishes this prototype.

The strongest concrete feature request: behavior over time

The most actionable critique came from @skinfaxi, who observed that the current world model only supports instantaneous, binary goals:

This is cool! I think it would be interesting to expand the language of the world. Right now the interaction with the bell or door is limited (basically binary). Even with binary it would be cool to say ring the bell three times or play shave and a haircut and then a mechanical device that could generate that frequency would be created (for ex a simplistic one would be to skip every other ring for ringing the bell). I guess that would require the world/the objects to account for interactions over some recording period.

This is a meaningful architectural point rather than a cosmetic request. A goal like "ring bell" is a terminal state: the mechanism either reaches it or it does not. A goal like "ring the bell three times" is a temporal sequence, and satisfying it requires the system to reason about the history of interactions across a recording window rather than about a single end state. As @skinfaxi notes, the example solution for alternating rings — gating every other ring — is mechanically simple, but expressing the goal itself requires the world model to represent time as a first-class dimension.

In other words, the current prototype's declarative language covers where things should end up. Extending it to cover how things should unfold over time is the natural next step, and it would change the kind of mechanism the system can search for.

Open questions raised in the thread

Implementation details were not disclosed. The top question in the thread came from @donalddominko, who played with the demo and asked for the source:

This is actually very interesting idea you had. I watched the demo and played with it and I am looking for a link to repo - I would like to know how did you implement the system achieving the outcome.

No repository link appears in the scraped thread, and no reply from the author is present in the comment set.

Engagement signals were thin. The submission reached 36 points and 9 comments, but every visible comment in the scraped thread carried a score of 0, and one comment was flagged and not shown. The thread is therefore best read as a small set of informed comparisons and one strong feature request, not as a broad consensus.

Bottom line

Impossible Machines is a prototype that asks a specific question: what would a programming language for physical mechanisms look like if you described the world as you wish it to be rather than as it is? Its answer is a canvas of sources, modifiers, obstacles, sinks, and targets where selecting an outcome — for example, telling the bell to ring — returns a working design plus alternatives. Hacker News commenters located it in a lineage that runs from The Incredible Machine through Disney Research's path-following linkage synthesis, and the sharpest critique is that its language currently handles end states but not sequences, so goals like "ring the bell three times" are outside what the world model can express.