Gregory's Server@TodePond I'd definitely love to hear those thoughts <3
|
7 comments
 @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. |
@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...