You are viewing archived messages.
Go here to search the history.

xyzzy 2021-07-19 23:24:52

Hi all, this is my first post here. Ever since I saw this literate programming talk I have been messing with existing literate programming tools. After trying multiple tools, I ended up writing my own tool using python + sphinx + cog + markdown. I am calling it wheel.

Because of cog - I believe literate programming can enable many interesting things like arbitrary preprocessing and code generation instead of just mangle and tangle. In plannr I have experimented with adding some syntax to hylang, a dialect of lisp. I think literate programming is criss-cross programming 🙂 and enables feature driven development. I have documented my findings here https://xyzzyapps.link/wheel/why.html

Would love to hear you guys think!

Links

1. Wheel - a literate programming tool with python + sphinx + cog + markdown.

  1. My main app Plannr (currently beta) and the literate documentation for it. Source code inside the documentation.

  2. My music making app Bitrhythm and its documentation

Florian Schulz 2021-07-20 10:31:41

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?

xyzzy 2021-07-20 13:06:01

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.

Florian Schulz 2021-07-21 09:53:08

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.

xyzzy 2021-07-21 10:59:56

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

Ivan Reese 2021-07-21 02:31:22

📡 Future of Coding • Episode 51

Toby Schachman • Cuttle, Apparatus, and Recursive Drawing

In this episode, I'll be talking to Toby Schachman, who many of you are surely familiar with thanks to an incredible string of projects he's released over the past decade, including Recursive Drawing back in 2012, Apparatus in 2015, and most recently Cuttle which opened to the public this past week. All of these projects superficially appear to be graphics editors, but by interacting with them you actually create a program that generates graphics. Their interfaces are wildly different from both traditional programming tools and traditional graphics apps. If you are not familiar with these projects, I strongly recommend that you actually go and play them (they all run in the browser), or watch the Strange Loop talk where Toby demos Apparatus and explains the thinking behind it.

(And if Toby's work still doesn't ring any bells — he was also at Dynamicland, and CDG before that. Heavy hitter!)

This episode was sponsored by Glide, and the transcript was sponsored by Replit — thanks to them both for making this possible!

The show notes and transcript are available right here: https://futureofcoding.org/episodes/051

Meta-commentary in the thread.

Ivan Reese 2021-07-21 02:50:21

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!

Jean-Louis Villecroze 2021-07-21 03:34:17

Spunds cool. Can't wait to listen

Yousef El-Dardiry 2021-07-21 06:08:41

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

Ivan Reese 2021-07-21 06:10:14

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.

Ivan Reese 2021-07-21 06:18:19

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!

Yousef El-Dardiry 2021-07-21 06:42:17

Cool, thx!

Mariano Guerra 2021-07-21 08:02:28

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)

Kartik Agaram 2021-07-21 10:39:29

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

Kartik Agaram 2021-07-21 10:52:06

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.

Kartik Agaram 2021-07-21 10:58:35

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

Florian Schulz 2021-07-21 12:45:30

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!

Ivan Reese 2021-07-21 14:31:58

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.

Mariano Guerra 2021-07-21 14:33:58

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

Ivan Reese 2021-07-21 14:34:39

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

Mariano Guerra 2021-07-21 14:34:51

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

Ivan Reese 2021-07-21 14:35:37

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

William Taysom 2021-07-21 15:43:29

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

Chris Granger 2021-07-21 18:43:44

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.

Joshua Horowitz 2021-07-21 20:22:17

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

Mariano Guerra 2021-07-22 07:46:03

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)

Shubhadeep Roychowdhury 2021-07-22 14:23:48

I just wrote a blog post about implementing a simple, general purpose state machine in Go - https://towardsdatascience.com/writing-a-finite-state-machine-in-go-e5535e89d615 Would be great to have feedback