Problems people are motivated by

In Aug 2024 the community did an exercise of articulating problems that motivate us, and trying to organize along the lines of those problems. Here's the current "star map" showing close connections between everyone who participated:

Distances and angles are not meaningful, just the presence or absence of an edge between two people. The graph is incomplete, because many people haven't yet commented on how close other problems seem to theirs.

Phase 1: Problem statements

Arvind Thyagarajan: It's fun and cool and a matter of creative pride to build well crafted and loved software for your family and friends and immediate community, but not enough people do it because it's unnecessarily hard, intimidating, and annoying.

avon: I think fundamentally I’m trying to attack this feeling that the digital spaces my friends and I inhabit don’t feel like our own personal space, and we have to communicate using someone else’s set of rules.

Beni Cherniavsky-Paskin: 3 problems:

Dany: I want to create interactive content and games, the way I work in Houdini / Photoshop / AfterEffects...

Dennis Hansen: I want to see software go from:

Duncan Cragg: The unprecedented magical powers and freedom of creation of programmable technology are not available to normal people, they're controlled by a "priesthood" of techies, big tech and technocrats that encourage and exploit complex, hard, imperative architectures and paradigms that inevitably lead to them watching, censoring, manipulating and dividing us. All of us should be freed and empowered to cast our own magical spells over our own personal and shared realities, through simpler and softer, humane styles of interaction.

Eli Mellen: A lot of what I do isn’t big project based work, it tends to be small sort of toys, but I do always contextualize it within the context of the future of coding — and while it doesn’t have a clear single problem statement my focus shared across implementations, on every project I tackle I explore some new bit or way of approaching the process of programming; whereas people had stories for eons it wasn’t until relatively recently that folks settled in to some of those stories being novels — I’m interested in exploring the different forms are programs can take and what forms help meet what sort of situation

Guyren Howe: A great deal more business logic can be expressed in First Order Logic than usually is. The relational model shows us how to make FOL inference straightforward and predictable. Therefore, we should implement much more of our apps in a relational system.

Ivan Reese: I have different answers for each project I'm involved with:

Jason Morris: The world runs on rules. Rules can be made computable (without translating them into objects or functions or processes) but it's unnecessarily hard to do. If it was easy, people who understand rules could build software that understands them too, people with problems could get cheap and reliable help, asymmetry of information would be reduced, and the world would be more just.

Jasmine Otto: Knowledge transfer depends heavily on special diagrams that don't transfer well to code. More stakeholders can follow experts using direct manipulation on their diagrams, than would benefit from direct access to the algebra, which is what current-generation visual analytics IDEs offer.

Jimmy Miller: Our programming environment is the main thing that influences the way we think about software. Much of this learning is implicit. It affects what problems we solve, how we work together, what things we consider possible, what things we consider hard, what arguments we find compelling. There is exists no combination of tools that teach these things in a way that align with my values.

John Christensen: I think the world needs more domain specific languages. "General Purpose" programming languages are difficult to work with because they require you to work in abstractions far away from the problem domain. Domain specific languages can have first class visualization/structured editing of logic and data. This dramatically reduces the amount of things to keep in your head, and domain expertise (rather than coding skillz) becomes the primary prerequisite for proficiency.

Jonathan Edwards: Software development is shattered into a stack of special-purpose technologies, each with their own terminology, syntax, and semantics. This creates a great deal of friction and complexity. Maybe this complexity is necessary for the most intensive software, but the long tail of small-scale software problems can be solved with much simpler tools. My goal is to collapse the stack into a unified substrate that is dramatically simpler albeit slower. My meta-goal is to organize other researchers into a field working on software substrates.

Kartik Agaram: Adapting computers to ourselves is hard.

Konrad Hinsen: Agency over information processing systems is too centralized. Too many people have to adapt to someone else's systems, rather than adapting their own system to their own wishes.

Mark Dewing: Understanding software (program comprehension) is difficult. I'm interested in ways to make it easier to understand what a program does and how it works. By doing so, one can more quickly and more confidently make changes to a program. There is a part of the solution space that involves a progression from simplicity to complexity. Such as tutorials, build-your-own-X, proxy apps, extracting kernels, etc. Are there ways to make these easier to write or better connect them to the actual code.

Nilesh Trivedi: Malleability via abstraction for me. I have found programming to be joyful when done in an elegant domain-specific language. The absolute opposite of "ad-hoc". I hope today's LLM-generating walls of unmaintainable code is NOT the future of coding.

Paul Tarvydas: Programming is too hard due to the mistaken fundamental assumption that CPUs are like functions. This mistaken assumption originated around 1954. Future of Coding projects implemented using computers, would progress much more quickly if we thought about CPUs as CPUs instead of as functions. I poke, randomly, at a variety of ways of thinking about programming and try to show that many ideas are 10x easier than can be imagined when using /only/ the function-based paradigm.For example, DPLs (Diagrammatic Programming Languages) and multi-tasking.

Shalabh: Software is trapped in silos (apps) and can't be recomposed. Imagine a world where pencils only work on notepads from the same manufacturer. Where you can draw only certain words and shapes that the notepad had been designed for. Where collages and inter-manufacturer paper-pencil integrations require upfront agreement and engineering between all involved parties. This is the digital world of today. I want a software medium where I can easily compose any artifacts, without requiring heavy upfront integration. Where I can slice, copy, paste, share, decompose, inspect the provenance and generally engage with all artifacts in a uniform way. I want a collaborative, dynamic medium which also happens to be programmable.

Stefan Lesser: These are the big picture problems that motivate me:

Tom Larkworthy: I think I am most aligned with malleability: adapting software, ad hoc tooling, fast UI/logic generation, alternative representations, reactive programming. Did not know there was a collective until just now!

Phase 2: All the raw assessments by everyone of how close our problem statements are to each other.

problems.html (download a local copy and open it in your browser)

The image up top only uses everybody's assessments of the projects close to them (at distance 1, 2 or 3).

Eternally under construction

Please feel free to add or update your problem statement. If you do, feel free to start a thread asking people to incorporate it into Phase 2. Problems are not the only possible framework for thinking about the future of computation, but they seem like a promising approach.

At some point we'd like to repeat this exercise for solutions rather than problems.

Resources

Primary sources from Aug 2024 (though currently missing images and other attachments): 1, 2, 3, 4