I find my self nodding a lot reading through it: https://xyzzyapps.link/wheel/why.html

I briefly looked through the “Code Walkthrough” of Plannr to get a better understanding. I wonder how you can get different perspectives on code besides chapters and pages.

Thinking in books: I understand that there is a table of contents and a linear flow through the book. There are also links. Is there also some sort of Appendix, Glossary or other forms of organization possible? For example, I found a couple of code snippets called “Websocket Reply Handlers” that contained message types and handlers. I could imagine an index of all those that link to their implementation. Would that be possible / how would you set this up?

In the original implementation cweb extensive cross referencing capabilities are provided but yes there could be other perspectives on chapters. You can get cross references with this tool. My current notion is 1 chapter = 1 use case or 1 complete feature with backend, frontend and tests.

Thanks! I really find this whole idea super interesting. I’ve been keeping a written log of my programming progress with notes about features, implementations and screenshots. But linking that with actual code would be interesting. I believe a lot of challenges from coding comes from the lack of Organisation and verbalisation. And as described here, files/folders aren’t enough and seem to be rather hacks. I like that in Processing (.org), you can create “tabs” when a single code file gets too long. You create a tab inside the IDE but that tab isn’t a new file that you need to import. It is just a new “snippet” that will be appended together with the other tabs. I wonder: is Observable another example of literate programming? https://observablehq.com — I do have to say that your examples are better, because they have a table of contents! 🙂 In general I think that lists, maps, and other designed forms of access to code are really needed in contrast to just files, folders and naming conventions.

I haven’t used observable but I have used python notebooks. I think nbdev comes close to literate programming. The difference lies in the flexibility of organisation and arbitrary reordering. In literate programming you define chunks that can be reused wherever you want, whether in docs or code. If observable provides a named block that can be referenced and embedded anywhere then it gets close. I would emphasise that this is production code, not just examples which blogs and notebooks are typically used for! Personally I find literate programming for noting down 1. todo’s 2. bugs 3. bookmarks 4, design decisions and history 5. build commands 6. tests

This episode was really weird to make.

I went into it a goal: to push the conversation in unusual directions. Most interviews are just a rote review of the guest's past work. I want to get the FoC podcast away from that. Instead, I'd like the show to be a place where the guest is challenged a bit, where they have to reflect on their work, turn it over, look at it from new angles. I think that'll raise both the hit and miss rate of the interview, but I can cut out the biggest misses in the edit (I've been doing that all along — typically about 10-20 minutes of each recording session never makes it into the episode). I think it'll give the show an interesting energy, something that interview podcasts tend to lack.

Toby... might not have been the best person to try this with. Or maybe he was the best person, it's hard to say. Toby does a thing that I wish more people did — when you ask him a question, he pauses and thinks about it for a good while. Then when he talks, he frequently pauses mid sentence, thinks some more, and then continues. It's a really admirable quality. He had no difficulty calling me on my bullshit, whenever I posed a question with inbuilt assumptions that needn't apply.

But... this meant a lot of dead air. A lot! So in the moment, recording with him, thinking to myself "I'm trying to push this podcast in weird directions", confronted with this copious dead air, I found myself dreading "Oh no, I've pushed too far, this is going badly, this is why nobody does this."

So at the end of the interview, I feared the worst. But, thankfully, after the edit, with most of the dead air tightened-up, I think it came through okay.

Anyway, that's a bit of behind the curtain drama. I'm going to keep pushing myself to get more energy (and weird energy) from the interviews, and we'll see how it goes!

Spunds cool. Can't wait to listen

That sounds cool indeed. Have you tried descript? Haven’t used it myself but seems like a cool tool for your editing work

I've played with Descript a bit. It doesn't quite fit with how I like to work, and the transcripts it produced weren't any better than what I get from Rev (read: almost unusably awful). But there's a lot of effort being poured into that tool, so if that holds I'll probably slowly use it for more stuff as time goes on.

I do all my audio editing in Ableton Live, because it's the fastest-feeling audio tool I've ever worked with. (I've recorded around a dozen albums, so.. my list of tools-worked-with is long.) Ironically, it's kinda pokey at podcasts — it's too freeform, where a little bit of additional structure (like what Final Cut gives you, say) would probably make things a go more quickly. But that's a tangent for a whole other thread!

Cool, thx!

Ivan Reese when I was a guest in a podcast they sent me the topics/questions beforehand to at least think a little about the answers. Do you think it would make it less interesting? do you come up with most questions on the fly? (the ones I was on drifted from the original questions a little too)

I love the question about subtractive, sculpting programming models at 55 minutes

An alternative subtractive model to conditionals may be replacement. A recursive drawing where you replace alternate circles with squares, say. But you could build that out of a primitive containing a single circle and square. Hmm, perhaps additive is good enough, and subtractive effects are a matter of tastefully choosing boundaries between primitives.

Every primitive you draw in recursive drawing could be seen as sculpting away all of a layer except for the shapes.

Besides the amazing work of Toby, I found the episode really interesting and didn’t notice any pauses. As an interviewer, your did a lot of preparation / research beforehand which enables a lot of questions that go deeper than usual. I think the interview was very honest und humane. It also gave insights into his thinking, more than just thought out solutions and also provided insights into other communities and tools that some of us might not be aware of. Thank you!

Mariano Guerra — I might try sending a few questions in advance; it could help add additional texture to the show. Certainly not all of them, as I love hearing someone go through a realization right in the moment. I come up with questions in advance, but I don't stick strictly to them. I also try to come up with about 2x as many questions as needed, and only ask the ones that would work best in the moment.

I think the right balance is sending the topics so they can think a little about it but add the spontaneity of fresh questions

Then it's just a matter of writing some questions that benefit from each approach.

also Mike Tyson rule on podcasts: everyone has a plan until they get punched in the face

@Florian Schulz thank you! Yes, I do about 10 hours of prep for each interview, and then about 20 hours of editing after the fact. The pauses are all ironed out in the edit. I'm still learning how to tighten the pacing without making the speech sound unnatural. Getting better, but still not perfect. Same goal as good special effects in film: you shouldn't notice 99% of the work. (Hey, that's a podcast.)

Guess I'm going to be getting a digital cutting machine soon.

If you watch APL programmers, I think they exhibit a lot of this subtractive thinking. They often start with a solution and then spend time reducing the symbols. Not as a golfing exercise, but for performance and understandability.

Ivan Reese FWIW, it's certainly my experience that Toby has a slow, thoughtful conversational style. That style was the general norm around CDG/Dynamicland when I joined – not sure if it grew lab-to-Toby or Toby-to-lab or both. I came to really appreciate it, but it took some getting used to, and until you're used to it, it can be very uncomfortable. So it makes sense to me that you felt unsure about how the interview went. (I thought it went well.)

Ivan Reese you kind of mentioned it but on the additive/substractive conversation my thought was: you add in "cyberspace" (Cuttle) to substact in the real world (material)