FoC Kartik

• 1 (Same)
• 2 (Overlap)
• 4 (Doesn't seem like a big problem)
• 3 (I care about this)
• 5 (Not a problem)
• 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.
• 6 (Alien to me)
• Ivan Reese 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.
• Konrad Hinsen I have added a :heavy_plus_sign: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.
• Avon
• John Christensen
• 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!
• 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.
• 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
• 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.
• Dany I want to create interactive content and games, the way I work in Houdini / Photoshop / AfterEffects...
• 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.
• 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. 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
• 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.
• Stefan Lesser 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?
• 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.
• 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. See https://duncancragg.substack.com/p/magical-mashability?hidden=true
• Beni Cherniavsky-Paskin 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...
• 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.
• Jonathan Edwards 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. (edited)
• Dennis Hansen 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