Gregory's ServerI wonder if this is the major reason to huddle together on top of jenga stacks with tons of dependencies, terrified of fragmentation: You always need more testing than you think, and there's no way to compete with something that's been through that much testing.
|
13 comments
  @TodePond I think I do tend/try to have that same mindset you call 'tadi'. Just not necessarily related to the web or websites. It's a good reminder, though. Thank you. Perhaps I need to let this whole approach die. It's centered around a text editor widget with 100+ tests to handle line wrapping, mouse clicks, easy splitting and joining of wrapped lines. @TodePond As an example, one bit of ugliness is my model's cursor x/y coordinates are saved while drawing each frame, and multiple bugs have arisen from something happening quickly without an intermediate frame to update the coord. Yeesh. @akkartik i do have some thoughts on how your approach differs to the tadi approach - because i was thinking it through a lot when i was first trying to formulate the style. there is a lot of overlap of course, and i took on a lot of your approach as inspiration (by definition, the tadi web needs to be compatible with every kind of "better computing" including yours) @akkartik this is how i see it (correct me if I'm wrong): you take "zero dependencies" seriously because you see the downsides of dependencies. the tadi approach sees that too. you try to get around that by taking the noble pursuit of building and re-building an entire stack of tools, which is really really hard. the tadi web gets around it by not needing dependencies in the first place. or if it does use a dependency, it's easily discarded and replaced or re-built. continued... @akkartik the downside of the tadi style is that you *can't make everything* with it. some things you have to sacrifice being able to make. but the positive is that you're not dependent on any 'dependency' in your approach, i see you still have dependencies - it's the ones you build for yourself. even though you don't use someone else's dependencies, you end up stuck with your own stack, which is also hard to support, just like a dependency. continued... @TodePond Not harsh at all! I think we're pretty close here, and it feels good to see my values reflected back to me. Sacrificing ability to make some things -- 💯 Using easily discarded dependencies -- 💯 Building an entire stack -- more true of Mu than my later stuff. Lately I think a lot in terms of Wardley Maps, they help me realize when I'm growing over-dependent on something. And it's led me to try to branch away from LÖVE in the direction of exaEquOS (Lua+JS) and Kaboom/Kaplay (JS). @TodePond So I think we're entirely (?) in agreement on what we value in principle, and we're trying out different trade-offs along a shared spectrum. Certainly this periodic concern of mine about testing is nudging me closer to your current location on the spectrum, with less custom code. @TodePond Oh I see a disagreement. I've been gravitating towards durable software as a value, which is perhaps anti-tadi. Depends on what "die" means to you here. I imagine "the Way" as emitting a trail of programs. Each program might be on a trajectory of ossification but still be usable long after it freezes. @TodePond My hope/dream is that in the FoC/Merveilles/TodePond/Ink&Switch/Handmade/Mastodon nexus there is the beginnings of a scene akin to the one around Gertrude Stein's Salon in pre-war Paris: https://en.wikipedia.org/wiki/Gertrude_Stein#27_rue_de_Fleurus:_The_Stein_salon A scene will have inevitable disagreements. But hopefully this ferment is leading somewhere with answers. |
I come stare at this abyss every year or two.
https://merveilles.town/@akkartik/108051805903874429
https://merveilles.town/@akkartik/111517545303519402
Doesn't do me any good, though.