Email or username:

Password:

Forgot your password?
12 comments
Kartik Agaram

@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.

Kartik Agaram

@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.

Lu wilson

@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)

Kartik Agaram

@TodePond I'd definitely love to hear those thoughts <3

Lu wilson

@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...

Lu wilson

@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...

Lu wilson

@akkartik i hope it doesn't come across harsh or anything - and the tadi approach is far from helpful or realistic in many ways. these are just the challenges i see you tackling and figuring through, and im really happy you are doing that :)

Kartik Agaram replied to Lu

@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).

Kartik Agaram replied to Kartik

@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.

Kartik Agaram replied to Kartik

@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.

Kartik Agaram replied to Kartik

@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: en.wikipedia.org/wiki/Gertrude

A scene will have inevitable disagreements. But hopefully this ferment is leading somewhere with answers.

Go Up