Back to the talks Previous by track: Gardening in Emacs: A Windows user's tale of tending, tweaking, and triumph Next by track: One year progress update Schemacs (formerly Gypsum) Track: General

Bookclub tapas

Maddie Sullivan (she/her) - IRC: ElephantErgo, https://ElephantErgonomics.com, hello@ElephantErgonomics.com

Format: 32-min talk ; Q&A: BigBlueButton conference room Etherpad: https://pad.emacsconf.org/2025-bookclub-tapas
Etherpad: https://pad.emacsconf.org/2025-bookclub-tapas
Status: TO_REVIEW_QA

Talk

00:00.620 Introduction 00:29.680 Hi, I'm Maddie! 01:03.840 Bookclub Tapas 02:00.520 Bookclub 02:40.300 Too many hats, too many roles 03:55.800 Narrativiation 05:24.780 My starter kit - My stock, off the shelf suggestions 05:47.660 Now what? 05:58.980 Our overarching goal 06:23.460 Our development focuses 07:05.120 The rest of the headings 08:37.980 Conversationality 10:55.480 Ad-hoc means lesricsf tion 13:01.920 Gratis documentation 14:48.440 Keeping the thread of your intention 16:21.500 Bookclub is becoming too much 17:25.240 Introducing Tapas 18:22.840 What are Tapas, what are Tapas not? 22:25.180 Tapas are maybe best illustrated by example 25:52.340 Introducing Squint 28:36.100 What else does Bookclub Tapas do? 29:08.160 Let's work together

Duration: 31:25 minutes

Q&A

Description

I've been experimenting with a new programming methodology that I've stumbled upon. I call it "Bookclub Tapas". It is comprised of two parts, "Bookclub" and "Tapas". Together, they form a literate-inspired, Agile-inspired development method which centers around developer self-reflection as a means to chip away at identifying powerful custom-fit abstractions.

Bookclub turns literate programming on its head by having the target audience of the source document's commentary be its own developer. Bookclub files contain source code, issue tracking, research, feature requests, and reflections on the development process all seamlessly integrated into a single file. Developers no longer have to worry about keeping track of what they want to be doing, why they want to do something, or even the full picture of how to go about doing something, because the Bookclub file acts in cooperative conversation with the developer as a living record of their hopes, intentions, and efforts.

Tapas is the idea that instead of writing stand-alone programs, we write library ecosystems. Instead of getting ahead of ourselves by trying immediately to write large programs to solve large problems, we instead focus on writing abstractions that reduce the scale of our problem. Our goal is to identify what sort of tool would make the problem at hand trivial to solve, implement said tool, and even work recursively to implement tools to implement our tools. Our goal is that each next level of abstraction is roughly a three-line trivial case of the level of abstraction below, and eventually the solution to our initial problem is itself trivial.

Over the course of the talk, I intend to dive into what is Bookclub, what is Tapas, what do they look like when used together, and why they provide a meaningful set of methodologies both for getting real work done and also elevating the programming process' beauty. I will use a live demo centered around light development on a real-life yet-to-be-released Emacs Lisp package. I intend to showcase how Org Babel enables Bookclub by allowing for incredibly malleable documents that seamlessly integrate source code, documentation, issue tracking, research, and even the build process. I also intend to showcase how the Emacs Lisp macro system enables Tapas by allowing us to recontextualize and reinvent syntax in order to build powerful, composable abstractions that do exactly what the context calls for while using phrasing that is both natural and intuitive.

About the speaker:

Hi! I'm Maddie Sullivan, my pronouns are she/her, my handle is ElephantErgonomics (ElephantErgo on IRC), and my email is hello@ElephantErgonomics.com. My talk is on a programming methodology I've stumbled into that I've come to call "Bookclub Tapas". It's inspired by literate, agile, and last year's Emacsconf! I've had great success with it for my personal development process, and I'm hoping you can get something out of it as well. I'll be laying out what it is, how I found it, why Emacs makes an awesome environment for it, and how you can get started with it too!

Transcript

[00:00:00.620] Introduction

Alright! Hi everyone! Happy EmacsConf! I´m so excited to be here. It's surreal to be part of the conference itself, in addition to being a viewer. EmacsConf is like Christmas to me, and I'm so excited when it comes around every year. Today, my talk is on a programming methodology that I've created, discovered, stumbled upon. I call it "Bookclub Tapas." Before we get into that, let me introduce myself.

[00:00:29.680] Hi, I'm Maddie!

My name is Maddie Sullivan, and my pronouns are she/her. I go by the handle ElephantErgonomics, which is shortened down to ElephantErgo in the IRC. You can reach out to me after the talk for questions, comments, or just to say hello by reaching out to hello@ElephantErgonomics.com. So this software development strategy I found, it's inspired by literate programming and Agile.

[00:01:03.840] Bookclub Tapas

So what exactly is Bookclub Tapas? Bookclub Tapas is a conversation that you have with yourself. It's a log and a ledger, of your intentions, hopes, dreams, and what you've learned over the course of development. Bookclub Tapas is an oracle you can consult about the state of, and the strategies behind, your development process. Bookclub Tapas is also a peer programming partner that helps you decide how to best put forward your efforts and how to best pull together what you're working on. Bookclub Tapas will also help you to understand how to tailor scope to your needs, and how to have the best parts of your program shine through clearly. Bookclub Tapas consists of two parts: Bookclub and Tapas, but what does that mean exactly, though?

[00:02:00.520] Bookclub

Bookclub is a reverse literate development strategy. Bookclub is a time for you to write, and then read and reflect. It's like a Bookclub, but it's for your program. Instead of inserting narration into your code to narrativize what you are accomplishing, you are instead inserting snippets of code into your narrative to make it come alive. So, what are we narrativizing, exactly? What sort of story are we telling? Bookclub is the story of you, your program, and how your efforts are allowing your program to come into the world.

[00:02:40.300] Too many hats, too many roles

Software developers naturally have to wear a lot of different hats, and take on a lot of different roles. We apply ourselves into a lot of different contexts. We do research, interface architecture design, mathematics, philosophy. We take in the world around us and then build abstractions to model it. We translate the abstract into the concrete, and then when we're trying to teach software how to be "smart," we translate the concrete back into the abstract. I can't help but feel like so much of what makes software development difficult is just trying to remember and keep track of everything. We have to try and remember so many different implementation details. We have to remember how our own code works, how the API of our dependencies work, how relevant real-world constraints behave, what the standards lay out, and how our data structures are laid out. When we're debugging, we simultaneously have to remember how our program is currently behaving, as well as how the program ought to behave in order to get a chance to reconcile that gap. It's honestly all way too much. We need a ledger of what we're actually doing in order to stay sane.

[00:03:55.800] Narrativiation

I think a really effective way to make sense of things that are complex and important is to narrativize them, to turn them into stories. This is a strategy that humans have been using for a long time. Mnemonic devices, metaphors, and drawing parallels are all different ways of doing just this. Telling stories helps us to understand things that are big and complex by grounding them in our own experience and making it fit into our scale. So because the way that everyone naturally tells stories is going to be a little different, because the details that strike us as important and worth focusing on are going to be different for different people, I'm not going to say that there are hard and fast rules about how Bookclub "should work," because how it "should work" is however it best fits your needs. Different people and different projects have different backgrounds and mindsets. And I don't think it's my place to say what strategy is correct as a universal law. You know, because Bookclub Tapas is, after all, just something I've sort of stumbled into. Bookclub is intrinsically ad-hoc. My providing a prescription of strategy is basically going to begin and end with the idea that you write a reverse-literate document that illustrates how you've gone about writing your program. All of that being said, I'm going to talk about how I've laid out my book club files and why I think this is a solid place from which to get started.

[00:05:24.780] My starter kit - My stock, off the shelf suggestions

So my stock off-the-shelf suggestions for just getting started is to have sections for: our overarching goal, our development goals, a place for scratch work, a test suite, research, and then finally sections for variables, functions, and macros.

[00:05:47.660] Now what?

So we have our starter kit sections. How do we go about using them? How do we get started? Well, we write them, you know, out in our org document, but then what do we do?

[00:05:58.980] Our overarching goal

We start by writing what we know. We have a spark, a vision. We had the beginning of an idea of what we wanted our program to do. Alternatively, maybe we had a client lay our goals out. Either way, we have some idea of how we want our program to be shaped. Let's start by writing that down. What are we trying to do? What is our goal?

[00:06:23.460] Our development focuses

After that, we're probably wondering to ourselves, "Okay, we have our goal, but how do we get there?" That's when we start writing our development focuses. If we have bursts of intuition about what functions to write, questions that we want to answer through research, we start enumerating those every time they hit us. Our goal is to write them all down in a checklist in order to turn them from daydreams into courses of action. If we aren't having development focuses hit us right away, that's okay. If we just stare at the goal for long enough, I think it's inevitable that the muse will speak, and we'll get a clear lead on a path forward.

[00:07:05.120] The rest of the headings

So now what? Now that we have our development focuses, we want to go ahead and create the rest of the headings for ourselves so we can act upon them. We go ahead and write the rest of the file's structure ad-hoc in a way that will serve our needs for now. If it's not fitting us well later on, we can just go ahead and change it. There's no pressure. That's the beauty of having this all be in a plain Org document. If we're doing something consistently, we probably want to have a heading for it. We'll go ahead and create homes for our variables, our functions, our macros. We'll want to create a spot for scratch work to sort of like stretch our legs and lament in a stream-of-consciousness sort of format about how a particular piece of design ought to work. Basically, any time we wear a different "hat" or we take on a different "role" as a developer, it's worth considering creating a category for it. The best way for us to figure out what headings to fill in, and how to fill them in, is to just go ahead and act upon our development goals. If we have a question we want to answer, we'll want to create a Research heading so we can go ahead and have a spot for scratch-work for reasoning things out. If we want to write the first draft of a function we want, We'll want to create a heading for functions and then a sub-heading for that function in particular.

[00:08:37.980] Conversationality

So now that we've filled in our sections, what do we do now? Our idea for a program has been turned into a story, but what does that actually get us? To me, a lot of what's exciting about Bookclub is that novelization goes in and a peer programming partner comes out. As we loop through reviewing our document, as we scan it up and down, we're able to engage in conversationality with our past self because of how verbose we've been in our notes. We can ask our past self questions, and get back answers. We've turned our past self into a peer programming partner. If we're wondering what to do next, we can check our Development Focuses. If we're wondering how something works, we can read documentation embedded in our function drafts, or we can read the outcomes of tests that we've performed in our research. We can ask ourselves questions and get answers. Some of what's most exciting about peer programming to me is having fresh perspective and alternate context. We have a fresh set of eyes on the program that aren't our own, and with that set of eyes comes someone else to share the burden of trying to remember everything. With Bookclub, instead of having a peer programmer that exists in physical space, we have one that's, to get all sci-fi for a moment, reaching forward towards us from backward in time. We're asynchronously working with our past selves as an equal-role collaborative partner in development. We have their perspective, their fresh memories of the code as it was written, and their focus on what was worth worrying about at a different point in time. We can ask them questions and get answers. We can ask them questions like, well, "What do I do now?" "How does this data structure work?" "What types does this third-party library take?" By asking these questions, I can even stay fresh on development progress that I last touched months ago. It's really easy to duplicate work, forget how things work, lose track of priorities. Bookclub helps keep us focused, it keeps us accountable, it even keeps us company.

[00:10:55.480] Ad-hoc means lesricsf tion

One of the most immediately useful things about Bookclub, in my opinion, is that we immediately have a list of actionable items. Every time I have a little pain point, I go ahead and write it down, and I write down all of the things that would be nice to have done someday. So you might be wondering, and it's fair to wonder this, isn't this effectively just the GitHub issue model? We're listing out bug requests, issue requests, feature requests. It's not exactly a new idea, and it's pretty intuitive. I think the important consideration here is that having really formalized apparatus for entering in our thoughts can be an unnecessary source of friction. Bug listings don't tend to be a great fit for daydreaming or verbose considerations of philosophy. Bug listings tend to be reserved for catastrophes. I feel like a lot of the tooling that we currently use really struggles with creating ergonomics that make taking frictionless notes difficult. We have systems where all the disparate parts of what we're working on feel really far away from each other. We're pushed away from engaging in conversations with ourselves as a result of how disparate all of our tooling feels, how the process of working with it is incongruent. My hope is that we can instead engage with a process that makes it really trivial to write impulsive journaling about what we're doing. So much of design is ultimately just daydreaming. Good ideas tend to strike us hard, in a momentary flash of inspiration, and then they fade just as quickly. Anyone who's had an idea all at once in the middle of the night knows that they're going to have to choose between either committing to writing it down or accept that by morning they'll have lost it. If we're not writing what strikes us as important at the same moment that it's happening, we're going to lose it. It's not realistic to expect ourselves to hold onto our ideas forever with the same precision as when we were first inspired.

[00:13:01.920] Gratis documentation

Okay. I'm gonna call you out real quick. If I ask all of you "Who wants to read really excellent documentation?" I imagine that everyone here is raising their hand. We want code to make sense and we want to know what the original developer had in mind. Even the original developer themselves would want this just for their own sake. I know that for me, I can even feel things becoming less fresh just after a couple months away from my codebase. And that was me from a couple months ago. They're not around anymore. Now, here's the rough part. Here's what I'm really gonna call you all out. "Who wants to write really excellent documentation?" Now, I don't know what's happening on your end, but I'm imagining crickets, silence, tumbleweeds blowing through to the horizon. It's a tough ask. It's not generally all that rewarding. If you're writing docs from scratch, a lot of it involves relearning the intentions behind crusty old code. For me, it hurts to not spend that same time implementing bug fixes and new features. It just doesn't feel like a great use of my time. Even if it's strictly for my own codebase for my own use, it's hard to sit down and do it even when I know how much I would benefit from it. My thinking is that when you write rough, piecewise daydreaming as you go, it's so much easier to not only begin writing documentation early in your process, but also to stay consistent about not slouching into an accumulation of a backlog.

[00:14:48.440] Keeping the thread of your intention

So not only does writing documentation early make us more likely to keep that habit going, but it also makes the documentation we do write way more robust. When fiction meets reality and we start writing out code that is constrained by the real world and not just our imagination, we learn that things we assumed about our design aren't going to work out in practice. Because of this, we can enter into a sort of situation akin to boiling a frog in a pot of water. Frogs don't notice that they're being boiled if the water is only heated gradually enough. We decide to adjust our design only a little bit without changing the documentation right away. Doing that once is fine, but I don't believe for a second that we're only going to do it once. We can find ourselves surprised that as time goes on, our code looks nothing like our spec, and we lose the thread of what our code was supposed to do in the first place. When we stake our intentions clearly and early, you ground yourself in them. You reduce the risk of straying from them. You have clear reference for what you want your code to do, and you reduce the risk of having its purpose shift over time. When we take turns alternating between writing code and documentation rather than acting, you know, as having it all as one step, we risk taking turns just moving our goalpost back and forth.

[00:16:21.500] Bookclub is becoming too much

So we've seen how our Bookclub files get us all sorts of amazing features and practical benefits. But we might be starting to notice a pattern as we continue to engage in conversation and work with our document and watch it grow in size. We originally created our Bookclub file with the hope to reduce what we would need to keep track of and to reduce our level of overwhelm. We might find that as our Bookclub file grows, we're encountering more detail than we can practically parse, manage, and decipher intention from. It can be easy to enter into a situation where we're drowning in the breadth of our notes, and in doing so we've recreated the same problem we originally set out to solve. Writing out every single detail helps us a lot to make sense of things at first, but then after a while, we can encounter a signal-to-noise problem when we try to make meaning from too many details. This is where tapas come in.

[00:17:25.240] Introducing Tapas

So tapas in Spanish cuisine are appetizers. What's notable about tapas is that you can bring a bunch of them together to make a full meal. In the context of Bookclub Tapas, they serve a similar role. The idea is that we write flavorful libraries that together form a full program. We have a full program, but it's made from discrete modules. The idea behind tapas is that instead of creating one perfect, "solves everything" codebase, we want to create a whole bunch of separate libraries that themselves nail a specific subdomain. And once these libraries are all brought together, they form the whole that we're seeking. Once our Bookclub file becomes big enough such that we feel like our scope can be split into multiple libraries, that's when we want to take the opportunity to split our program up into parts, into Tapas.

[00:18:22.840] What are Tapas, what are Tapas not?

So, maybe one of the best ways to understand what makes a good Tapa is to first examine what does not make a good Tapa. The single most important thing to understand about Tapas is that they themselves are substantial. There's a lot of back and forth on the idea of micro-libraries, their merits, their dangers, and when and where they kind of work best. I think the distinction that I would like to draw is that I think that tapas belong in the larger end of scale and complexity for microlibraries rather than the smaller end. I think particularly small helpers like NPM's is-odd are a good example of something I think does not constitute a good Tapa. Meanwhile, I think Python's Requests library is a really good example of a Tapa. I believe Requests only does HTTP connections, but I feel like that's not so simple and straightforward that you can just go ahead and implement it on your own real quick. A real danger of creating helper libraries that are too small is that we don't remove abstraction nearly as much as we postpone it. If our libraries are small, but the glue code that binds them is large, we haven't done anything to reduce complexity or employ abstraction in a meaningful way. If all of the complexity exists in our glue code, we've simply replaced our functions with libraries of the same size and purpose. Our codebase is still monolithic instead of having meaningfully divided scope. I think that a good Tapa ought to feel like augmentations or extensions to the standard library. You know, maybe something kind of akin to Scheme's SRFI system. I think that the goal of good Tapas is not to solve a particular problem, but instead to solve a particular class of problem. The goal of a well-written Tapa is to solve needing to do hard work in general rather than solving what can only really be an individual need of an individual program. I feel like Tapas are most helpful when we instead seek to solve a larger overarching problem that intersects with the problem space of our code base. When we have a handful of Tapas that are roughly the same size and scale, the glue code that marries them is also roughly the same size and scale. As a heuristic, I try to aim for any function being approximately 3 calls in length, and then any Tapa being between 6 and 12 functions in length. The number of Tapas themselves can be as many or as few as you need, but then your Tapas can split into their own separate Tapas as needed. My hope is that the collection of our Tapas, especially as we create dependency chains among them, is that each next Tapa is a trivial case of the one prerequisite to it. Every Tapa is a meaningful, human-readable abstraction that enables us to feel confident about our tooling without drowning in detail. The whole stack can be understood by humans, but we only have to focus on any one piece of it at a time, rather than focusing on the entire stack all at once. We can practically achieve a huge final product, but each individual step in working towards that goal is still at a human scale. One thing I want to make sure to point out, one thing I want to make sure to point out explicitly, real quick, is that having access to a hygienic macro system, like the ones that we have in Lisps, makes for an amazing experience for creating Tapas. The types of abstractions that we can do by modifying syntax at compile time makes for incredibly intuitive and ergonomic tooling.

[00:22:25.180] Tapas are maybe best illustrated by example

So we've talked quite a bit about what I think makes a Tapa good, but I think maybe the best way to understand the concept is to have a look at the whole workflow in practice. I've been working on this, currently unnamed, Elisp program recently. It's a validator for the filetags lines of my Org Mode files. So I have Org Mode files under my Documents directory, organized in this hierarchical way, and the nested directories have meaningful names. I want the headers of my Org files to be tagged in accordance with the sequence of the names of the directories. I do this by having the file-tags line at the top of the file just list the path segments in order. If I have an Org file in the directory "~/Documents/foo/bar", the file-tags line has the tags "foo" and "bar". This is totally fine to do by hand, but I want a program that recursively searches through my directories to validate that the tags are correct because it's easy to drop something. This scale of problem is actually kind of perfect for demonstrating how Bookclub Tapas work in action. We have a problem that's mostly rather simple, but it has a lot of moving pieces. We want to iterate over directories recursively, we want to do string manipulation, we want to parse buffers, and we want to edit buffers. All of these tasks are simple enough on their own, but it's deceptively easy to start tripping over ourselves when we feel like it's necessary to do all of these different things in one step. So there are a ton of great string manipulation tools for Emacs, so that's checked off, that's done, taken care of. I'm still kind of daydreaming about writing a wrapper around some of the Emacs standard libraries for directory traversal, just to make it a little bit nicer to work with. But the big thing that really struck me as odd is that there doesn't seem to be a great tooling for destructuring Emacs buffers beyond just chaining together a bunch of editor commands. Emacs is so buffer-oriented, I feel like it really deserves a good library for programmatic buffer destructuring. I looked around for a bit, but I couldn't really find anything. So at the end of the day, I could definitely just grit my teeth and put my head down and just use tools that feel cumbersome to work with if I wanted to. I could write something that's "good enough" just for the purpose of my package and then hide it deep inside the code base. I could absolutely do that. But I can't help but think about how after I properly write the tooling I'm missing, I'm really going to be thanking myself in terms of reduced implementational complexity, reduced bug hunting, real reusability, and ultimately really just a deep sense of pride in knowing that I took the time to do something in a way that feels "right." This right here is the perfect time to split off Tapas. Any time that we find ourselves reaching for a fictional dependency, wishing that someone had written a library like this... We can take that opportunity to remember that we are "someone." We can write that library ourselves, and we deserve to write that library because we deserve to get to use it.

[00:25:52.340] Introducing Squint

So I'm going to briefly show a Bookclub buffer for a program called Squint. It's the buffer destructure that I've been talking about, and it's real. It's a wrapper around Emacs's narrowing functionality and regular expression search. It's not totally done, and will likely see some breaking changes, but I really like where it is. I'll be posting it in its current state on some of the big source repository sites relatively soon. I think it has a good feature, which is really quite exciting. And it'll likely probably get split off into its own Tapas. We'll see. No matter what, I do recommend being on the lookout for it, because I think it'll be a really excellent demonstration of some of the solid ideas behind how to get rolling with Bookclub Tapas. So I have my background section where I'm basically just sort of laying out, you know, what the objective is for the program. I have my vision where I'm doing some daydreaming about, you know, how this all ought to work. I date stamped this. As you can see, it's from a while ago, but I still have the full context of, you know, all the things that I've done working on this. I listed out a bunch of ideas for different forms for functions macros. I did different pieces of research. Yeah, I was trying to figure out for the width restriction macro, what types does it take? And I did a whole bunch of tests to try and ultimately figure it out. Because it claims in the documentation, I believe, that it will just take any type for labels. But in my testing, that's not ultimately what I found. The results of my tests is that symbols, numbers, they work. Strings do not. I'm not sure why that is. But for my purposes, this is what I need to know. I have my development focuses here. So I have my assorted goals for different directions I want to take the program. And then lastly, I have my functions, my macros. And this right here is the titular macro. This is ultimately the big meat of the program. And it's all contained happily organized inside my Bookclub file. I'm quite happy with it. I think it looks really nice.

[00:28:36.100] What else does Bookclub Tapas do?

So what else does Bookclub tapas do? I don't know. It probably does a lot of stuff. It does all sorts of stuff that I don't know about yet, but this is where you come in. I'm really excited to see what people do when they take these ideas and run with them. And if you have something really cool you're doing with it, please email me and come talk to me about it. I'd love to hear about it. Again, my email is hello@ElephantErgonomics.com.

[00:29:08.160] Let's work together

So last, before we wrap up, I want to go ahead and give a quick plug for my services. I am an independent software engineer that has an emphasis in backend design and general automation. In particular, I have an emphasis in that really cool new generative AI thing that everyone's been talking about recently. If you have a headache, you have some sort of pain point for your small or large business, you wish you could just wiggle your nose and have disappear, come talk to me. I'll make it disappear. I love doing that. Reach out to me at hello@ElephantErgonomics.com. If you think that Bookclub Tapas would be a great fit for your team and your project, I'd love to hop on and help you get the ball rolling quickly. Go ahead and email me at hello@ElephantErgonomics.com. Lastly, if you're a member of the larger Lisp community and you want to fund independent software development for things that really excite you, for passion projects that make our ecosystem richer, I'd love to look into accepting independent funding so I can commit more hours toward making that happen. Some of the projects that I want to work on are a Python Foreign Function Interface for Guile Scheme, a framework for rapidly creating simulation games that feels just as simple as writing Emacs configurations, I want to work on getting a full graphical web browser inside of Emacs, and I want to finish programs like Squint. These are just some of the projects I want to work on, but I need funding to do so. If you want to see these things happen, send me an email at hello@ElephantErgonomics.com with both your intention to pledge a monthly contribution as well as clarification, a sort of vote on which project you would like to see me prioritize. I would love to have folks reach out for any of these reasons. I would just love to talk to you. Thank you so much for watching! I really hope that the talk was interesting, and I'm really excited to see your thoughts and questions right now in the Q&A! Thank you so much for watching. Bye!

Captioner: sachac

Q&A transcript (unedited)

All right, take it away. Okay, am I, are we live? Yes, we're live. Oh man, holy moly. Oh, that's surreal. Hi everyone. Oh man. Ah, so excited to be here. So good to see all of you. Okay. So, should we just go ahead and get right into it? Yeah, let me, let me see here. So I have. Yeah, I see, I see some, I see some questions coming in. Perfect. I am going to show my share my screen real quick. We have currently currently we have a sort of a dross thing going. And so I just wanted to, while we're waiting for some more stuff to come in, I just wanted to sort of idle on this buffer here. If you increase your font size slightly, that might be even nicer. Yes, absolutely, gladly. Whoa, okay. There we go. All right, the first question was looking for examples of files in book club style. The person says, that seems to be related to what I've been doing, but coming from different influences. Yes, yes. So I included a, included a, Let me see, I'm just looking at the IRC here and smiling at all the people. So, yes, I provided a link. So I think that an excellent. So I have gone ahead and provided the get the link to the repo and I'm going to go ahead and post that again. So this should serve as a full example of what a just sort of standard book club file looks like. And if anyone has like specific questions about anything in particular, they would love to see my sort of like walkthrough and narrate like specifically, you know, any place in this file that they would like to see me sort of like go over live, I would be super happy to do that. So I have the whole, you know, more or less complete book club file for Squint pulled up here. Yeah, I have my vision laid out, which has my initial sort of goal. you know, the background and the vision sort of combined to lay out what my general sort of goal is. I just realized, let me kill my stream there. There we go. All right. There's another question. The product of a tapa like squint.org would be pure gold for an agent like Cloud Code. Have you experimented with providing an agent with a final output and letting it chew through to-dos? That would be a really excellent question. I actually just kind of recently got into Clawed in particular. I played quite a bit with GPT and and a lot of 8 billion parameter local models. And I was never super impressed. It always felt like I was just sort of wrangling to get it on the same page, whether as a result of sycophantism or really just not having enough parameters in order to understand the context of what's going on. Cloud has completely changed my perception of what an LLM can do or not. It makes autonomy not seem like a total fever train. I have definitely been curious about how an LLM would react to book club files. I think that, yeah, especially like, I've been daydreaming a little bit about, you know, having it generate scratch artifacts or suggesting, you know, changes to the format. It's like, yeah, the fact that this is all like, you know, like super, The goal and the hope for all of this is that we're being verbose about our thinking anyway. This is sort of how, by default, deep reasoning kind of works. I actually think that I totally agree. It would be a great fit. I have yet to personally do it, because I've always been just a little bit wary about, like, you know... Well, if I'm writing a program, I want to write it, you know? People often talk about, like, you know, oh, I just want to hand off the boring parts to Claude. But the thing is, if I'm writing an e-list, I find the whole thing to be kind of fun. be super, um, it would be super interested in, you know, just sort of as a point of exercise, like seeing what it's capable of. Because I think, I really do think that this would be kind of an ideal environment. It is kind of close to, you know, native-ish, how LLMs think. There's also, like, you know, of course, the, um, the privacy angle. I don't necessarily want to provide a whole bunch of code verbatim that I intend to GPL3. But I believe that Claude kind of has a better policy in terms of what does and does not become training data. I'll have to look into Claude in particular because I feel like that would be my target for it. But yeah, I think that's definitely onto something. I've definitely thought about this. I've definitely been really curious about this. Next question, do you think every Tapa should have its own book club file as well? Or would you rather keep just one book club file in the top of the project? So I think that I definitely would advise that each Tapa have its own book club file. The reason being is because I find that for me personally, the way that my brain kind of works is that out of sight, out of mind is very literal for me. I find that I find that. What am I thinking of? Sorry, I just saw that I got an email and I'm like, yeah, okay, cool. Case in point, right? We are at case in point, you know, out of sight, out of mind. Yes, no, absolutely. Yeah, no, exactly. I, um, I'm definitely quite ADHD and it works for my advantage because it provides all sorts of versatility. This is another great advantage of book club. If you have an ADHD mind like I do where, you know, You love jumping around and working on all sorts of different pieces simultaneously. You don't like sitting down and doing the same thing all day unless it really latches onto you. You know, you can pivot and you don't do anything. It really rewards the fact that you can pivot. So I find that to be really excellent. But to go back to the original a question, I would definitely recommend, at least in my circumstance, I find it to be incredibly useful to have each tapa be its own book club file rather than to have a unified file that holds all of your tapas. You can definitely do this, especially if you're using org to organize it hierarchically. It's just sort of a matter of preference and style at that point. So long as you're making a clear distinction between your tapas, that's the main thing that I would recommend no matter what, because the whole hope that I have is that you have a sort of separation of focus between the different you know, the different focuses of your different tapas, they really should ideally feel like different programs so that you're not, you know, getting over yourself, getting ahead of yourself. I think that, you know, on that basis, I would probably default to recommending that tapas have their own separate book club files, because ideally they should kind of be different sort of independent but related thoughts. But at the same time, I mean, like, you know, this is coming from someone who like has a billion small, like, you know, I had one giant org file for a long time and then realized that really didn't work for me. So now I have a billion tiny ones. So depending upon how you feel about, you know, should I have one really big org file or a bunch of really little org files? I feel like that more or less gives your answer. I think it's whatever works best for you. I know that far and away what works best for me is having separate files. No matter what, you should have separation of concept though. But however you do that is, you know, is best your judgment call. Next question, how do you build habits when it comes to documentation? I tend to produce lots of documentation in one go, then effectively forget to do it for long periods of time and end up playing catch up, which results in a loss of precision, as you alluded to in your talk. In a work setting, when something goes on fire or priorities change, it can be hard to keep discipline. Would love your thoughts. Thanks. Yes, absolutely. So what I tend to do is I don't So really, so far, what I've been doing is that I haven't been making a conscious priority of writing documentation at all. And if that sounds contradictory to the talk, that is correct. What I mean by this is that I go about is that when I'm writing code, when I'm writing, you know, drafts of my functions, the way that I tend to approach this, the way that I really emphasize the approach for it, is that I want to focus first and foremost on sort of like just writing down what my internal monologue is for what I'm doing for that pass working on the file. So my document takes ultimate Distance of dark is ultimately a property from the fact that I am writing what I'm doing as I'm doing it. And it's more or less just I'm just mashing out the stream of consciousness of what's going on inside my head as it's happening. So if we go down and we take a look at, yeah, so let's go ahead and take a look back at the macro. Yeah, really, this is kind of cheating, because mostly I would consider this to be self-documenting, but we all kind of know that that in and of itself is a slippery slope. That's not great. Because it's like, I could believe that this would be self-documenting if this was a three-liner. It is not. which, you know, also goes to show me that this needs to be splitting into its own topos. I intend to, you know, write a Tapa that's a sort of, that's a sort of like macro builder that automatically, you know, does the gensims for you. Something along the lines of what's the common Lisp macro for that called? It's like, There's some common list faculty that does automatic Jensen binding. I can't quite remember what it's called. A prior version of this talk had my live coding that, but that ended up sort of distracting from what I kind of wanted to nail out and focus on. But really kind of what I do is that, let me see here if I can find some sort of, Yeah, so I have in my research section sort of layout like what the quirks of all this sort of are. I think my development focuses contain a little bit of what could be ultimately considered to be documentation. Yeah, as I'm looking through all of this, I'm kind of realizing that like, you know, yeah, there's stuff that I'm into documentation here, but it's all a little ad hoc. You know, I would, in part, the design of this particular tapa is arguably not currently, but is going to be simple enough such that a doc string is sufficient for documentation. That is not the case currently. All right, next question is, how do you write examples and tests? I think that you mentioned that during the talk, but I couldn't find them on a very quick look at your org file in the Squint repo. My use of the word test was a little bit creative. It's my validation of the code that I've written. I more or less tend to do a, I tend to try and write really small functions and have really aggressive validation by just making sure that, like, you know, when I chain functions in the REPL, each step of them produces results that are really quite immediately and self-verifiably seen. Now, this isn't a great excuse to not use a test suite, but it's gotten me pretty far. What I mean by tests is that in the research sections, what I've done is, so I've created a sort of tested in the sense that I have created a really highly representative case of the way that the program ultimately ought to behave. In doing so, I created a sort of embedded domain language that I have termed animal houses. And Animal Houses is a sort of markup language that has rather simple rules. This here is the entirety of the spec for Animal Houses. Grammar or anything, but like, it is more or less. Breadth of everything that needs to be known about how animal houses works. And I've created animal houses because it is an ideal and incredibly simple circumstance. For how to go about as needed tests. For how squint ultimately ought to work in practice. So when I'm doing research, what I do is I take the text of animal houses, and I will go ahead and insert it into a buffer. And I'll just create an analog buffer. I just called it a woo. And then what I'll do is in my research sections, I will write Like I'll write like step-by-step like instructions on how to go about with a REPL-driven detection using animal houses. So it does squint pass label to width restriction correctly. The tests conducted here indicate that it does not. And then I link to a development focus. that um effectively acts as my bug report or sorry my uh you know my bug for um my bug listing for this particular problem that I've identified I lay out some criteria of how to go about using the REPL to um you know I identify what I believe is sort of like the quarantined area that I found for the bug and then test is that I will go about engaging with narration the step-by-step of how I produce the circumstances around the bug until I ultimately narrow all the way in and arrive at a conclusion. Something's going on with the screen share. I can see your screen but the server cannot see your screen updating. Sorry. Oh, no. Maybe you stop switching. Yeah, and then we just redo it again. Thank you. Yes, absolutely. Thanks to someone who noticed the buffer time, the time in the load line was not updating. Okay, let's try that again. Now it's updating. Gotcha. I hope that wasn't going on for too, too long. Hopefully what I was saying wasn't completely indecipherable. Let me see here. Yeah, this is the sample text for animal houses. This is the spec, not a formal grammar, but it is more or less the whole of the spec that you need to write a parser for animal houses. Most of the tests around Squint involve writing sort of ad hoc parsers for animal houses. Just when I have it in its own buffer, you know, I find more or less it's an excellent way of going about testing in an ad hoc sort of REPL driven manner. that I just sort of write regular that pull out the pieces of the sections of buffer that represent the different fields and data types in association with the animals and the houses to which they belong. And then when I am engaging in research, Um, you know, what, what my research section is, is I'm ultimately just sort of like laying out, like, you know, I'm sort of thinking to myself, is this working right? I feel like, like, I feel like there's something here, something in this area. And I'll, you know, ask myself, well, kind of like, what is it, you know, what am I looking for? And then nail down, how am I going to go about looking for it? The process of working with the REPL to sort of pin down like what exactly is going on and come to a conclusion on completely jumping out of order. Have you experimented in like whisper.el for doing speech to text as you think out loud into your book club? Now I am. I love that idea. That is awesome. Yeah, no, I love that. Even with, I only have a CPU, no GPU on mine, it does capture things a lot faster. And because it actually saves the recording to a WAV, or I guess you can configure it, in case it doesn't recognize something well, you can go back and check it. That's nice. I like that more than a straight speech-text thing. I've been mulling over the idea of having a keystroke save into a background buffer so that even when I'm looking at something else, I can dictate into my equivalent of the book club file. Yes, yes, yes, absolutely. So you can be scrolling through documentation on, like, you can be scrolling through documentation on one screen and you can be musing to yourself about, like, you know, is this supposed to work this way? Like, you know, like, what in terms of, like, you know, like, I see this function. It sounds like it's what I'm looking for. I don't know if the types are quite right. I don't understand. It's named what I'm looking for, but I don't know what it's taking in. You can reason through all of this. You're not even writing into the buffer that you're working with. That's actually so cool. Or you can type into the org capture process so that it can pick up an annotation automatically. Sorry, annotation is the link to the thing, whatever you're looking at. Oh, that's super cool. Yes. No, I actually really love it. I haven't, you know, hooking this all up to Org Capture at all. I actually really love that idea in of itself. Yeah. Or a capture will give you a lot of capture options. Like you can capture to your currently clocked in, uh, heading. So then it just files your note in the right place automatically. Absolutely. I love that. Let me see. I'm actually like writing a note to try that out. I'm definitely going to have to do that. Like the flexibility of that in particular sounds just perfect. I'd like to finish typing noises and then we can ask the next question for which there is one. The question is, what is the largest project in terms of team size you had the chance to consult and introduce the book club tapas concept? And what has been your experiences with these setups, implying larger applications or solutions that company is working on? So yeah, probably the largest application. So I have, It's been interesting. So in regards to this, the largest, I would say two people in a couple of different circumstance. So it's the pair of us working in a startup context. And then, you know, we both have like rather technical backgrounds. We can both more or less, you know, You know, sort of reason about particularly excite, especially as we've been building up top us is that, you know, well, we're both rather technical. You know, I'm definitely software engineering sort of end. And, you know, this partner is more. I mean, he's done all sorts of different engineering, but none of it in a, like, especially software context. So like, you know, but what's been really cool about that is that especially as we've built up top us and made clear distinctions about what they ought to do, you know, he doesn't have a ton of like really, he doesn't like experience like specifically in software engineering, but because we have it all laid out in this really flexible way, he's able to pick up the ball and like, you know, like he's able to take the ball and run with it. because it's all laid out in a way that's so intuitive. Like, you know, he's able to like collaborate with me and like, you know, like, you know, run off these ideas and like really go for it. Like, you know, almost as quickly as I can, just because we've set up a structure where like all of the different pieces have these really intuitive and intrinsic and straightforward roles. And that's, that's something that's really exciting in of itself that I didn't really go over in the talk. Like a managerial perspective, this is actually a really excellent way of understanding the whole context of like what the software stack looks like. Because it's like, you know, it makes it more intuitive for developers for sure, but it makes it more intuitive for everyone. You know, it's on that basis that I can't imagine clients like just a better way at this point. Um, that was that was the other circumstance where I have been working with a partner. This has been with, um, you know, I would be, uh. You know, sort of going back and forth with someone who had hired me. Um, to, uh, like, you know, to work on contract. And I would use this to sort of go over with them about, um. Sort of get a solid idea of scope and function, do pre-planning as we're going into more specifics on what the overall look for the project and how it ought to look and how it all ought to be laid out. So there's a lot of really exciting flexibility there that I think is really cool. People will, of course, be curious about the mechanics of that collaboration. Did you get other people using Emacs in org? Were you using version control? Did you try out CRDT? How did it work? So all of this so far has been over screen share, where I would be stepping through the buffer by hand. I would love to set up some sort of an environment where I could get you know, clients and partners, like, you know, really excited about using Emacs on org. But, you know, it's, it can be a little bit to ask, I would love to see if I can, like, put together some sort of a config that, like, sands off all of this and, you know, makes this this really, you know, you know, like safety-proof sort of intuitive environment just for CRDT in particular. I love the idea of like, you know, sort of like spawning CRDT so that like, you know, the two of us can, you know, type SPAC and ideas and sort of like draft together on, you know, especially like the glue code tapa for a larger software stack. like collaborating on that over CRDT or having folks step through Tapas and, you know, unfold them and like, you know, point to a particular thing. And it's like, you know, like, what's, what's this? What's the clock here? It looks like we're spending a lot of time and I would like to get a little bit clearer of an idea of like what exactly we're doing here. back up a little bit because the stream just disconnected and reconnected from the audio. So, please repeat just the last sentence. Yeah, yeah, for sure. Yeah, so I would like, you know, I love the idea of, yeah, like, you know, collaborating on, especially like on the glue code. tapa for a particular software stack, you know, having the both of us use CRDT to type into it simultaneously, I think that would be super cool. I also really love the idea of, you know, having a client or partner, you know, thumb through individual tapas in the stack. And then like, you know, like, look at and be like, well, we seem to have time on this recently, can you give me like, some clarification on like, you know, what, what this part is and how it's, you know, what it means for the whole and sort of like what, you know, what it represents in terms of how all of this is going to come together. I think that would be super cool. I love the idea of that. I would even consider like, you know, if not Emacs proper, I would love like, you know, maybe a, a web-based org parser. for, you know, even on just a read-only version of the document where, you know, clients and partners, yeah, just sort of thumb through with it and then chat with questions. Make the, you know, screen sharing for, you know, peer programming process just a little bit cleaner, you know, more intuitive on their end. I think that'd be super cool. I love these ideas. All right, theoretically, the big blue button is open. I think we've gotten to the end of the questions on the etherpad. If anyone else would like to join or ask, I'm gonna need a couple of minutes and then I can do closing remarks whenever people are ready. So I will meet now when people figure things out. I would also be super down if, you know, anyone was curious about hearing more about some of the projects that I was kind of rambling at the close of the talk, if people wanted to, you know, hear more about, um, some of my ideas in regards to, um, uh, what am I thinking at home with the, uh, What's it called? Yeah, yeah, just sort of the, you know, some of the funding for passion projects, I would be interested in laying out some of the ideas about how that could work mechanically. And I think that that would be, you know, really cool for the whole ecosystem, because I think that there are definitely, you know, things that we could bang out, you know, for getting kind of all sorts of people on that model. I think that it would be really cool to to having a, you know, funding model for things that are really worth using. um and developing um the other thing is like you know just sort of um yeah just rattling off specifics on things that people could potentially vote for uh on that and in terms of specific might want to work on All right, there's a question from IRC. Sorry, I just got that. Did you address that one already? Let's see. Where is it? I will copy it from IRC. Thank you. Gotcha. Into the past. Perfect, perfect, perfect. Let me read the question out loud so it's in the recording. I guess a major pro is it has less friction as people can do a lot, maybe not everything in book lab tapas files versus having to log into gazillions of different systems, each one of them keeping a portion of the information. Did I get that viewing point right from your elaboration of the collaboration between you and your teammates? Yes. No, that's absolutely right. um because yeah like really my hope is that we can you know there's there's a lot of conflict into that we assume that a lot of um pieces of tooling and the separation between them is really sort of a necessary evil i think that you know having a system where really the complexity of engaging in all of the information relevant to the program. If it's in a format where you can just email it back and forth, break off pieces of it, work with those individually, I think that that's something that's incredibly rewarding. Something that just dawned on me that I wanted to mention that I've been daydreaming about is that in a circumstance where you have multiple developers, like, you know, across a larger team, working on a book club tapas driven project, what you can do is have, you know, a clear, you can lay out your goal, and then start splitting it to tapas from that point, and then assign each teammate their own tapa, which becomes their baby. And I really love the idea of people being able to, you know, have an idea of an interface about how all of these are ultimately come back together, but people have their own like agency over their own code base, despite the fact that they're working in collaboration. I think that it can be incredibly motivating for a team to, you know, have each person in charge of their own project, but of course it's all ultimately going to the same code base. So, you know, I think that, that a pursuit of beauty is this really solid motivator in terms of how people perceive the merits of their efforts and how that lights a fire under them to continue and keep going and dig deep when things get frustrating. When you have a personal stake in your project, I think that that's a really excellent time to really push and move forward on it. And people having ownership over this idea of their specific tapa could be a really cool way to do that in a team setting. But I pivoted off a little bit. So yes, but I absolutely did that. You know, that having a simplistic format for your information is a really solid way to have collaboration be frictionless. You have one source of information and you don't have to drown in your tooling. All right, I think you've addressed all the questions on the etherpad. And as you said, people can email you, even though the website looks like it's still not quite there yet, people can email you or ask questions to the etherpad afterwards. Is there anything else that you'd like to share or shall I wrap up, introduce myself doing the closing remarks and then try to do the closing remarks? Yes, so I have two last thoughts. Yes, no, I did just want to confirm that my email is completely working. If you want to keep up to date with the stuff that I'm working on, please shoot and I will, you know, at your request, I will add you to a mailing list. which will have intermittent updates. I'm not going to send you spam, but it will have updates for what I'm working on, what this all looks like, and just context for the different things that I'm working on. My website will be going up soon enough. I just got a little distracted because I'm like, oh, I'm just gonna spin up a Gux server and I'm gonna make it super cool when really I just need just Debian and Apache real quick, just something. So the website will be going up. It's just not up yet. And the very last thing is that I would really like to thank everyone that helped me to get here. I would like to thank you know, all of my, you know, I would like to thank my fiance. I would like to thank all of my friends. I would like to thank my, you know, my mentor and business partner, Sharon. I would like to thank Tracy, my therapist. I would like to thank my parents. I invited people to come watch this thing, and I would like to thank all of them. I would like to thank everyone who was planning on coming to this event anyway. The Emacs community is incredible, incredibly encouraging, incredibly kind, incredibly smart and talented. Y'all make Emacs what it is, and it is so cool. I would like to thank you, Satya. I would like to thank all of the organizers that made this possible. This thing is the coolest and it was, this was so cool.

Questions or comments? Please e-mail hello@ElephantErgonomics.com

Back to the talks Previous by track: Gardening in Emacs: A Windows user's tale of tending, tweaking, and triumph Next by track: One year progress update Schemacs (formerly Gypsum) Track: General