Prompt for everyone here: to the extent that you think about the Future of Coding or have projects to try to improve things, what problem are you trying to attack? Can you state it in a couple of sentences? Without reference to a solution? Try to be precise about the audience. For example, some problems affect everyone, while others affect only professional programmers, or only researchers who use computers in their work. My hypothesis is that focusing on problems will help us all find our most promising collaborators in this group. (The next step will be to combat our tendency to be defined by our tools, to let our tools erect barriers that divide and balkanize us. But that's further down the road. For now, let's just "find our homies," the people we share specific dissatisfactions with.) There are ideas for problem statements in a couple of earlier threads: • https://futureofcoding.slack.com/archives/C5T9GPWFL/p1718448593662299 • https://futureofcoding.slack.com/archives/C5T9GPWFL/p1717926129937119 • https://futureofcoding.slack.com/archives/C01932BJGE8/p1721870703344739 But this thread is not for critiquing or analyzing any of those statements. Just add your own, and nothing else. (It's totally fine to copy statements from these threads. Many of them were arrived at after tons of consideration so it would be surprising if others didn't care about them. Also feel free to synthesize from multiple statements. Just try to get to something crisp and opinionated.)

I have different answers for each project I'm involved with, but they're all ultimately a "there oughta be". I am the audience, in that I want to see something exist in the world. • At Ink & Switch: I've never seen software that echoes the pleasing feeling of scribbling on paper — especially not software for programming. • Hest: I've never seen an approach to programming that centers animation. • My personal website, the Hest podcast, the FoC podcast: Too often, the way we share our ideas feels like slowly letting stale air out of a balloon.

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.

• 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.

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.

Adapting computers to ourselves is hard. (hi there @Arvind Thyagarajan)

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.

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

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.

I have added a ➕to all statements that I see as overlapping significantly with my own. Four so far, not bad! But I'll also try a problem statement in my own words: 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. I am working on this problem mainly in my professional domain, computational science, because that's where I feel I can make most progress with the little means I have, but I'd like to see it attacked more widely.

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!

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

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.

• The top-level environments in which end-users spend their work day are not malleable. This got worse in last decades. • The ones that are malleable, require too much professional coding knowledge to inspect or modify. • That holds even for 100% Open Source linux desktops. They could be so much more self-explaining, self-inspecting, self-modefecation-guiding...

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.

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. We have existing, successful, widely-used systems that implement an end-user relational “programming” system (FileMaker, Access). Datalog is almost certainly the language in which to express this logic, insofar as we’re not just doing it with a GUI. This attacks the issues we’re all concerned with by: • making it possible to solve problems with much less traditional programming; • supporting end users solving their own problems without needing to learn programming; • changing the nature of the traditional code we do write into smaller, simpler pieces joined together with relational logic frest.substack.com

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. See https://duncancragg.substack.com/p/magical-mashability

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.

These are big picture problems that motivate me: • We design generic and universal solutions that scale, instead of specific and contextual solutions that fit. • We expect people to adapt to tools that don’t quite fit their needs, instead of empowering them to create exactly what they want. • We mechanize the world and automate our humanity away, becoming more like machines, instead of amplifying what makes us human with technologies that augment our intellect and creativity. And these are more specific problems I work on, plus a few exploratory questions about them: • We build on infrastructure we don’t/can’t fully understand anymore. ◦ To what degree makes us lack of holistic understanding overlook important design opportunities? ◦ How complex a system can fit into a single individual’s mind? • We avoid changing infrastructure because too much depends on it. ◦ To what extent do we lock ourselves out of exploring valuable branches of the design space? ◦ Is it really that difficult to reinvent and replace foundational elements of our infrastructure? • We think about software as tools to manipulate and control when they have become more like environments we experience and inhabit. ◦ What makes designing livable environments different from designing functional tools? ◦ How can we design open systems that enable and encourage unanticipated use cases?

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.

Reminder to folks: here's the other part of the fun game

OK I’ll play. The problem is that 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.

I want to see software go from: Molded to computers → Molded to humans Arcane symbols → Intuitive physicality Mass-manufactured → Self-authored Hidden inner world → Fully inspectable Ossified → Malleable Siloed → Co-located Lonely → Shared

I'm most aligned with "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.