I am sorry to interrupt, and this may sound like a question with an obvious answer, but what are the goals we are trying to achieve? What are the problems we are trying to solve?

As it happens, as a follow-up to part of the sprawling thread under https://futureofcoding.slack.com/archives/C5U3SEW6A/p1717664405411569, I have a couple of dozen tabs open with manifestos shared in the history of this forum, that I've been meaning to lay out in one place. But unfortunately I've gotten side tracked by all the other parts of that sprawling thread..

I might join some project instead of developing my own, but I need to be interested in that project

There's a table somewhere with projects by everyone here, but (1) I don't remember where it is (some Google Doc?) and (2) I don't think it has "goals" as a column (though it should).

Yeah, I think manifestos are a different kind of beast. Shared problems do seem like a better starting point for collaboration than shared solutions.

There are 3000 developers here, if 1% of people are willing to join and develop other projects this mean that we have 30 persons which roughly mean that we can sustain 6 projects in parallel (5 per project). time to unite 😄

Here's the spreadsheet: https://docs.google.com/spreadsheets/d/12sTu7RT-s_QlAupY1v-3DfI1Mm9NEX5YMWWTDAKHLfc/edit?pli=1#gid=0

hopefully not over-estimating

You are probably over-estimating. I don't think I've seen any people here join any projects.

I've never seen it happen and I'm pretty sure it'd be a memorable event

Everything is too fucking complicated. I want a person to be able to use a computer to at least 95% of its capabilities (right now they are using maybe 30% of its capabilities) within a few hours of seeing a computer for the first time. And I want them to be able to do that even if: -They are 8 years old -They are living after mankind has experienced semi-apocalypse

I think that's too ambitious to be productive, @hamish todd. There's a difference between understanding the primitives and doing everything that is possible. I'm not sure I can use even lambda calculus to 95% of its capabilities. Certainly none of us can do 95% of what is possible with Legos, right? Consider prime numbers. Easy to define for an 8 year old, but you can spend many lifetimes plumbing their implications. Similarly "after mankind has experienced semi-apocalypse" seems hard to test. What's more, I think a semi-apocalypse might make people more focused and willing to spend a few days to learn something. "I only have a few hours" seems like a first-world problem. My preferred framing is: get some value after 1-3 hours of effort. Not requiring a tall cliff of 100 hours of effort to get any value out (even if it's 100 hours worth of value). This feels like a good test that you don't have gratuitous complexity, while not limiting potential for life-long learning. I tend to agree with your broad sentiment, so perhaps I'm being pedantic. But I think the problems here quickly get so intractable that there's huge value in picking an achievable goal.

I agree that learnability is a key point. At each stage in your journey, it should be clear what next steps you can take, and taking each step should represent a manageable effort.

@Oleksandr Kryvonos I love that you bring this up - I briefly done so here, and did for a long time in other places. Greatly appreciated that you did it, at this point I'm just too tired to push against majorities in some group which has very different goals. What I read into the question is this: • one future of coding might be that we're all going to do much more coding. And invent, reinvent, many techniques for many different personal or proprietary systems/environments, for the odd chance that one might become popular/successful or to prove/promote another point. But all of these separate and incompatible, and after many years, maybe one little thing gets adopted elsewhere, or not. Inventing even more languages that have a set of features but not another set, so if you switch from one to gain some benefits, you do it at the loss of other features + sunken cost into the prior environment. While at the same time, it's just far too much work for any single individual to do all/enough of it, but by being very busy doing my own silo/duplication, not joining anybody else's, it's a lot of wheel reinvention and duplication. • another future of coding is one where more of the things created become reusable, compatible, mixable, to get some benefits/savings from synergies, reuse. I can easily imagine that the 2nd "future" is not a goal/interest for many. To the contrary, specifically here to do more of, or their, or another competing/duplicating, variant of future option 1. These two are not mutually exclusive, but I don't see a whole lot of benefit/improvement coming from the competing/duplicating piles of option 1 projects (too many to even look/review these, far less to reuse, if one could in the first place), and I don't see much done towards option 2. Given there's lots and lots of people around doing their respective own projects, but there might be not much shared goals (or different conflicting strategies to get to the goal, unorganized, non-coordinated, not practically collaborating), just a vague overlap of lowest-common-denominator (as type 1 doesn't have much interest nor sees much benefit beyond that). It is far easier to just work on your own personal project and ignore everything else, and remains a harder problem, too expensive or technically or legally prohibitive to mix/reuse other people's work (because per type 1 is not designed to, this was/is not their goal). Maybe you did not have this in mind, but it's a hard problem that remains, and I don't see how a future of coding is much interesting or greatly beneficial if most of the work/effort is sunken into repeated duplication/reinvention, results trapped/stuck in this dead end (to then be rediscovered and duplicated all over again).

I would love to do 2. Somehow all my attempts end up as 1. It's like a nightmare. If only someone could show me what I'm doing wrong.. After many attempts, my alternative framing of these phenomena is: you need a Cambrian explosion of lots of people trying lots of almost identical things before it starts becoming clear what the solution to converge on is. The problem is not that we have 100 projects doing similar things. The problem is that mainstream tech is preventing a million new projects from exploring similar things.

I'd love to do 2 as well. But compatibility/mixability can only be achieved at an infrastructure level on which we all build. There is no such infrastructure level today.

Hence all the attempts to build infrastructure to converge on. I explicitly used to pitch Mu as "build your research projects atop this, and they'll be easy for other researchers to run." Needless to say, this was not compelling.

We expect much more in terms of affordances from our infrastructure than what Mu could possibly offer. Which points to the problem: designing and building a good-enough infrastructure takes more resources than we have, and then we probably wouldn’t be satisfied with just good enough. Wondering: are there best practices for building prototypes for future infrastructure?

@Kartik Agaram Mainstream tech preventing things, that does not need to be relevant. Would be fine already if developers here could share/exchange some things between their respective apps/environments, given people here are developers, are not constrained/bound to mainstream tech (by making their own things/apps/environments anyway), etc. But for "some" reason(s), seems this is too hard/expensive already, for reasons. I don't think mainstream pressure is a significant factor here (for people who make their own things instead of passive consumption of delivered mainstream artifacts).

@Stephan Kreutzer I don't really follow why you think mainstream tech is not relevant, or why you think developers don't share/exchange. It sounds like you're saying that there's something easy we could all do that we are not doing, but I don't follow what it is. Perhaps you could demonstrate what it is by example in a project, perhaps of your own that shares/exchanges with some other project? Perhaps you already have such an exercise you've done before that you have in mind. I'd love to see a pointer to it if so.

Uhh, I don't know, I don't have much of a clue what you people or other people are doing or have tried. For some time, I'm trying to come up with some kind of system architecture/model that's horizontal instead of vertical integration/apps, similar to the great architectural designs like ARPANET/Internet with OSI Reference Model, DIKW pyramid, these kinds of things. Might never work, might be ugly, might be slow, fine, but maybe it works eventually, or some parts. I have no idea, I'm just trying to find out (why and why not and what can and can't be done about it). https://rumble.com/vgkp4r-reading-and-processing-data-and-text-input.html + https://rumble.com/viajgt-structuring-data-and-text-inline.html + https://rumble.com/vk47ug-tokenization-and-lexical-analysis.html + https://rumble.com/vva5ds-parsers-interpretation-and-control-flow.html with at least two more missing about encoding and escaping but it should probably better be a writeup/articles/posts and not video, there's also a few good books like Terence Parr's "Language Implementation Patterns" (he's the ANTLR guy with respective grammar library, in my mind this is to undo syntax/notation). Here's some parser + transformer?/filter? based on grammars, https://gitlab.com/publishing-systems/tero-grammars OK it's just subsets/incomplete/not-correct and not ENBF, fine. Another that's nested/cascading and stream-based (idk, I just avoid AST/DOM/tree in memory?) https://gitlab.com/publishing-systems/jteroterosta which doesn't really work and is kind of dumb, there's even a "debugger" https://rumble.com/vr52of-interactive-tero.html but that's broken because I made a major mistake down at the core of all of these and too what's the point of a separate GUI that's not introspective/reflective (debugger written in itself)? Is then trivial to put it into a viewer/"browser" or similar https://rumble.com/vpw3z3-einfacher-web-browserviewer.html and one day into a "structural" (?) editor (of the Emacs/IntelliJ and not Teco-vi/Visual-Studio type). Separately, there's an implementation of an interpreter for a subset of TRAC (that's because I went after that before looking at Lisp, and too I push back against designing any new lang) https://gitlab.com/skreutzer/bac and obviously, point would be to make parser front-end grammar-based (including recreating it's grammar definition grammar in the host/implementation so from there it can load other grammars for other langs/notations/syntaxes, minus libraries, lang contructs, idiosyncrasies) and internal interpreter all just mappings. Eventually adding a compiler backend if I ever can, who knows x86, RISC-V, Java VM bytecode, Smalltalk VM, no idea (and likely never optimized). Before combining these, I still suffer from not having memory, which does not work for sources that aren't context-free. For graphics, GUI, data viz, why not throw away all the frameworks just give me the device context/canvas, I abstract away just some primitives of drawing a line, box, circle, do some hitbox test https://gitlab.com/publishing-systems/experimental/-/tree/master/graph + one more in "Object Pascal" with Lazarus Delphi version for forms as an exercise, but couldn't clear rights so far so is not added (with all of these, throw away the graph exercise and add graphics primitives against DirectX, OpenGL, SDL, Qt, anything and whatever, like Logo/Turtle, doesn't matter) and that's then controlled by scripts/interpeter with some algos that are portable across rendering devices of platforms. Admittedly, there's also some older earlier ("work")"flow" things, up to imitating NoFlo adapters for invocation (minus GUI/diagrams), but ofc that's too heavy/rigid and I think it's pretty clear that each of these parts can't work very well on their own if not on/in some kind of system which offers common services behind target-/platform-/implementation-independent abstractions (can be both, local and/or remote nodes, mixed, without noticing or caring), communicating via some shared "message" exchange. BUT this is a pile of old junk, these are also the easy parts, which also don't really work nor are useful, basically I don't really care and don't look forward to discuss. Instead the thing is to make many more things (for me personally, would be great if in the area of things I have been unable to do, or don't have the time to do myself) over a weekend or two (or a few months), till maybe there's something that's neat and does work, only after which some beneficial use case or application might be eventually found if we're lucky or clever. Also, to be very clear, I'm absolutely not going to tell anybody else what to do or not to do, to the contrary, better avoid the kind of things I have been trying so far! Make something better, or you already did, OK, what is it, how does it work, how can someone else independently implement/port it to other uses/places, ideally easily/cheaply? Mine is besides the point, I don't want to link these, don't waste the time looking at these. Should be at most just another implementation of a set of general architectural patterns, which are combinable/mixable. If your vendor of your environment supports a common feature, cool, if not, OK too bad, back to graceful degradation or you get/add it.

I guess the obvious perspective on the current state of the software world for me is: we have plenty of reuse, both of pieces of software (programming languages, web browsers, etc.) and of architectural patterns (MVC, event loops, semantic versioning, package managers, high-availability databases, etc.) It seems to me that we share millions of lines of code across the OS and web browser, and then we have hundreds of projects fork off hundreds or thousands of lines of code on top of that shared infrastructure. In this view it doesn't seem fair to me to focus on the thousands of lines, rather than on the millions of lines below them. It seems clear you don't share this perspective, so I'm curious to hear why. There's some metric in your head by which we're not sharing software and not building on each other. Can you come up with a concrete metric for it?

@Stephan Kreutzer Mainstream tech is what powers every device I can buy. It's what produces all data I consume and implements all protocols that I use and wish to continue to use. I am not interested in starting a full tech stack from scratch. I have neither the competence nor the time for this, but most importantly not the motivation. My idea for FOC is evolution, not revolution. At the same time, I want to escape from dependencies on lock-in technology. Which is why I am a big fan of boring technology. I suppose I am not alone here with this view, but I don't expect it to be widely shared either.

I have neither the competence nor the time for this, but most importantly not the motivation.

I’d love to dig into this. All three of these. _Competence_: Seriously? You know how to program. You know more than one programming language. It’s all the same anyway. What makes you think you lack competence in building anything you can dream of that is made out of code? It reminds me of Christopher Alexander pointing out how our current culture has achieved to convince regular people that they can’t build their own houses. _Time_: That’s easier to understand. It seems insurmountable to get anything done these days that isn’t just a trivial application of high-level APIs in few lines of code, which most likely somebody else has already done. Also, infrastructure has accumulated millions of lines of code at this point so it’s hard to imagine doing something like that from scratch by yourself. But isn’t that just because our assumption is that a lot of tech has to be done like it has, and it would be dumb to not build on top of the infrastructure we already have? Was it better when we were naive and didn’t know how things “are supposed to be”? That reminds me of the story Alan Kay often tells about Ivan Sutherland who supposedly said about inventing the first interactive graphics program, the first non-procedural programming language, the first object oriented software system, all in one year with Sketchpad, “Well, I didn’t know it was hard.” _Motivation_: Well, that’s a very personal one. No one can tell you what you should want to be doing, only you can decide that. But it reminds me of @Devine Lu Linvega who has carved out his own little piece of infrastructure with Uxn that over some time has grown to become his daily driver and — most importantly — seems to deliver endless motivation and joy to keep hacking away at it. I’m realizing that I’m writing this less as a response to you, @Konrad Hinsen. You provided an excellent prompt to write this down for myself. Thanks!

@Stefan When I say I lack competence, I am not thinking so much of programming competence but of domain competence. Example: I couldn't write my own networking stack because I am mostly ignorant of networking technology. Given time, I could rebuild all the software in my own domain, personal or professional, but not the infrastructure I rely on. Staying on the topic of infrastructure: I am not aware of any precedent for infrastructure being rebuilt from scratch. All infrastructure I can think of in our world has been built on top of or as an evolution of existing infrastructure. One reason is possibly that we have to remain at least interoperable with existing infrastructure if we want to do anything in collaboration with the rest of the world. Your reference to @Devine Lu Linvega's Uxn suggests that your view of infrastructure is a bit different. Uxn is something I'd call situated infrastructure. It's for a self-selected community that wants to do things differently, and accepts being disconnected from mainstream society. That's one way to bring about change. But this approach requires growing the community and the infrastructure in parallel. You can't gather a community like FoC that's mostly founded on shared negative goals ("we are unhappy with the current state") and then expect them to agree on a common foundation for situated infrastructure.

Hmm… these are good arguments, but they don’t convince me. (Mostly because I don’t want to be convinced. :) Perhaps infrastructure you rely on in your domain should be considered part of your domain? Where and why draw a line? New infrastructure is built all the time. We call it platforms these days. And, yes, it partially hooks into existing infrastructure, which is a moot point, because it depends on where you draw the line of where infrastructure begins. There's always one level deeper that already existed and is built upon. And the whole interoperability thing is obviously not a binary situation. You can look at Uxn the way you do, and you’re probably right. Even I don’t agree with or care about many of the values that community shares. However, I’d like to think that I can look at Uxn as a motivating example for what a single individual / a small community can achieve with little resources and how it raises questions about if we really need all that what we have, take for granted, and consider infrastructure, and I can also be right. (Not that being right gets us anything important.) Infrastructure is just infrastructure because most of us agree that it is. And every piece of infrastructure once was a weird idea that “will never take off” and “will be impossible to scale”. Until it wasn’t. With our current culture we move towards more and more dependency on so-called “infrastructure”, just because it's convenient and all the people profiting from it tell us that this is what progress looks like. You can’t build your own house! Hire an architect and builders. You can’t write your own software! Hire a developer. You can’t cook your own food! Think of the cooks and delivery drivers that wouldn’t have a job if you did that. (The last one is weak; we’re still working on that one, it's not quite there yet, but give it a few more years.) I don’t want anybody here to agree on a common foundation for situated infrastructure. I would like for everybody here to think hard about what they consider infrastructure worth building upon, if it really does have to be that high up the stack, and what the reasons are why they think they can't go a level deeper. And if those reasons break down to just “it’s more convenient, because it’s already available”, then I’d like them to reflect on what that does to us culturally, and why we ended up in a world where nobody seriously believes they can build their own house anymore. Literally and figuratively.

My definition of infrastructure is: everything that I trust to be in working order for a long time, because a large number of people I don't know are committed to take care of it. That includes roads and sewage disposal (public infrastructure), and Linux (both the kernel and distributions building on it), but not Google Docs (which I have no reason to trust long-term) nor Uxn (supported by so few people that I can actually find out their names). Anything new is by my definition not infrastructure, it's at best a prototype for future infrastructure. We (the FoC community) could aim at building our own prototype for future infrastructure. Or resurrect prototypes from the past that didn't make it into mainstream (stuff like Plan9). I might even participate in such a project as a side project for fun. But my main use of computing is professional and I have to keep it accessible to and acceptable by my professional community, which is computational science. That excludes everything that doesn't run on off-the-shelf Linux machines, in user space. In theory, I agree with all your criticism. As an idealist, I dream of a similar world as you do. But if I want to make a difference in my work environment on the time scale of what's left until retirement, I have to focus on something rather than wanting to rebuild the world from scratch.

@Konrad Hinsen I’m in a constant debate about that with myself. Especially as I get older I’m worried I’m slowly losing that little bit of naive idealism that I have left and which gives me hope that not all is lost yet. Even though I mostly dislike the projects and startups younger tech enthusiasts jump on these days, for the reasons outlined above mostly about their “infrastructure” choices, I envy their enthusiasm for believing in just building anything you can dream of will make the world a better place. That is obviously false and proven so, but, man, was life easy back in my twenties when I didn’t care about that.

> Seriously? You know how to program. You know more than one programming language. It’s all the same anyway. What makes you think you lack competence in building anything you can dream of that is made out of code? "Seriously? You know how to write. You can even write in more than one language. It's all the same anyway. What makes you think you can't write a novel in any genre you can think of, or draft laws, or work in a programming language spec committee?" Hopefully this analogy shows the absurdity of thinking programming is all the same, of confusing the thing with the reductionist view of the thing. Yes, you can do with programming -- as with reading -- everything humans can do. But basic literacy is a very, very small initial step in doing it all. It's not just that @Konrad Hinsen has to build a network stack, it's also the display stack, and the font shaping and a million other things, each of which somebody built up a career around. I remember one Thanksgiving I was an absolutely terrible person to be around because I was trying to print floating-point numbers. > It reminds me of Christopher Alexander pointing out how our current culture has managed to convince regular people that they can’t build their own houses. CA looks to regular people (among whom I now number myself, now that I'm past my twenties) like this: imagine you're living in a little mountainside hamlet surrounded by towering peaks. Each peak has an aqueduct leading down from it, feeding the village with some different essential raw material. CA is up there on one peak saying, "hey look! I made it up so you can too!" He's right, but that's just one peak. What hubris to think I would want to go to the exact same peak as him?! You're not in my top 3, Chris. To do the thing he's actually suggesting, I have to scale all the peaks, rebuild all the aqueducts. I was even more ridiculous, way down on foothill Mu of some other peak, telling people everyone should be going off and building their own aqueducts for everything. I didn't even have the personal track record. I just muddied that one patch on the mountainside with all my attempts to climb a few inches. > Ivan Sutherland supposedly said about inventing the first interactive graphics program, the first non-procedural programming language, the first object oriented software system, all in one year with Sketchpad, “Well, I didn’t know it was hard.” Ivan Sutherland had one huge advantage: it was not infrastructure then. There was no shared expectation of the features it "had" to have. But it's infrastructure now. That train has passed. I'm starting to think depending on sharing infrastructure is the essential characteristic of human beings. It is what we mean when we say human beings are social. We build things, then we depend on them, and if enough people depend on them then we're stuck with them. Yes, one person can go off and choose not to depend on it. But: • It is impossible for a community to make those choices together without going off the reservation entirely. You'd start looking like a cult. You have to be willing to be seen by others to have joined a cult. • You can never be sure you'll suddenly find the need for some bit of infrastructure you thought you'd never need. Like that floating-point printer of mine. Every time that happens, I feel stupid, and then I realize how ridiculous I seem to others all the time. All this is not to say we shouldn't try. We should absolutely try. I'm still up there making a spectacle of myself on a slightly different spot. But it's important to be clear-eyed about the endeavor. Let's not kid ourselves that there's anything obvious or normal or easy about trying to replace infrastructure. It may well be a giant waste of time, a dead end on the road to finding a better way to live.

I was thinking of the other end, the (pseudo-)infrastructure users. The people who rely on some library and are then surprised when it no longer builds.

@Kartik Agaram

Hopefully this analogy shows the absurdity of thinking programming is all the same, of confusing the thing with the reductionist view of the thing.

I don’t think it does. And the point wasn’t to claim it’s all the same. My whole post was about the limitations we put on ourselves because of our beliefs. I sincerely believe that everybody can write a novel in any genre they can think of if they really want to. Nobody claims that’s easy to do, but if you know how to write you have all the capabilities you need to get started. And if you don’t believe that, then of course you never will.

CA is up there on one peak saying, "hey look! I made it up so you can too!"

That doesn’t sound right. If he was on a peak, and he’d say something, it would be more like, “Hey, why don’t you come here, or to that other peak over there? Just because people tell you not to?” Or perhaps he’s down in the valley on the market asking the people around him, “Hey, why don’t we all go up on that hill there together?" I see what you mean, but putting Alexander on the same level as the usual blog post that oozes survivorship bias is a grand mischaracterization. I obviously can’t let that stand uncommented. 🙂

Ivan Sutherland had one huge advantage: it was not infrastructure then. There was no shared expectation of the features it "had" to have.

I think this fits together with this:

Everybody is trying to create the infrastructure of the future, because we're all accultured to want to scale up.

Our culture pressures us into thinking that all we do has to have impact. We need to be successful. And that means scale. And that taints our perspective dramatically from the beginning, in the sense that we are trying to create infrastructure from the beginning, even though we kind of also understand that it can’t really be or that this is not our decision to make. We can only birth something and hope the world likes it. Or use marketing and social media to make them like it.

All this is not to say we shouldn't try. We should absolutely try. I'm still up there making a spectacle of myself on a slightly different spot. But it's important to be clear-eyed about the endeavor.

This seems to be a trait that is amplified in software people. "Here’s the truth: It’s practically impossible. But we should try anyway. But it’s never going to work." It’s analytical mind take-over. You should all be spending more time talking to artists. “And then I just tried this stupid thing and it turned out pretty good. And everybody else liked it too. I had no idea, I was just messing around — it just happened."

Let's not kid ourselves that there's anything obvious or normal or easy about trying to replace infrastructure. It may well be a giant waste of time, a dead end on the road to finding a better way to live.

You know what, screw this! Let’s kid ourselves! Let’s pretend we can just do a Sutherland and didn’t know it was hard. Why do we have to be clear-eyed? It seems that the clearer our vision is, the more likely we get stuck on how impossible it all is.

You know what, screw this! Let’s kid ourselves!

That's why my basic principle is that whatever I do in this field must be fun. If it fails, well, I have still had fun.

Just randomly found today. Seems to be illustrating something relevant.

I wasn't really talking about survivorship bias. Rather, in recent years I have a greater appreciation for why people aren't persuaded by CA telling people they should build their own house and "everyone should learn to code." There's a lot of things someone thinks everyone should do. If we were all right, it'd be too much! So it all seems like noise. If we programmers want to be playful, perhaps connecting with CA is counterproductive. There's nothing less playful than building a house. Particularly on a budget, and CA was always very concerned with cost, by all accounts. (Which is a very good thing for a builder to be.) I guess we'll agree to disagree on whether anyone can write novels. The word "can" is doing a lot of heavy lifting there.

@Kartik Agaram I’m ok to disagree, but I’d like to document for the people following this thread that one of us studied Alexander extensively and has read The Nature of Order (which is the most relevant work here) sort of several times now and one of us has not… :) And also there’s an important difference between “Everybody should build their own house” and “Everybody can build their own house”. Alexander mostly tries to point out what we can do even though we may believe it’s impossible, but he leaves it to us to decide if we should. Fascinatingly, software people seem to like telling people what they should be doing, while simultaneously telling them they can’t do it because it’s impossible (see above). http://nature-of-order.stefan-lesser.com/b2-c10-the-playful-core-of-the-matter

Why are you generalizing from me in one comment to "all software people"? 😛 I didn't realize CA was relevant to the "everyone can write a novel" sub-thread here. I think my primary frame lately is how to get to a desirable future. How best to navigate a trying present. Unfortunately I can't do it alone, and other people's decisions affect me (analogous to epidemiology). So yes, I'm simultaneously trying to figure out what I should be trying to do and trying to convince other (similar) people to do it as well. If CA is making a big distinction between can and should, he seems a lot less relevant to me at present. In general that's been my sense from this thread. I need to let go of some essays by Richard Gabriel I read in my youth.

Having read NoO, I feel like I must at least try to correct mischaracterizations. I’m not sure why I do. In a way that is, I guess, me also trying to tell people what they should do. I should really stop doing that. :) I wasn’t just pointing at you. I felt like the whole conversation had that pattern, and even if I remember that incorrectly, I still feel like that generalization seems valid. You can probably just open a random other thread and find the pattern there. It’s just so frustrating to see how we are always stuck on the what and the how, and we keep arguing on that level, and never really try to get at the why, the values that drive us, which seem easier (not easy!) to get at least some people to agree on. The what and how is so fragmented at this point that even people who fundamentally agree on the same values can’t collaborate, as @Konrad Hinsen described, and the way we argue about what and how we’re just digging ourselves deeper into our individual holes.

Ok, so all this is still relevant in a thread about goals vs solutions. I don't understand why you think we "never try to get at the why, the values that drive us" when "people who fundamentally agree on the same values can’t collaborate". It seems to me that people's values do shine through even in discussions about "the what and the how", and you seem to concur as well that "why" is roughly near "values", and that you're able to see people's values enough to see that they agree on them. So something here feels contradictory to me, and I don't see the goal/problem you're pointing at.. which, yes, must be frustrating! ❤️ (FWIW I can't mischaracterize NoO because I never characterized it. I only characterized CA. It seems fair to discuss other published work by him. I mean, when you introduce quotes by him I think they're not all from NoO, and you're trying to connect up with stuff in people's heads who haven't read NoO? At least he's said those things in other places. Anyways, this stuff is definitely getting off-topic here..)

In this thread I’ve been exploring to represent an approach more than trying to explain something. I was thinking more motivational, aspirational than “Let me tell you how it is.” I may or may not have succeeded with that. And between the lines I hope it is somewhat obvious that I’m massively struggling with taking the position I do here myself. CA changed his mind quite significantly over his career, criticizing his earlier works himself. And certainly if software people have heard of him and read anything from him, it’s much more likely to be Notes on the Synthesis of Form or perhaps The Timeless Way of Building (A Pattern Language everybody bought, but apparently nobody really read.) It’s natural, but I don’t think it’s fair to characterize CA based on his earlier works, when more recent material is available where he put a lot of effort into further differentiating and integrating what he has learned since then. It’s easy to consider an author as standing for something rather static, and often that’s probably okay, because many people don’t change their views much, but that I feel is a problem with CA. There is a lot of wisdom in The Nature of Order, which is harder to unpack and to share than knowledge. I guess that is what makes this work so difficult to embrace. You can feel him struggling when you read The Nature of Order. And a lot of the learning I got out of it is in the form of changing my thinking and my perspective, which seems to me much more valuable than collecting more knowledge (which is of course necessary too). Most people seek knowledge, not wisdom. Simple rules and principles and recipes that cause certain outcomes or at least make them more likely. Which is sad, because I think what we need right now much more is more wisdom, more knowing what knowledge to apply in which context and why. I don’t know how to teach people this, but I do know that Alexander taught me this.

This conversation is definitely bumping NoO up my reading list. Just to reiterate, though, I was responding to specific quotes you made, and not trying to represent everything CA did or stood for. It's hard to have a conversation about those quotes if that requires reading a thousand pages 🙂

FWIW, this thread has certainly influenced the post I published yesterday. I also wrote a draft about infrastructure, which is even closer to what we discussed here, but that one isn’t coherent enough yet to publish. Thanks for all the prompts and discussion here. It does help a lot to sort out my thinking.

The discussion on infrastructure looks like a good occasion to cite on my favorite concepts again: pace layers . In that picture, infrastructure is between governance (which regulates it in a more slowly evolving process) and commerce (which provides innovation from a faster process). In our context, "commerce" should be labelled differently, perhaps simply "technological development". A key conclusion is then that something that is not regulated cannot be infrastructure. As for Uxn that has been mentioned: I see it in the "fashion/art" layer (more art).

It does seem like we really look at Uxn differently. You seem to try to define what it is, I’m trying to point at what it stands for. In one of his talks @Devine Lu Linvega says something along the lines of, “I’m not telling you how I’ve done it, that doesn’t matter; I’d rather want you to feel inspired to do something similar.” I’ve never thought of Uxn as infrastructure in the sense of, “Come on, everybody, we're using this now!” I wouldn’t want to use it myself. I think about it as a case study in rebuilding infrastructure, and how difficult/straightforward that can be.

My view of Uxn is quite similar, I just don't call it "infrastructure". Infrastructure isn't designed, or appointed by some authority. Technology becomes infrastructure by widespread adoption and the subsequent creation of instutions that commit to maintaining it. Uxn, just like a new programming language or a new audio editor, is enabling technology. Technology designed for others to build on. The particularity of Uxn in this space is that it tries to escape from the dependency on today's infrastructure.

Summary: • Konrad Hinsen's interest is primarily what's relevant for his dayjob/employment, that's some coding/software done today to perform some tasks or obtain some benefits, not research towards an alternative future model as is not manifested yet, so no tasks performed or benefits obtained from an alternative future model yet. So no point in investing time/effort, as there's no ROI yet, if ever. • Kartik Agaram made strong repeated arguments for why we should stay with the infrastructure/model of today, and maybe just change/introduce a few small things here and there. Potentially for the purpose of playing around and having some fun. On the one hand, there's a problems extracted from manifestos "programming computers requires a lot of knowledge and effort", or "adapting software to ourselves is hard; few people do it", or "software is trapped in silos (apps) and can't be recomposed", or "software is inefficient and unstable because it's built atop a Jenga-like tower of dependencies", at the same time "reuse" of this existing software with MLOC (hard to maintain, hard to customize) is seen as necessary, and too that one can't or shouldn't try to replace it with a better alternative. Too, not wondering how it is that we can reuse the MLOC of databases, programming languages, web browsers, OSes, but can't reuse the few lines of our own across our projects, as dependent-on and written atop one of these. Then, why waste the time discussing these matters? Could be that it's just a statement/compilation of these manifestos and problems seen by others, not necessarily to agree with. Fair. Konrad had a good insight: "You can't gather a community like FoC that's mostly founded on shared negative goals ('we are unhappy with the current state') and then expect them to agree on a common foundation for situated infrastructure", or I may add, it's not about situated infrastructure, because there's many different situations, but ideally common shared infrastructure. Means, communities like this are not actually set up or trying to do something [together] about the problem, it just comes together to complain and lament (possibly because everybody has a different conflicting/competing approach, wasting the time trying to convince everybody else, who have their own therefore won't drop theirs to join someone else's). FoC itself may not have, may not need, to have any projects or work groups of its own, it's just an open conversation space where people can dump/promote what they're doing on their own. To actually seriously try to work on some better future of coding/software, this is a rather unlikely place per setup/goal, and likely a different community with a different setup/goal should be found or created, if there were a need/interest + capacity to work on this topic. I'm puzzled how there can be confusion about Christopher Alexander (CA here). He's an architect. Architects make patterns/blueprints (templates, class definitions). A builder or fellow architect can use these to produce/generate houses (object, instance or similar, following the architectural structures). The result is supposed to lead to certain properties and benefits. CA (as others) made a contribution and maintained a claim that his is somewhat more "healthy", more beneficial, than other such templates (consider brutalism, Le Corbusier modernism, which is a pattern of industrial mass production while on the other hand helps with hygiene, affordable housing, modularity, etc.). Critiquing CA to be overly dogmatic and insistent, that might not be too different from insisting that everything should be OOP, functional or imperative (be advised these are not architectures), or everything should be microservices (this one may be a single architectural pattern/style). CA did not do this, but made the case/point that if a more "healthy"/"regenerative"/nurturing architectural style/approach is ignored/rejected, you're stuck with houses that are not produced to be healthy for the human inhabitants (resulting in humans being less healthy, for no particular good reason). In this way, today's industrial production of houses (with no architecture or poor or unhealthy one) is seen as unfortunate, not great that it's dominant for profit reasons (cheap to make, health costs and damages externalized). So CA is about proposing and demonstrating + implementing an alternative model, which avoids and replaces the negative/unhealthy aspects produced by the majority of today's built environment. "Healthy" here not in an abstract sense, but in a very practical sense of un-social setup, leading to depression, discomfort, etc., these being scientifically measurable/measured. Like, the contrast between Le Corbusier's architecture for the health of the inhabitants and Alexander's is that the former's is mostly hygienic (scientific), while the latter's is "wholistic" by taking psychology, natural environment, etc. into account as well. Like, it shouldn't be too hard to see that Le Corbusier's has a certain lack of care for the focus on just the individual dweller(s) within their flat, and while there's shared rooms and public spaces and what not, these are primarily there as an "operational necessity" (my phrasing), you nominally give everybody minimal living space and a public shared space, but the actual priority is to industrially build lots of these to house many people, and how these interact together to form an environment is not of much interest, similar to the urban planning. If I'm not mistaken. So these architectures serve rather different purposes/goals, and therefore per their design generate different outcomes. May not be apparent or visible to regular people who are not architects. Users just suffer the damages and have to pay the price (for the enrichment of the builder), not really understanding why they're miserable, as the environment is seen as inevitable, natural and a given. But architects know it's just made up by someone for some goal, and it can, sometimes, should (ought) to be different. So OK can say it's the capitalist incentive to screw over the inhabitants to rob them for personal profit and the law of the market demands it, but then no need to complain if accepting this to be inevitable or futile to try to change to some better alternatives. Same with software architecture. Then too no coincidence Kay's pyramid vs. gothic cathedral, roman arches, etc. "Architect", in case it remains an unknown notion in software, is an "arch technician [engineer]". Not necessarily a master craftsman who is very good at stacking blocks onto each other, but someone who also knows how to use/apply physics to support structures that are several orders of magnitude more beneficial (both cost-effective and in use like enabling the aqueduct, eventually even trains can go over one). Is occupied with questions of what and how to build, or if at all, vs. what not to, and what impacts and properties the result will generate.

@Stephan Kreutzer

Means, communities like this are not actually set up or trying to do something [together] about the problem, it just comes together to complain and lament (possibly because everybody has a different conflicting/competing approach, wasting the time trying to convince everybody else,

That's a way too negative view in my opinion. Critique is the first step to improvement. Learning from others' critique is valuable. Good ideas from different situated contexts are valuable as well. I learn a lot here from people working on very different things. That's fine. Asking for constructive cooperation on our topic is perhaps premature.

OK, that could be the case. Originated from Oleksandr Kryvonos asking the question what this community is doing. The profile now says his account is deactivated, which is sad if that's the case. Also, I'm slowly catching up with listening to the FoC podcast episodes with Steve Krouse occasionally claiming to have a similar goal/ambition (while it sounded like more startup-oriented, more limited to teaching kids programming, tied to just Victor and puzzled-by/confused-about Kay), but I did not get to the point if/where he leaves. Dating back to 2017 (that's 7 years). What's missing to reach the required level of maturity? If ever? Is that even a goal? What are the immaturities that may (self-)sabotage any one of us? Given from the 2.903 accounts only <= 5 participate in this discussion (granted, most accounts might be abandoned), each of us busy/occupied with many other things and struggling a lot with the wider challenge already? OK, we do not need to entertain the illusion that many or any majority would agree/subscribe (or more importantly, contribute), so it's liberating and perfectly fine if at least a subset could work on these topics. Or if it's just lots of different situated contexts. These too can contribute a lot of confusion, disagreement and junk. Is fine if the conclusion to Oleksandr's question is that there's no shared, common goals, or no agreeable paths to work towards any of such goals. At the extreme, this might mean no two persons can agree on a single goal or any proposed path towards a goal, which ensures that none of these can ever be reached, other than by single individuals working on their own projects only.

Kartik Agaram made strong repeated arguments for why we should stay with the infrastructure/model of today, and maybe just change/introduce a few small things here and there. Potentially for the purpose of playing around and having some fun.

I'm not sure I'm interpreting this right, but I want to clarify. • I don't think infrastructure is inviolate and we should only build atop existing infrastructure. In fact all my writings are vehemently against this. • It is perfectly understandable why anyone might not want to try to change infrastructure. That's the reasonable default position. • If you're trying to change infrastructure and you don't understand why the existing infrastructure exists, you won't be effective at your aims. • On the other hand I can't discount Stefan Lesser's argument in favor of beginner's mind. It's just that I don't have beginner's mind, and I don't think it's something you can fake. • So what do I think we should do? My current answer for myself is: use as little infrastructure as possible and try to build what you need atop that, just for yourself. If it's good, your personal infrastructure will also become infrastructure for others. If it's not, well that wasn't the goal.

Why not simply explain why the current infrastructure exists [in part, that's why I ask for the why and what for the problems extracted from the manifestos] and what can be done about it in order to be effective for any related aim/goal? If not, stay with the current infrastructure, because it's there for reasons and little/nothing can effectively be done about it, so no reason to complain about the MLOCs and related problems of inspection, maintenance, customization, combination, etc. If the "why" is claimed to be inevitable or insurmountable, indeed it makes sense to just focus on some small things which are built on top of it.

I'll stop here. I can't think of any more words to clarify what I mean. I certainly don't have all the answers. But there's a difference between "x is hard" and "x is impossible". The latter is usually also a judgment on anyone who tries x. I'm not judging.

Yes, hard or impossible for reasons not described. Case closed.

Sure, you are certainly free to close any cases you want to close. I'm keeping them open. My reasons are described at https://futureofcoding.slack.com/archives/C5T9GPWFL/p1719411858348569?thread_ts=1717926129.937119&amp;cid=C5T9GPWFL.

I think it's just naive to assume that you personally have to know/arrive-at all the answers, and that you personally have to do all the work yourself. As you identified/extracted as a problem from the manifestos. You may not subscribe/agree with this problem, and be of the opinion that you can or should do everything yourself. Indeed, I too believe it's very hard if not impossible, I don't see why you would want to try nonetheless, instead of making it easier and cheaper and working together with other people, but to each their own.

I genuinely don't understand what you're disagreeing with me about, I just sense that you care very much about this disagreement. What should I be making easier and cheaper, how should I be working together with other people?

"Programming computers requires a lot of knowledge and effort" is one of the problems extracted from the manifestos. Do you agree with this assessment/claim to be somewhat accurate/true, or not? If so, you/we may ask, what makes it difficult? Any answers to that, or not?

> I just find it rather likely that the "future of coding" will look pretty much like the present (with minor variations). That seems like a reasonable conclusion. Your criticisms are valid, but I'm not finding them constructive. > Do you agree with this assessment/claim to be somewhat accurate/true, or not? I do, as stated at https://futureofcoding.slack.com/archives/C5T9GPWFL/p1718449988190349?thread_ts=1718448593.662299&cid=C5T9GPWFL > If so, what would you say makes it difficult? 1. Incentives 2. Dependencies 3. Intrinsic difficulty I think we need to tackle 1 and 2 before 3. I'll stop there. If you're still interested to read more, I've written a huge amount of prose and prototypes about this before (alongside the 3 other problems I mentioned in the link above), available in this group's archives at https://akkartik.name/archives/foc and on my site at https://akkartik.name. But I'm not learning much from our exchange except that you seem dismissive of this group.

Hmm, I see. In https://futureofcoding.slack.com/archives/C5T9GPWFL/p1718449988190349?thread_ts=1718448593.662299&cid=C5T9GPWFL offering another problem statement that seems to be (give/take) a summarization of the individual problems extracted from the manifestos. That you accept these is indicated by "*My* problem". Are you saying one is supposed/expected to 1. read the manifestos, 2. the works cited therein, 3. exported archives of this place, 4. your huge amount of prose and prototypes [and by extension, everybody else's as well]? Could you indicate which strategies your prior prototypes explored to improve on 1. and 2. and which you're planning to try in the future? Or point to a summary, write-up, article, list? Sorry to hear that you're not learning much. I'm still learning what is going on and isn't with you people. True, I'm very dismissive, as I've spent (= wasted) an awful, excessive amount of time with groups of a similar setup, which could never get their act together to do a collective thing, so for that reason I have little interest to repeat such a few more times, and rather find out quickly. Primarily, if there could/can be a different approach/strategy, which avoids the common and known flaws/mistakes and has better processes that lead to a better result/outcome. I don't think this is a contentious view. Based on past experience and empirical observation.

"groups of a similar setup, which could never get their act together to do a collective thing" = your goal, not ours I think!

@Stephan Kreutzer I care about some of those problems, yes. The ones I mentioned. I didn't summarize all the problems. It was unfair of me to point you at all of the FoC archives, I'm sorry. I didn't mean to imply you're required to read all that. It's more a resource. I don't want to monopolize this thread to talk about myself, a subject people here have already heard about at length. But I did earlier send you more focused DMs describing just one of my projects. I think that gives you a pretty accurate flavor of what I'm about. So to the extent you dismissed them, you're welcome to dismiss me 🙂 As Duncan said, it's not clear there's ever been any collective goal here. If you're looking for one, this doesn't seem like the place for it. There isn't a single different approach/strategy, we're all still exploring the space. While we're talking there's always hope of finding something that achieves consensus and inspires us to work together. But it does feel at times like waiting for Godot. I guess I'll go back to elaborate on my previous answer a little bit. That's not too off-topic here. >> ..what would you say makes [programming computers] difficult? > > 1. Incentives > 2. Dependencies Incentives: the computer industry arose out of a world war and early computers were huge and expensive things for countries or large organizations. That history still influences the industry. Our software was largely made in an industrial setting catering to the needs of companies. Making them easy to program is a low priority. Making them understandable to independent individuals on their personal computers is even lower priority. Dependencies: most software depends on lots of other software. Little effort has been made to keep things parsimonious. All this adds to the difficulty for an individual wanting to program their own computer. You can't just learn to do one simple thing, it pulls in a bunch of other things that you are at risk of needing to find out about when everything breaks. In this environment it's natural that most people throw up their arms and look around for someone to just give them something readymade even if it's partly or very remotely what they want. There are feedback loops between incentives and dependencies. Software has bloated dependencies because companies are able to hire people to care for them. Bloated dependencies perpetuate the way companies work and give them a reason for existence. This is why I work on what I work on. As I said in my DM to you, my vision for the future of software is: • tools built atop a stable stack with infrequent upgrades, • built durably to seldom update themselves, • always providing source code and infrastructure for anyone who wants to modify them. Durability and minimizing upgrades seem like good practical tests for the dependency footprint of a piece of software. If we ever get to a computer that requires learning a minimum of stuff to do something, we'll then be in a better position to tackle my third bullet: the intrinsic difficulty of programming for someone who doesn't seem to naturally enjoy it. But from where we are, it seems hard to even think about. You're right that my plain-text software is toy-like. But we have to learn to walk before we can run. I don't think we'd be in any position to manage say Xanadu-like hypertext until we fix the foundations I've described above. That's probably the essence of every disagreement in this forum and probably others: I think we all agree that all the problems everyone points out are problems. We just disagree about their relative priority.

This is good, constructive. Might be accurate and can be the conclusion that there is no shared effort. Might not be a goal here, despite Steve Krouse sometimes asked for one in the podcast, but seems he's not here anymore. Either was one of his personal hopes not shared by others, or simply didn't manifest for other reasons. Oleksandr asked for what "we're" doing here, not clear if that was about collective efforts, but seems his account is inactive now too. I was mostly asking, what if a new ARC/PARC/VPRI was started, based on the problems we agree on, and organizing around work-groups (or similar) trying/reviewing various strategies. It seems to be the case that we (or I) cannot find a single person in favor of this (and then too, a lot of work would come with this, and is uncertain if to any "success"(tm)). Also, I'm not aware that there's any place for such, given the earlier groups did shut down (for reasons/problems, = flaws in their setup, in my mind). Which is in part the reason why there's a need for a new one. Me being "dismissive" is mostly pointing out and probing into there being lots and lots of projects, programs, products, but no two are compatible. Adopting one for its functionality is at the loss of functionality found in others. Or switching back and forth, in the app silo model. Also means, future of coding is developing these separately, hard if not impossible to share code/solutions (other than re-programming). Problems and root causes like these. Additionally, I don't see much support that any guy who programs in one lang will jump and contribute or adopt some other guy's thing in another lang. Rare updating is one strategy, and especially cool if the software is relatively stable, not much to update as there's not much bugs to begin with. So more stable/reliable as a dependency/foundation. Could be an option to see if there's models for frequent updates, but these don't break things, so stuff can be modified and extended and it's largely fine. I have no strong position here, just attempting to add another strategy that could re researched, to counter the problem of breaking changes (which is what makes dependencies bad). Plain text schemes, it's not that I say it's "toy-like", as I'm largely unaware what your prototype is doing in detail (beyond format). It's more that I've many times complained about projects/people who do these as a strategy, because if it's say Markdown (or any other), that's somewhat limited to its domain of documents, and for their app on top each add some customization. These are not known nor shared by anyone else, because can't, per "design" (or lack thereof, as is natural/inherent with plain-text schemes). So I think it's should not be much contentious that this strategy doesn't help with some data exchange or compatibility (other than the lowest common denominator of just plain text, which is why people like/adopt it). I tend to probe in the reaction if I bring it up, and often people stubbornly insist that it must be their custom notation, expecting everyone else to adopt it. Or, sharing/exchange is not a goal there as well, and it's just personal note taking. Just adding it as another detail technical problem in design/impl, a source/cause for incompatibility, preventing shared use. No need to agree, of course. People can (and do!) "dismiss" what I'm saying here. Also, not necessarily about your prototype, but in general, but there's also plenty of people who run this as a strategy in general or limit theirs to just PKM. OK. This is a good description: many people here likely agree with some/most of the problems identified (which is why I was happy to catalog/highlight/promote these and pretty reluctant to subscribe to a particular or single solution/strategy that would require consensus/agreement on that as well). We may disagree about relative priority, but I think as commonly observed, far more agree about paths/strategies and possible solutions, as starting from the problem, everyone adopts/develops a different approach towards a solution, and very often (on the meta-level), these are incompatible, conflicting, mutually exclusive (either per design or by indifference). Resulting in many incompatible and no shared/shareable artifacts/mechanisms/etc. Hoping for consensus I find rather unlikely on the basis of these disagreements and sunken cost fallacy. I'm just wondering for some time if there could be a way to mix/adopt/port things on a granular level, which avoids the need for global agreement on a set of (potentially conflated) many individual points. One big shared project on the other hand is an option/proposal as well, if agreement/consensus could be reached, but here as well I don't see much indication that any number of people might enter into one. For example, some agreement on problems, but there's disagreements about goals. Because one general/open goal could be, "mitigate problems caused from dependencies", but that's not the goal you might commit to, instead, your goal is a particular approach/strategy for mitigation, the goal of "rare updates". Someone else who agrees on the general problem decides/d on a different strategy/approach, and the two of you may never agree. So I was just wondering for some time if it could work to agree on the problems as "goals", and then organize and try various approaches, ideally also to see if multiple could be adopted/mixed (if these work), or investigate which are good and which are anti-patterns or not practical or flawed. Otherwise, if you have an ultimate, absolute solution to most of the problems, someone else may have a different solution on one point or has discovered a largely separate set of other solutions, and fine, there's then never much agreement (nor shared work/efforts). It could be perfectly fine to leave it at that (I too don't want to monopolize 😞) and could wait if someone picks it up again, if ever.

@Stephan Kreutzer yes It’s not simple to go from information to experience and then even shared experiences.

🙂 everyone just has their own observations/views/experiences, and is not automatic/easy to discover shared overlap and differences with everyone else's (so the easy/quick way is to never look into it or even try to). I stay with just mine I guess? And the next guy with just his, and so on.

And the (software) world we have built, with all its fragmentation into factions of languages, frameworks, and architectures, ensures that we minimize chances to find probably much more common value overlap, as we tend to rarely look across the boundaries of our chosen preferences. See also: https://futureofcoding.slack.com/archives/CCL5VVBAN/p1720864532019509

You can operate in a shared reality from different assumptions. You can try to communicate with different media. My point is and was 🙂 that I don’t think that Text Chat as we use it here will help us individually to help us understanding us better collectively . Does that make sense @Stephan Kreutzer ?

Text chat - if there were a collaborative project, chat is pretty inadequate for keeping track, organzing, project management. It's some kind of "reverse Conway's law". With a setup that's only/primarily chat, that encourages talk and discussion, rarely to picked up again and often repeating. I think that's why Kartik searched for the manifestos, extracted the problems, I went towards making a document to collect and expand the points, towards a canonical intro/overview and maybe to register items thereunder, and so on. I don't think form, lack of tooling or medium is a huge limiting factor, as one can bootstrap from a napkin. Not ideal, but it's a viable start, to then improve and replace it several times. I would be worried if perfect tooling, ideal conditions, etc. would be considered a requirement for starting some work, because that may simply never come. If trying to organize to improve the tooling and medium, can't, because there's no good tooling/medium to organize that as well. It's a deadlock/catch-22/circular-reference situation, and instead (per Engelbart's example), simply bootstrap out and up from whatever. My frustration is not primarily with the form/medium. While that's bad, I think can be figured out and improved, already some simple measures help a lot. No, my frustration is with that there's a lot of talk about the great concepts, methods, etc. developed and demonstrated by other groups and the pioneers, but when it comes down to it, it's proven to impossible to find people who are 1. excited about these things and 2. more importantly, put some actual effort into trying. You make it sound as if calls/meetings, online or in-person, are inherently better (linear audio being not too different from text chat - might even be worse, because is temporal, Kartik could never search for manifestos someone mentioned). I don't have good experiences with calls, to the contrary. I'm not really aware what came out of our calls, I don't see there's much practical work/effort/results/progress in the project proposals we tried (or didn't try, failed to try). Alan Kay talks (PKM), book list (SVG), word list/cloud (duplicate). Finally, concluded with instead talking to the Weco people. Or similarly, the World Wise Web experiment, spending lots of time on meetings, ends up abandoned, even if you did went to their place (village) for some time, or attended their calls. I'll just repeat once again, go take a look at https://groupware-systems.org/skreutzer/online_collaboration_conversation_space.xhtml (+ a few more not on the list, notably Canonical Debate Lab is nice, just is a closed group), listen to all their meeting recordings, maybe even go to their/some place and meet them, talk some more, but I wonder what the results might be that you and me could use/adopt. Worse, theirs is unlikely to be of the kind I want (some better "future of coding", solving some of the problems we identified, they're not working on that as that's too a non-goal for them as well). In 2018 I attended the Doug@50 calls whenever I could, and because it was just meetings/calls, some prominent figures dominated the conversation (who weren't even much interested in the task, they were doing their own different thing instead, it's just these were more and louder). So the "group" (a bunch of individuals who disagree) couldn't arrive at agreement/consensus, the attempts to make something shared was sabotaged, all efforts got scrapped, and everyone continued with their own thing (mostly what they were doing all along anyway). For that reason, I reject it as a model as I don't see it working. I should add, I'm also employed on a dayjob, and there I do have meetings, both in-person and online, and I can assure you that generally, most of them, are very ineffective, dysfunctional or counter-productive. There are some positive cases, and that's mostly per pushing for more effective meetings/conversation (written agenda upfront, some moderation to stay on topic, written protocol, later working from the written protocol, etc.). While I'm not that good with that myself, at least I'm asking for it, while many don't agree and seem to not mind wasting lots of time (as evidently, no need to work and paid anyway, talking is cheap and easy). Ironically, such meetings are sometimes conducted by product managers or project managers, who really should have an interest to more effectively manage their projects and meetings. But this might be the case because they don't/can't do the technical work themselves, so they do organizing/meetings. Also, there might not be much training/courses for effective meetings or project managers, I can imagine some simply slip into the role, even if not really good at it. Now thinking about it, while text chat isn't great, our discussion here might have been better than if it were a call or meeting, because everyone can jump in, pick points, we can (and Kartik did) extract some items, at least there's more/better chance to organize, I learn things and have time to consider/think-about. I want to recognize that Stefan Lesser suggested a meeting in person. OK, might be fine, as are calls or text chat, if you need to and can't do better. This would exclude everyone who can't be at the place in the time. Who knows, seems there's a bunch of Germans, that might help to meet locally. At the same time, there's a German meetup, and I wonder if you people attended these, what's discussed there, if any of that is towards some kind of shared project, and if it where, what is it, where is it? Is it hard to find out about it, if not attending in person? Then, what good is it? (per the method of not using software, the computer, the network, this is kind of anti-thetical, doing it like the since the beginning of time). Like, what is the plan for how to go about those who can't be there? Exclude, ignore? To me, these modes are not a good/better experience either. To really highlight the source of my frustration (might not be yours/shared): form/medium/modality/tooling is secondary (and improvable), but I don't see why or what for we would meet or start calls, given we already found out (with the help of primitive text chat) that most of us have very different goals (incompatible ones). While we agree on the problems, we're not going to constructively address them in a shared/collective manner, as the intention/choice or capacity or constraints (various other factors), that's the status quo and not much chance/interest to change that. So why or what for would we call or meet? Continue with the disagreements and conflicting choices of approach in person? Adds some cost/effort with no upside/gain? In a call or meeting, I would once again just repeat something like the book list metadata project. Or you and Kartik could meet/call and start a project to import each other's custom Markdown (and then do that with a third guy's and then a fourth's). Or you don't and you each stay with PKM only. Or it's just exploration/prototypes but a plan/architecture/system we don't have nor make. idk, I think I could live with text chat, online calls or in-person meetings. Would be perfectly fine if I organize some notes just for myself, tracking and review etc. (nobody needs to adopt, if no interest or don't see/get any benefit out of it). For as long as there were some actual work/research in a compatible manner and not only conflicting/individual. Otherwise, why even chat/call/meet about it? If nothing is done about the problems identified, which works across projects/software/people, future pretty much won't be much different from the present or past. I don't think the amount of talking or medium makes a huge difference, if there's not much of this kind of work done. I just realize and once again repeat: no, I don't want to sink again lots of time into just talking about some proposal or this or that or read or write many more manifestos and some articles or whichever repo (you can rarely make much use of), absolutely not. I did try/do that several times and I don't see why a few more times repeat the same exercise. As you see, I rather try to "speedrun", check see and probe what people are up to or not, I think I was relatively efficient to learn a number of things about FoC participants and community and it's setup and goals. To do something different is probably to not do a/the FoC thing, but see if something else and different could be done. I framed it various times as a new ARC/PARC/VPRI, specifically to avoid the effects observable here, and OK struggle if not outright impossible to find some person who's in favor of such and follows up with trying. So what to call/meet about, about this? Again? I may add, reading curious-reader's posts here, if I'm not mistaken, your requirement is that some source should drop a lot of money to fund such research/effort. Which didn't happen and likely won't. Also, not indicated what the money is even needed for and spent on. I assume, burn it on salaries. Of course, funding drying out is what killed ARC, PARC and VPRI. I don't think it's realistic nor desirable. But if that is a pre-condition, fine, it may just never be met, and then what to even spend/burn it on. Could be another difference that I don't have much time, in general and then for being busy with too many things (as it's all a lot of work). Given not much exists and is reusable, and lots of time sunken/wasted on the poor state of what makes the present. So I'm glad about things that save time, capacity, and against sinking/wasting/spending much more than already.

@Stephan Kreutzer I feel like I understand you better after https://futureofcoding.slack.com/archives/C5T9GPWFL/p1720861284444429?thread_ts=1717926129.937119&cid=C5T9GPWFL in particular. It sounds like there are 3 positions here: 1. It is fine, good even, that everyone is working on their own thing and using this among other places as a clearinghouse to share progress. (Not necessarily a position anyone is taking, but we kinda default to it by our actions.) 2. We've spent a lot of time here talking about solutions without triggering any collaboration, but we haven't tried talking about problems nearly as much. There might be some hope of collaborating if we do so. (@Stefan and I are advocating for this.) 3. The only promising avenue is to spin up a new research lab like PARC or VPRI. Only then will people actually collaborate and not just talk about collaborating. (@Stephan Kreutzer you're advocating for this) Does that feel like a fair summary? The third approach has been discussed a bit here. Not a whole lot, but I can dig up links later today if you like. Then again, I feel you'd say there's nothing to be gained by discussing it, only doing. The problem we run into is that doing it requires funding, and nobody here seems to have the skills for fundraising. So it seems infeasible. (I also have doubts about whether it's the right approach, but they don't matter since I can't influence the funding.)

I’m interested to talk about values. Problems are a good starting point to get to values, certainly a much better one than talking about solutions. Put simply, talking about solutions keeps fragmenting us into factions of technological particularities. We nerdsnipe each other into taking sides about minute implementation details. That's ok; we all love that stuff, that’s why we’re here. Values, however, have the chance of uniting us across the boundaries of our preferences. Ideally, they foster community by highlighting what we can agree on and helping us connect to each other. Even though we cannot understand why that guy can’t get over his obsession with Scala, which is clearly the wrong tool for the job, he's coming from the same place as we are. Talking about values is a social activity to explore and discover each other's motivations and what is important to us. That's also why I believe a synchronous, in-person meeting is more suited to this, as it’s more about connecting to each other than about collecting facts in a spreadsheet. Coming to it with a results-oriented mindset is going to make it feel very unproductive and inefficient. Trust the process. :) Setting goals and defining strategies to achieve them is absolutely something values can support, but this has to come at a later stage, separately. To get to meaningful values, people need to be open and willing to listen, leaving space for things to emerge. That’s why I believe we shouldn’t even attempt this without a dedicated facilitator helping us stay in that mindset.

Yes values get us into a more interesting territory IMO

@Stefan I like that -- with one caveat. I care about values here to the extent they get us working on solutions together. Many of us bring overlapping values and solutions to the table. The goal for me is to converge on solutions based on a common set of values.

BTW, here’s what I mean when I talk about values.

Yes I was quite interested in Joe Edelman’s work on meaning. So Andy asked him and we had a session at kernel:

Hi — just barging in here to break some china. I'm thinking about building a replacement for slack as the hub of the community. I'll put in the bulk of the effort, but would love to (a) get help from other folks here in the community, and (b) build something that other folks can easily hack on top of. Maybe it'll fit some notion of "infrastructure", who knows. Also, while I haven't read any Christopher Alexander, my wife and I did in fact build our own house. (Well, designed it, did the CAD, built all the cabinetry, did the flooring, etc. But we hired dudes with cranes and insurance and drills and cement trucks to do... that stuff). So hopefully I'm joining the tradition of people named "Ivan" who don't know how hard something is. Let's see if 1% of folks come out of the woodwork and this actually turns into a decent initiative.