Some possible goals for the future of software After some recent discussions, I spent some time searching the archives of this community for the word 'manifesto', then skimming the manifestos I found in search of their goals, phrased as problems they saw in the world. Then I clustered them by these problems. Here's what I ended up with, possible problems we have seen in the past: • Programming computers requires a lot of knowledge and effort. ◦ https://github.com/dkrasner/Simpletalk/blob/master/ComputingManifesto.pdf ◦ https://github.com/stefanlesser/recurse/blob/master/manifesto2017.md (creating data visualizations) • Adapting software to ourselves is hard; few people do it. ◦ https://www.researchgate.net/publication/220427813_Meta-Design_A_manifesto_for_End-User_Development ◦ https://malleable.systems • Software is trapped in silos (apps) and can't be recomposed. ◦ https://malleable.systems ◦ https://object.network/vw-llll.html • Software is inefficient and unstable because it's built atop a Jenga-like tower of dependencies. ◦ https://handmade.network/manifesto ◦ https://vladh.net/manifesto ◦ https://guidoism.github.io/escape/day_two_manifesto • Programmers encourage the world to be profligate with the attention of others. ◦ https://github.com/stefanlesser/recurse/blob/master/manifesto2017.md • Software has a deep influence on populations without corresponding accountability. ◦ https://criticalengineering.org • Programmers build software atop platforms optimized for consumption rather than creation. ◦ https://www.inkandswitch.com • Programmers can't build a sustainable living without behaving in anti-social ways hostile to their customers. ◦ https://altocode.nl/blog/manifesto ◦ https://github.com/stefanlesser/recurse/blob/master/manifesto2017.md • Programming requires simulating the computer in your head. ◦ https://shalabh.com/programmable-systems/wheres-my-simulator.html • UIs are poor. ◦ https://github.com/Slackadays/Clipboard/wiki/User-Experience-Manifesto (discoverability) ◦ https://github.com/stefanlesser/recurse/blob/master/manifesto2017.md (touch-screen controls) • It is possible to break a computer's software in such a way that it requires outside intervention (e.g. a rescue disk) to fix. ◦ https://guidoism.github.io/escape/day_two_manifesto • Computers can't model the world. ◦ https://www.dcs.warwick.ac.uk/~hugh/TTM/DTATRM.pdf If the problem you're chasing doesn't quite fit in any of these buckets, please share it in a similar format. (One sentence, not describing a solution.) If it does fit one or more of these buckets, please mention them. (Alternative wordings are also appreciated, but for me the primary goal here is to cluster ourselves.)

This is an awesome breakdown, thank you for putting it together! I'm new to the channel, and it's been tough to get a broad picture of what people are trying to do. This is such an accessible way to dig into the space 👀

Thanks @Kartik Agaram! This is very helpful. I recognize my goals as mostly a combination of the points listed, but there is one more aspect which is somewhat related to other points but also distinct: People (users, other developers, ...) have no chance of knowing precisely what a program does if they have not written it themselves. Put differently, expressing software source code is a form of encryption of the initial developers' intentions. An obvious illustration is spyware, but the problem exists even in a world without evil-minded players. In my field of work, computational science, it has become impossible to understand someone else's work, because so much of it is documented only by source code.

Great effort @Kartik Agaram .. I think this list should be put on futureofcoding.org . My goals are mostly related to "programming requires simulating the computer in your head" and "Programming computers requires a lot of knowledge and effort"

@Kartik Agaram love the list! Curious if you could expand on what you by “anti-social”?

@Christopher Shank It's kind of a rough attempt at summarizing the contents of the actual manifestos under that bullet. Could you scan them and let me know if it doesn't seem the most apt phrasing?

I first interpreted “anti-social” as saying developers are socially avoidant, the act of programming and distributing it isolates and insulates them from society, so they never understand the impact of the software they are making. But it seems you’re also using “anti-social” to highlight how the incentives of building software largely go against the good of society (e.g. attention economy) and developers, the ones making the systems, turn a blind eye in order to make money/a living.

Yes, my reading of the manifestos was more your second interpretation. Going against the good of your users, or of society more broadly. And that fits with my own perspective as well. Examples: • when we say, "programming is a priesthood and programmers have power." • The new word of 2023, enshittification. For example, how Google search has gotten worse over time. • The broadly documented social ills that arise from say Twitter optimizing for engagement. One additional personal gloss of mine is that such behavior is not just anti-social but also goes against one's own long-term self-interest. I wonder what Larry Page and Sergey Brin use for searching the internet, and how they feel about it. Google's behavior seems anti-long-term to me.

Looking at that list again, it's mainly the first four points that overlap significantly with my own itches, in addition to the one I already described and which I'd summarize in a catchy phrase as "It's hard to see what exactly a program does, even given its source code." These problems do of course overlap with others from the list. For example, the power that software professionals and their employers have over the rest of us derives from their priesthood status, having competences and resources that can only be obtained by becoming a software professional oneself.

Also Home-cooked software ideology https://maggieappleton.com/home-cooked-software

@Oleksandr Kryvonos That's a good talk, but is there a problem in there? I'm noticing some relationships between the problems mentioned so far. The most interesting conclusion it's leading me to so far is that software is intrinsically untrustworthy because (following @Konrad Hinsen) it's often impossible to see what a program does just by looking at its source code.

Trust is indeed a big problem with software. All the more if you don't trust the commercial entitites that produce it. For an academic discussion of trust in computational science: https://osf.io/preprints/metaarxiv/nt96q

One of the core values I follow is "reduce accidental complexity". It sounds obvious, but digging a bit deeper, it has many ramification. For example, is memory management accidental or necessary? Depends. Is a dedicated PL for shaders or build accidental or necessary? Probably accidental. Another core value for me is, small and scalable. If something can go into a library, it probably should. Scalable is important, otherwise you can't build ontop of what you've already build. The tool can't be build from itself, it becomes hard to customize / expand.

@Kartik Agaram nice graphs, I will work on visibility and understability of programming - I think it is ok to learn a lot of stuff to be more fluent in programming, but I think people might use simpler and smaller subset of tools to start with

I think these problems are well-known, and over time got worse and more severe, not better. So what could you/one do about it? What cannot work is to try to make another app or SaaS or programming language, as it may address 1-2 points from the list, but there can be little hope (for difficulty and cost and dependency) to improve on many of these points. What cannot work is to waste the time with proprietary/silo projects, as these per their design/setup/intention/goal already decided that they're only going to do a few things for their particular users, which does not include other users, may exclude you, something may change with the single vendor/implementation after having become dependent-on/trapped-into it. It's probably a failure to deliver solutions in just one isolated place/product and not for software in general, across many systems, apps, services, etc. So for each of the points, one could go and collect strategies which improve the situation and reduce the problem, make/find/combine various little, easy, cheap things that supply or support these properties, port these over to more little pieces that still lack it, come up with some meta-framework which resolves these issues (as a category/type or actually, architecture, for how to make software that works in this fashion). Notice that each of these are different & separate manifestos, which each address their own respective point in isolation.

This is the crux with being for freedom and against silos and proprietary solutions at the same time. It’s easier to find a single individual who contributes their time and effort to move something forward single-handedly (like @Kartik Agaram did with collecting all these manifestos) than it is to align multiple people to commit to the same values, at least for long enough to move something forward together. Unless “collaboration” means I put some project on GitHub and you like it so much that you contribute exactly what I needed, avoiding any arguments. The really interesting things happen when a group of people with at least slightly if not dramatically different values and priorities get together and manage to come to some sort of agreement. It doesn’t have to be consensus, but maybe there are some principles in some order of priority that most (not necessarily all) people in that group can agree on. Then you have a manifesto that is worth the name. Before that, it’s just opinions. What I would like to suggest is to take that list and get as many people from here as are willing to do so together into some kind of room — perhaps virtual, perhaps even physical, perhaps for a synchronous discussion, perhaps just some temporary asynchronous thread — where we try to come up with something that most (not necessarily all) who are in the room can agree on. This is not an easy process. Because it’s a messy social process and not a problem waiting for a technological solution. And let’s face it, we’re all much better trained in dealing with the latter than with the former. Openness is needed. Compromises will be required. Freedoms will be limited. That’s what it takes to commit to a shared direction. One meeting will not be enough. It would have to start with individuals presenting their perspective and others to listen until we all understand where everybody is coming from. Then we can start to argue about what is more and less important and how we should phrase it in a statement that represents the group. To a certain extend you will have to learn to love the process and let go of the result, at least for a while. Maybe the result will not be good enough. Maybe the whole thing will be a blood-bath. Maybe some people will leave the group mid-process. Maybe new friends or enemies will be made in the process. But chances are that most of those involved will take something away from it, even if we don’t end up with something like the Agile Manifesto in the end. I find it highly unlikely that a significant enough number of people would be interested in seriously attempting this. Maybe you like the idea but just don’t have the capacity at the moment. And capacity it will take. That’s fine. I just want to raise my hand and say that I’m willing to try this, seriously, and I’m available, and I’d like to support such a process where I can. I’m not going to volunteer to drive this process though. I have my own skin in the game and I think it’s better if somebody who doesn’t steers it; I could potentially find someone who can help with moderation/mediation, who is skilled at exactly that, but doesn’t know anything about programming, if people think that’s useful. I consider moderation/mediation and driving the process different things, which can be (but don’t have to be) done by different people.

Thought for my day: "deliberate structure creates better bonds." https://hachyderm.io/@anthrocypher/112655263184386797

@Stefan Good points you bring up. There might also be the option of "rough consensus and [hopefully increasingly] running code", meaning, that we don't necessarily need to agree/align on values, priorities, etc., as long as one agrees that at least one of the problems/deficiencies listed would benefit from some improvement. OK, theoretical agreement is one thing, let's say it's of help if anyone makes some contribution to at least one of these items. Similarly, besides issues and problem solving, maybe the goal/mandate/focus could be to try to find ways to make these things easier, simpler, cheaper, to gain some overview, collect solutions and failures/dead-ends. If someone works on their respective own thing, that's fine, we can then review it and look for ways how to introduce it easily/cheaply elsewhere (not anyone's single future of coding, but for software in general). If that's difficult and too expensive, we may look into why that is, and what could be done about it. In a similar fashion, there could be "work groups", maybe RFC process with comments, updates/corrections, etc. No need to agree on a particular path, as is fine to do multiple contradicting explorations, prototyping, or other, and simply collect and consolidate/organize the findings for next steps. Of an "open" (non-exclusive/-excluding, while protecting against hijacking/distraction) "institutional" type, long-termish (next 100 years of coding?), neutral in operation (avoiding conflict-of-interest, so favoring one hobby horse project/approach should not prevent/hinder other attempts), and so on.

Wherever you go, there you are. But the one thing you can do is build a map of the places you've been. That always helps.

Yeah, we don’t necessarily have to agree on anything and everybody is free to do and build what they want to. That’s great. And, yes, exactly, that's what we’re doing already. Freedom! That’s all great and contributes important variety and diversity. But through an evolutionary lens — just applied as an analogy — it seems we have plenty of variation but not enough selection to make progress. There are no clear pressures to adapt towards something, to achieve better fitness. We have more projects than we can weed through in a lifetime. It seems with very few exceptions people prefer the “throw something at the wall and see what sticks” open market approach to developing ideas. And what gets selected is mostly based on popularity, which has often little to do with how good the underlying idea is. I’m not saying we should stop doing that. It just appears to me that we have plenty of people trying that approach already and wouldn’t it be great to also try some other approaches as well? One of them I tried to outline above. It’s not supposed to be “better” or “right” or anything like that, just different. Seems interesting to me to investigate what drives other people to believe what they believe is good and try to find patterns and see where people’s values overlap. Sure, we can try to figure that out from deciphering individual project READMEs on GitHub and that’s probably a more convenient process where nobody gets into an argument. But ultimately coming together on certain issues is a kind of editing process where parts have to be cut to make something else stand out. We do this all the time when we design what we work on, but we mostly do so individually, hoping that other people will later find it so great that they join our cause and accept our values. I’m just wondering what becomes possible if we’d align our values and start from a shared cause.

I don't look at it that way, a dichotomy of "freedom"/diversity/variance vs. a homogeneous shared goal/alignment. Instead, similar to the Agile manifesto or Christopher Alexander's test for more aliveness in a design (with likely some overlap between the two via Ward Cunningham), the selection can simply be made according to openness/libre-free licensing over closed/proprietary implementation, portable over a specific one-off implementation (idiosyncratic), generic over specific, simple over complicated (but no simpler), cheap over expensive, horizontal modules/layering over vertical integration (= rigid), and so on. On the basis that in/with software (as the medium), this should be possible, and the costs and complications and incompatibilities are to some degree artificial and unnecessary (not technologically inherent/mandatory). That way, two attempts can be compared and the better one identified. With ones that are bad overall but include a few good aspects, the good aspects can be extracted and added to better designs/implementations. For overall desirable implementations that have a few undesirable aspects, why not make a variant which removes these? Also based on that these properties should introduce the flexibility for this to be a realistic/practical occupation (to make such adaptions/changes within acceptable time/effort). To clarify in regard to your framing: there's a freedom to try many things that may potentially produce the desired properties, and there does not need to be much interest nor is there likely much benefit from results that fail to be designed towards these characteristics. Does this make sense? Or do you have a master plan already with most of the questions answered/solved?

@Stephan Kreutzer Who makes these decisions over the criteria you list? And how are these decisions made? In what context? Would you be able to state which of each criterium is universally better than the other? Is open, portable, generic, simple, cheap, horizontal always better than the respective alternatives? In my view these are design decisions that individual developers make during a project and often they have a general preference for one, mostly based on their unique experience of which languages, frameworks, and patterns they have encountered and are familiar with. This has little to do with Alexander’s Mirror of the Self test and a lot with what he writes about in Liking something from the heart: > It is a current dogma that you may like what you wish, and that it is an essential part of democratic freedom to like whatever you decide to like. This occurs at a time when the mass media have taken over our ideas of what is likable to an extent unknown in human history. Thus if one were pessimistic, one might even say that there is very little authentic liking in our time. What people like can often not be trusted, because it does not come from the heart. While it sure seems easy to decide if it’s just you making that decision for your own project that you have full control over (could this be why there are so many of these projects on GitHub?), it seems we can’t agree on any of those collectively, and certainly not based on a deeply felt agreement that does not come from some shallow ideology. We don’t have a collective direction, a North Star to orient ourselves towards when making such design decisions. We just have several ideologies that prefer different aspects and have different priorities putting different weights on each of them (Declarative! Strong typing! DRY! Test first! This or that architecture! Etc.). Direction can’t come from a preference for certain design decisions directly. We tend to argue as if there was a universally best way or right approach and you should always do X. But somehow there is always somebody why doesn’t agree X is the right thing to do. Direction has to come from deeper values that allow us to make good decisions in particular contexts — sometimes making a design decision that is the exact opposite from the last project we did, just because the context was different. And while not at all easy, values may be the only things we might have a chance to agree on. When an Emacs and a vim person go at each other, it doesn’t really matter who is right (because neither is), it’s much more valuable to attempt to understand why they think they’re right and in what environmental conditions that may be true. The alternative approach I suggested only looks like its goal is to define what is “universally right”, at least for the people participating. What it really is about is to look closer at the context to learn about why people prefer one over the other and in what situations that makes sense. To find out what they value and to see if we can find some alignment in that. As Alexander puts it: > _The essential thing is that, when we really like something, we generally agree on it. This is so shockingly different from modern ideas that it needs to be discussed very carefully. > > The main breakthrough in understanding will come when we are able to distinguish the everyday kind of liking (where we obviously do not agree about what we like) from the deeper kind of liking where […] we do agree. Ultimately it will be this deeper kind of liking, where we agree, that forms the basis for good judgement in the realm of architecture. > > The crux of my argument will be to show that the deeper kind of liking not only exists but also corresponds exactly to the presence of living structure, and to objective and structural life._

I wonder to what degree we are victims of the problem(s) we are trying to solve. I see many projects here that have a lot of overlap with what I am trying to achieve. But I cannot contribute to them, nor even examine them in depth, because of technological gaps. We all build stuff using the technology we know and love, but that's different technology for everyone. Plus we choose example application domains we know and love, and those are different as well for everyone. For me this is fine. Exposure to interesting ideas is reason enough for me to be part of this community. Sure, we could all be more effective at reaching our goals.But I suspect that would also be less fun.

...

But I cannot contribute to them, nor even examine them in depth, because of technological gaps. We all build stuff using the technology we know and love, but that's different technology for everyone.

...

To me, this sounds like a "challenge", a problem-to-be-solved. You shouldn't need to examine components in depth to simply use them and to take advantage of their ideas. Unix pipelines let you do that, but, most languages don't allow plumbing components together (easily) that were written in other languages. Unix pipeline syntax makes it too difficult to go much beyond pipelines to build networks with multiple connections between truly-asynchronous components. Internet-ish plumbing is somewhat different, but, we're stuck creating networks using caveman assembler-level, goto-level operations that need more "structured programming"-like revelations.

It definitely is a challenge! And one I'd love to see tackled. Until then, it's an obstacle. What makes the challenge hard is that it spans multiple layers of technology and multiple roles in dealing with technology. Data structures and APIs must be matchable from an efficient low level up to a user-relevant high level. And there must be match-making techniques for software developers, systems integrators, and end users.

@Konrad Hinsen I started Mu because I couldn't make sense of the code of existing projects. And Mu failed because I couldn't learn from other projects.

Everybody: good points and great examples! I would have lots of comments, but would take too much time and space to write and read these, into the ever-expanding mess. Therefore, one option could be to just act (not necessarily found or pretend-to-be) as some kind of another ARPA/SRI ARC, PARC, VPRI, (not HARC as that was another startup scam), except it's mostly virtual/online (as network is in place), and there's also no money (instead, no need to burn much, on what? salaries? without a business/income/ROI? so the benefit/gains is from savings, collaboration, reuse, progress, from the respective results/artifacts, and if it's not that, questionable if the results are any good [dogfooding, bootstrapping - in the Engelbart and maybe but lesser so startup sense]). Main purpose is to "organize" the explorations, somewhat more strategically, channel the efforts instead going in all arbitrary directions. You may simply join/create a department that works on a project/problem/topic/domain. Too for project managers, designers, testers, writers, etc. (non-technical roles = functions). With "neutral point of view" (research is kind of open-ended, hoping to not be prescriptive/biased, but guided based on progress/results), we just collect problems people see and the potential solutions, catalog the failures and successes, compare these in their context. Architectural pattern language (not GoF Design Patterns of just idiosyncratic little recipes) could be made up from [example:] layers is universally better vs. integration is universally better, to then compare/score, review/investigate what the benefits are vs. problems/costs/limitations created. Ideally, eventually something can be found or made that's reusable/exchangeable and integrating, which is a research question, and is a good result if determined that these are mutually exclusive for an inherent technological reason (not historical/arbitrary reasons), which would be great to pinpoint and understand (can save lots of time and is then a new base line for trying/attacking it nonetheless, or finding mitigating workarounds). Also, you already have a list of manifestos and problem descriptions extracted from these, so depends to which ones you subscribe and which you would want to add. Similarly, which solutions/approaches you would subscribe to and work on, vs. which not (reject). Ultimately, at the end there would need to be an imaginary Alto-like to be produced and supplied (materialized into applications or conceptual architectural patterns + anti-patterns [like "considered harmful", etc., + why and when]). Alternatives are: not doing it or doing something else.