A lot of us here have projects that we are working...
# thinking-together
j
A lot of us here have projects that we are working on. Or ideas we'd like to see become reality. But I'd bet that many of us feel we haven't been able to get things to be the way we want them. Maybe we make prototypes and they fall short of our goals. Maybe we can't express our ideas well enough. Maybe we never put the ideas in any tangible form. I'm curious about everyone's thoughts on if there is something that could be done about that. Could we as a community help? Is there a structure that you think would help? A societal change? A personal change?
c
"Willing into the world" is a rich vein As a writer (er, writing type, as I am not a productive writer), words come immediately to mind – I know many of us take private notes, and feel in those a power that coalesces energies – words themselves have a summoning power – they build a trail, sometimes in front of us, sometimes breadcrumbs, of what we intended and might actually still do Related tangent – I've wondered if there should be a much wider notion of "two-minute-week" – for instance, I'm not ready to post videos and show+tell – but would I post a little microblog update? No, because I'll just end up talking in a private sort of language that no one understands. But should I do that anyway? Think about the original twitter status update, how it was a still-undefined format. Lunch and what's on tv and headed out and reading X, all became the first announcements. There weren't pictures of peoples' lunches back then! Would it be bad to post something here in one's own private sort of language? Could it still bear fruit? "I'm adding [complex whatsit] to the [no idea] area of [unannounced project]. Feeling stuck with [phrase you might actually be able to parse and mention something for]."
👏 1
p
For me, personally, one of my biggest obstacles is the general lack of guaranteed proper tail calls in most programming language implementations. There's work on getting them added to WebAssembly, but I cannot grasp why they weren't there to begin with. They were added to JavaScript, but they are not widely implemented. And the languages that otherwise might function as portable assembly, such as C and Rust, have no intention of adding them. I cannot grasp why anyone would ever want to create a new language without tail calls, and yet following the programming news one constantly sees people announcing new languages that they somehow believe are better than what already exists even though they have the same limitations around flow control as most other languages since Algol 60. The biggest thing I would ask of the community is to join me in lobbying every single language creator to PUT PROPER TAIL CALLS INTO THEIR LANGUAGES RIGHT FROM THE BEGINNING! And yes, it needs to be right from the beginning, because if you don't plan for it you will create a design that makes it very difficult to add later.
1
👏 1
n
@Jimmy Miller For me, a good first step would be to put together a "design team" that can butt heads and figure out the right design for a future programming system. The team would consist of people who are willing and able to work full-time (or thereabouts) on building the FoC, whilst being self-funded (i.e. unpaid) and perhaps eventually crowdfunded. This is the only format (apart from a company) in which I can see a collaborative effort succeeding. We need to bring people who have the time to work deeply on the problem into the same room (or at least, the same Zoom).
d
completely agree re: needing people who are able to work deeply in a post-capitalist world, this would in theory be pretty straight-forward (depending on where we land post-capitalism). but here in capitalist-land, we do have the crowdfunding route as an option. not a great one, but it has occasionally worked.
1
j
I don’t think that not succeeding is bad. It has the potential to start an experimental creative cycle: 1. Choose or create a “cybernetic environment” (environment capable of running programs). 2. Make some (even small) experiments inside it -first, define their ideal form, then implement them. Involving wider spectrum of people is encouraged. 3. Analyze the shortcomings of the implementations w.r.t. the idealized versions. What aspects of the environment were limiting? 4. Create a better environment. Repeat.
Smalltalk was meant to be such an environment, but as Alan Kay reported (regretfully): “Smalltalk stopped changing” -meaning that people continued to do “experiments” (in this case, production-level programs), but stopped analyzing them w.r.t. the environment.
w
A place like Recurse Center with a stipend. 2 - 6 months of solo work would be enough time to prototype virtually anything. I think everyone here just needs more time to work and it's difficult to do that with a day job/family/financial obligations.
n
2 - 6 months is enough time to develop a prototype if you already know what needs to be built. But that's not the problem I (and many others) have. The problem is figuring out what needs to be built — design work, rather than "coding" work. Finding the right design for a programming environment could take years (evidence: I've already spent several years on this, and @jonathoda has spent several decades). A small fraction of that time would be coding, but most of it would be designing. IMO design work is the main thing our community should aim to support.
j
@Nick Smith I think that it's not necessary to get stuck on environment design right away (perfect is one of the enemies of WIAN). It's better to just get started with a suboptimal environment, then identify it's (concrete) limitations and fix those. After a while, some of the design will fall out for free out of the experience - at which point, one can rethink the environment to increase its cohesion.
1
y
something my art/tech friends and I do that helps us move from idea -> prototype -> more has been a pretty banal but powerful ritual we call story club. At the basis, a weekly zoom share out of a story (read: really anything, big or small, that exists in a sharable state) from everyone there that the only requirement for is that it was worked on inside that week. Then everyone goes around and shares an inspiratory item/idea that they found that week, with the goal being to spark discussion and to bring ideas to the front of mind for the following weeks work. Recently we have been making every other weeks meeting a working meeting, gathering in my apartment a few hours before the call for breakfast and to work in tandem. That’s all to say, I’d love to see something similar in this space, and I understand that FoC projects do require a good bit of thought/execution time, maybe such a club could put people into a place where they could then go to recurse and run up a pretty legit prototype
m
@yeT which changes would be required to #C0120A3L30R to be closer to what you describe?
y
I think an element of synchronicity, maybe a sort of historic sharing log, some sort of template of [shared thing: thing, inspiring object: thing]. Maybe a record of projects shared with their entries, allowing folks to see what other people are working on and the progress made. Maybe an associated gather/zoom setup could be helpful for working days
n
@Jan Ruzicka FWIW, because I've mostly been designing a language, and not an app, I've not actually needed to build any working prototypes to complete my design iterations. It's always been sufficient for me to simply write down a small program that embodies a design idea, and manually evaluate its syntax and semantics. That saves 100+ hours building a parser, interpreter, and/or IDE. Once I've settled on a complete set of language constructs (and a syntax) that can be used to build complex programs, I’m sure I will need to build an interpreter. But that would be at a very late stage in the design process. So it's really not coding that has been slowing me down. I've almost never gotten “stuck” during my design work such that I've needed to write an interpreter to proceed. People who are doing interaction design, e.g. designing structured editors, would obviously need to write code more frequently so that they can test out the interactions they have in mind.