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.