Construct

Programmers should have the ability to create programs using tools that are native to the problems they are trying to solve, rather than having to jump through layers of translation. Traditional methods of programming work very well for linear, text-based problems, but break down when applied to other domains. Construct provides a different way to design computational solutions to geometric problems.

I worked towards four goals in the design of Construct:

• Clarity of program state. Programmers shouldn’t have to guess what the program is doing.
• Native geometry concepts. The language should mirror familiar concepts from pen-and-paper geometry.
• Specification without inference. Programs should be unambiguously translated from the programmer’s input.
• A full range of programs. Using geometry should not limit the kinds of programs we can create.

Programs are designed in Construct as geometric constructions, where objects are related by constraints. The interface provides two views, shown above. The top view shows the data represented in the program: a collection of geometric objects arranged in two-dimensional space. The bottom view shows a graph of the dependencies between these objects, allowing the programmer to examine relationships that may not be obvious in the data view.

Construct was designed to enable visual professionals (architects and designers) to engage computationally in their work without having to leave its geometric domain. I hope that this project will spur innovation towards creating more inclusive models of programming that can enable new approaches to computational problem-solving and bring a wider range of programmers into the field.

Construct was presented at Carnegie Mellon University‘s Meeting of the Minds symposium. I encourage you to view the presentation poster and read the full research report.