Okay, hi, we seem to be back. Sorry for the little interruption. John, you might not have
realized, but I was supposed to send a broadcast message to the dev track and I submitted it
to the gen track instead, so I spoke over you for 20 seconds. I apologize humbly, deeply,
and sincerely. But John, I have to apologize now. I will say hi to you. How are you doing?
Hello, I'm doing good. I know I'm saying you harmonized with me. You didn't talk over me,
you talked with me.
You know, as much as I would like to say yes, that is possible, the fact that I did not
have the sounds on your talk makes it very difficult for me to harmonize. You know, it's
like try to have a barbershop quartet and they cannot hear one another. Try to tell
them to harmonize. I'm not sure if it's going to work.
I sang, actually sang in a barbershop chorus for a while and I know the pain that you're
talking about. But anyway, it's water under the bridge.
Yes, what a serendipitous discussion. I wasn't expecting this. Okay, you have the pad open
in front of you. Do you want me to read the question or do you want to take them on your
own?
I'd be glad to do it.
Right.
All right, I'm just going to go start from the top here. I have not only one config,
but multiple configs in different locations..emacs.init.el and.emacs.init.el and different
Python installs in different places. This is something I should take care of earlier
rather than later. I need to pay someone to consult on my config. Is this an existing
business? Is there a place to barter a screen share for something else, a value in exchange?
In any case, thank you for giving permission to have fun without the need for too much
structure.
That's, and that's, yeah, I feel humbled being asked this. I don't know how much insightful
answers I can give here other than the fact that I did notice one of the talks that I
really wanted to catch and resonate with was the Emacs buddy initiative. That was actually
one of the points that I wanted to include in my talk, but it turns out that 10 minutes
goes by incredibly fast when you, when the ideas are flowing. And I think that that's,
that's probably one of the best advice that it, to sources is to find some kind of buddy
who probably would be a great, especially someone who is, who is maybe at a similar
or, or even a different experience or comfort level may be able to, you know, be a good
exchange of value there. But yeah, I mean, that's, and again, it's something I'll think
about more. I might not come up with the most interesting answers live.
Oh, it's fine. Don't worry. You know, you don't have to worry about making the most
exhaustive answer. You know, the whole point of, sorry, let me move myself to the left.
Okay. Nevermind. I'm trying my best to composite the shot live. Yeah. You don't have to worry
about making very exhaustive answer right now. Also, we have about 11 minutes. We might
open up the chat. So you have a lot of questions. So I think a lot of people are very interested.
I think, you know, when you have the arguments that you're trying to valorize the box standard
user of Emacs, I think everyone is feeling very invested into the talk and might want
to ask questions. So I'm giving you a heads up people. If you now is the last chance you
have, we are the last talk of the day, barring the closing remarks. If you have questions
to ask, now is the time to join DBB. We'll be opening it in two minutes. And in the meantime,
John, feel free to go back to the question and answer as many as you can.
Thank you. And I would love to talk about this with people in the community forever.
So this is not the last chance to talk about it. All right. How would you suggest Emacs
developers, including package developers, interface with non-developer users and get
their insights to help in shaping future Emacs functionality?
You know, I think I've seen a lot of discussion on the mailing lists where this kind of exchange
is wanted. You know, I think this is one of those things that may, it may always be difficult
because I've, you know, I have some participation on both sides of this, if there are sides
to it. And I think that most people agree that there's maybe could be a more tighter
communication. So I don't think there's anybody out there who thinks that there's work to
be done here. There's definitely effort that should be dedicated here. It seems to me like
it's happening. I mean, this, you know, the Emacs survey was developed pretty closely
from what I could see with the core maintainers. So I think that it's out there. I mean, perhaps
the mailing list is a good place to start, the several ones of them. I think that you'll
certainly get an answer and hopefully it will start a dialogue that can continue.
All right. Next one. My impression that many common Emacs users are migrating to other
editors in past years. The reasons cited are configurations growing out of control, general
rough around the edges feel of Emacs, they've been putting up with for a while and maybe
this isn't new. As a result, Emacs is becoming a smaller set of people. More invested, do
you share this observation? So what do I think of the trend? And I'm sorry that I was talking
over your editing there. I hope I didn't pressure you into stopping. I mean, my, my impression
has been that that that's a thing of the past that was happening. My impression, I've been
using Emacs for something like 25 to 14 to 15 years, depending on exactly when you start
counting the time. It's been a long time for me and I haven't been very aware of things
that whole time and become more and more aware and conscientious of the scene over the years
recently. But those impressions are that it was getting less, less usage in past years,
but it's, it's got, I think it's been increasing pretty quickly in recent years and increasing
at a pretty high rate. So I don't, I don't necessarily disagree that there are different
sets of people within the Emacs community who may, whose usages may be changing and
maybe certain sets of within the community are shrinking and their investment levels
are changing. But my, my, up until now, if you had asked me, it would have, I would have
said that the Emacs user base was growing, changing and the usage of what they were,
what they were counting on was, would, would have becoming, you know, more towards the
popular, maybe away from what the core user base would have, would have focused on previous
to that. But yeah, overall it seems to me like it's growing. And I think that where
we are here and everyone who's gathered here today is, is evidence of that.
And what do I think of that trend? I mean, I, I'm happy about it. I think, I mean, I,
one of the things that I didn't have a chance to focus too much on in the talk was, was
the power of that vanilla out of the box experience. I am a Viper, happy Viper user. I don't think
there really are many others that I, at least ones that I know about and they may, they
just may be the people that I was describing in my talk. They may be out there using Viper
happily and they're, and they're dark matter. They're there and they make up maybe a huge
amount of the universe, but you just maybe can't, it can't feel their effect. But, you
know, I think that the, I'm glad that that usage is growing, if it is. But I also would
hope that people continue to value that out of the box vanilla experience. Because I think
that it gets, it's easy to overlook and I think it probably does get overlooked. And
that may just be a necessary consequence of the fact that when things become popular,
when things grow in popularity, they are, what gets focus and what gets coverage is
those things that are more receptive and lend themselves better to, to popularity. And that's
not necessarily the same as the things that are the most, it's not everything is really
all I can say. There's more, there's always more to it than that. So I hope that as popularity
grows, people won't forget those things and those things will stay, stay useful for everyone.
Should I do the last one or should I stop? Oh, yeah, I might have some comments on this
if no one shows up afterwards, but for now, yes, feel free to answer the last question.
Okay. Do you consider that using one of the starter packages, do me max, space max, etc.
affect that learning process that you mentioned? Or is it a good thing from your perspective?
You know, that was another thing I wanted to mention in a talk that I didn't, that my
10 minutes didn't allow, or maybe just the way that I talk in those 10 minutes didn't
allow. I wanted to just acknowledge the fact that I don't have experience with them. I've
been using GNU Emacs since, since I started using Emacs. I think they solve a problem
for people. I think they have a place. But, you know, I think, I think some of the thoughts
that I had been forming that I wasn't able to put in there about these was that you need
to start wherever gets comfortable for you. And I think that no matter what you use, whatever
you start with, I think you, you always get to the point where you feel like you've entrenched
yourself in mindset or a set of habits that you use and you think it's, you want to change,
you know that you should be able to change and grow, but you've just become accustomed
to what you do. And I think that if, if using a starter package, if using a starter package
gets you over that initial, you know, gets you into the things, if you feel like it's,
it's going to limit your growth later on, I don't think it's necessarily because of
what you chose. It's just, that's, that's just the feeling that everybody's going to
feel eventually. Yeah.
So sorry, John, I was talking with production. Are we, are you finished with the questions?
It seems that you are, yeah.
Yes, I believe I am. And I will, again, I will add better thoughts to these later on
the pad.
Yeah, but that's fine. I think you did a bang up. I'm French. I don't know if a bang up
job is a good job. Can you confirm it for me?
Yes, thank you. I appreciate that.
Cool. Thank you. So it seems like we have Bob on for a question. So Bob was the speaker
for the HyperOrc talk earlier today. So Bob, can you hear us?
Yes, I can hear you great.
And we can hear you as well.
Can you see me? Let's see if...
We cannot see you yet though.
Okay. Yeah. I just started, start sharing. So I wanted to ask you, I mean, one of the
things we really suffer from hyperbole, we have this issue that we try to make things
as easy to use as possible, right? Just point and click, press this button and the magic
happens. But because we are dealing with a domain that has a lot of complexity to it,
we find, like you're saying, people have always done something a certain way. They bring whatever
processes with them that they've used before. So it feels like there's a much heavier barrier
to get regular users on board than there really should be from what we think we're producing
in the software. So I wanted to get your perspective about what you think that might be and, you
know, ways we could pursue tackling that.
And by regular users, you mean ones who have already had a lot of time and...
Emacs users who are not developers, not just not Emacs developers, but maybe they're non-technical
at all. But they have to manage everyday information. They do emails, they do memos and whatever
else they're processing.
I'm not sure if... I don't know. This might not answer things to your satisfaction, but
I'll, you know, be glad to keep the conversation going. But I wonder if... One of the things
I was thinking of is that it's very easy to generate, I think, a lot of psychic baggage
with Emacs as you use it over time because you get... I think I mentioned this in the
talk. It's very... It's hard to use it and not be aware of all the different cool functionalities
that it's built on and the things that you can take advantage of. And part of that is
that as you develop your own workflows, you are not only developing them, but you're,
for pragmatic reasons, rejecting other things. But you don't, you know, you're still aware
that you've done that and you're aware of all the different possibilities that you've
kind of left behind, at least temporarily.
I wonder... I think at some point that baggage can impede you. Definitely can. It can make
you less open and feel less safe to try new things out. Especially if those things are...
I think sometimes it scales with the more useful and exciting and maybe even... Oh,
that's pretty... If it's going to be exciting and useful and significantly change things,
you could maybe feel extra resistant to try them out because you're not sure that you
want to deal with all that excitement. And sometimes, again, the more useful it is, maybe
the more resistant you are.
In the programming environment, you might consider the difference between Smalltalk
and C. And Smalltalk has all this, like Lisp, all this great interactive capability, but
you have the baggage of carrying this big image around that people didn't want many
years ago when it was popular. And C had nothing and still largely has nothing, right? Except
you've got Unix there. And so people stare at a blank screen. They have no dynamic support.
Maybe they have tags, but very little tooling. And yet, C dominates over Smalltalk. So I
think we're talking about a similar kind of problem that maybe the leap is so far for
people that you need to give them a series in between to transition them from their very
weak initial environment to something much, much stronger.
Yeah, that's a good point. And that's actually something that I think of for myself and thus
something I was thinking about in regards to my talk. When you know that you want to...
Let's consider the kind of user that you're talking about and hyperbole. And by the way,
I enjoyed your hyperbole talk, your hyper-org talk, but up until now I hadn't been familiar
with it. So I may say things that don't make any sense. But let's say this user that you're
talking about who you want to become more comfortable with hyperbole. I'll start from
the perspective of let's say they know they want to become more comfortable with it, but
they also are having trouble getting comfortable with that process. And so that's certainly
something I thought about building for myself and suggesting in this talk of when you know
that you want to accomplish something, when you know that you want to change some of your
habits to call them out and really put your habits on display for yourself. And rather
than trying to remember them and ingrain them into your finger muscle memory and all that
is to make some space to have your habits be public, not public necessarily, but just
explicit in your environment and allow yourself to be uncomfortable with new habits for a
while and that break out of the habitual space, give yourself some kind of mnemonic structure
that lets you do these things habitually that will eventually kind of become that mold into
which the habits will grow on top of rather than just trying to go from one set of habits
to a new set of habits. And I think Emacs is one of those things that is great for that
because it's the text, and especially what you demonstrated in hyperbole in that it seems
like it's very easy to just write some text up that can generate for you a cheat sheet
and say I've been using this on the left side, instead I want to use this on the right side
and maybe two buffers or something. And you don't have to worry about what it's called,
you don't have to worry about how to execute it or the key sequence or the function. When
you find one day you find yourself using something on the left side, I'd rather use this on the
right. And maybe over time you can move away from that and try to make it be more automatic.
But at least I think maybe the key there is just acknowledging that the things that are
habitual or that you want to become habitual can start to give yourself training wheels.
Right Jens, I'm very sorry I'm going to have to pause the conversation now. But don't leave
quite yet, this was a very interesting discussion and I would love to participate a little more
but we are actually preparing for the closing remarks in the background. But what I'm going
to suggest, because I don't want you both to lose steam and the closing remarks, you
can watch them in your own time, I'm just going to thank everyone really. So by all
means if you want to continue the discussion, you can stay in the room, we are still going
to be recording and if you want to continue the discussion for as long as you want, it's
going to be all good for us. It just won't be streamed now but it will eventually be
available. So if you want to join the discussion now,
you only have to go to the talk page and you will be able to join there. I'm really sorry
Bob, I'm going to have to end it off in 30 seconds because we need to move to the next
room. So I'll leave you to say bye Bob if you want to.
Okay, I will stay here and talk to whoever wants to talk.
Great and Bob do you want to say bye? Bye, thanks John, I appreciate it.
Okay see you in a bit, we'll be closing remarks in about one minute. Okay, really sorry for
recording short, we are now off stream and you can keep talking and we are recording
everything. Okay, see you in a bit, I have to rush.
So yeah, again, I don't want to keep you from the closing remarks.
No, I'm happy to talk to you. I think Leo just kept saying, well you can stay but I
have to cut it off. So I guess he was just saying the recording. I don't care.
Let me jump over to, there's another question that someone posted, I just want to make sure
I don't ignore that and then I'll.
The tip of the day package or some elaboration on that idea and Emacs help discovery for
lay users, does that already exist?
You know, I'm not, I can pretty, I don't know if the person who wrote this is, if it's
plasma strike, but hopefully they'll see the recording later. I'm confident in saying that
this does exist. I don't know what it is because I've never used it, I've never seen it, but
I know that something like this must exist, so I'm confident in saying that it does.
Yeah, I haven't seen it either.
If not, I mean, it probably would be something that would be relatively easy to make. Not
necessarily the person who wants this, but yeah, it's something that I could.
That's kind of interesting. If you put an org or a high rollo file together of all these
tips, it would be very easy to, yeah, have something on a timer that would just pop one
up every so often or based on some action, but that's kind of an interesting learning
technique. I certainly use that in some other packages where a lot of times you just X out
of it right away, but for things that actually provide useful tips, you tend to read them
and linger for a bit, right, before you move on, and that's a great way because, I mean,
after decades of using Emacs, there's definitely packages in Emacs, libraries that I've never
seen before, I didn't know were there, and that I sometimes find useful, so there's always
a lot to discover, and that feature discovery is a difficult thing, because that's why we
spend a lot of time documenting things, because like with the reference manual, hyperbole
about 170 pages, I don't expect people to read the manual, but to use it in info and
say I'm interested in the action button, okay, I'll just read that action button section,
and that's really what it's intended for, and why we provide quick access. In fact,
if you look at the menu structure, the pull-down menus for hyperbole, there's just one pull-down
menu, but the submenus under there, each one has an about or a doc item, and when you click
on that, it takes you exactly to the place in the manual, discussing the concept that's
covered by that menu, so it makes it very easy for people, but I was wondering, you
know, if you, I think you have a lot of good process-oriented thoughts, and I'll say, you
know, if you know who Doug Engelbart is or was, I worked with him a bit, and he was always
focused on you have to evolve your process while you evolve your technology, and clearly,
a lot of the people in the Emacs developer community are sort of focused on the technology,
which is common, right, even in corporations, and it's always sort of a struggle to get
people to try to evolve both at the same time, so I'd be interested in sort of conversing
along those lines about, you know, we've built, so we've built two levels, I think, in hyperbole,
we've built the toolkit of primitives that you can build from, and customize to your
own needs, but we haven't done a lot about, and people are always asking, well, what's
the workflow that I should use to integrate it with, and we're like, you know, well, what's
your knowledge workflow, you know, what sort of tasks do you have to do, and then we can
tell you something, but it is one of those general kinds of things, you know, like I
say, I use the K-outliner to capture requirements, because I want, when I share those requirements
with people, I want them to say, you know, well, item 9a, let's edit this this way, because
a lot of times, right, they can't interact with the document that directly, or they want
me to maintain it, so I find that everything is numbered that way, in any sort of structured
ideation process, to be extremely valuable, and so, but I think, you know, maybe, obviously,
as you said, you haven't used that, but, and I've worked on a lot of other Emacs stuff,
but I think it'd be valuable, you know, having some discussions with you, to talk about that,
you know, perspective from somebody trying to grok something like this, or, you know,
get deeper into Emacs, and I always feel like, like I'm developing some new software at work,
and our company is kind of moving from being a more consulting company to a technology
company, and I say, well, okay, we're doing this big, big set of applications, where's
the market input? The business people kind of wave their hands and say, you know, we
want something shiny, but we never get structured input from the actual clients that will be
the users, until we build something and put it in their hands, and I'm like, that's too
late, you know, and we need, so I think it's sort of true here, too, that it's very hard
to just, you know, like if I said, let's just have 10 people who have never tried hyperbole,
look at it, go through a process, and just write one page on their experience, you know,
but I think that'd be very hard to get that set of people together in general, you know,
without effort, significant effort.
That's a good point, because the people that would be able to use it, i.e. people who are
already Emacs users for the most part, they're probably either already familiar with it,
or busy, too, or maybe they have their own ways that they don't, they might be competent
enough to do it, but not comfortable enough to do it, or not interested enough to do it.
Maybe you have the intersection of all the different properties, which might be pretty
small.
Yeah, but just having those ideas, I think it helps us, you know, to shape, and I feel
like we can take what we have and meld it, like what, if you saw Carl Volt's talk on
his bi-directional links, I think that's a super valuable thing that we, you know, we
haven't really considered much, but people talk about a lot as a result of work, having
given them that capability for a while.
That was Eduardo Oakes, was that Eduardo Oakes, or?
No, no, that was not Eduardo.
He's an interesting fellow, you know, it's like clearly very bright, but he lives in
this academic-like bubble that, like, he wants to understand everything from the atomic level
up in order to use it, so, you know, imagine, like, personally, you're what?
I identify with that mindset, so I, so yeah, if you wanted to use toilet paper, would you
try to understand the atomic composition?
I'm just saying, he takes an extreme view, which may be, for him, that's what he finds
work, so, but some interesting things come out of that, which is his EEV kind of stuff,
which is very, very explicit, right?
Everything is laid out, so it's bulky in a sense, but it, but he's got some good ideas
on, like, tutorials and stuff, and he seems like he's more a scientist than a developer,
so, you know, when we were trying to, I said, you could, the things you want to do, Hyperbole
has a toolkit for, so just use Hyperbole, and then we'll help you shape whatever you
want to do, and that's where we were never able to do that, because he'd say, well, okay,
you have a button type that does what I want it to do, but now explain to me all the activation
process for that, and I'm like, well, then you'd have to understand the, you know, the
key parts of the Hyperbole code base, and you don't really need to, to do what we're
talking about, so we can't, you know, that would take a long time, so let's not do that,
and that never worked for him, so he decided to just build his own stuff, but then you
look into that stuff, and it's sort of what you described in your talk, is, you know,
it's not structured, it's, it's messy, it's, it's just sort of, you know, cobbled together,
so he's got the same, he's got the same issue that it's, he doesn't want to do it just for
his personal need, he wants, he wants this to be somebody that, something that people
use, and so he gives talks and things like that, and he, so he, he's got this way of
thinking that's very different than other people, that keeps his stuff away from people,
but that's not his intention, it's just, you know, sort of the operational mechanics of
the way it is, and I'd love, you know, I'd love to help him with that, or do something,
he's a very nice fellow, but I haven't gotten him past the, you know, there are other abstraction
levels besides the atomic level, let's, let's work on some of those levels, for him, you
know, there's some sort of barrier, I think, there, so you're saying you're a little like
that too? You have to get your hands on everything? Yeah, and I think that's, and full disclosure,
I don't, I didn't have a lot of time to write, or to get in, I didn't have a lot of, like,
in those 10 minutes to say everything I wanted to say, like, I'm not, I don't want to give
the impression that I'm not a technical person, I am, I am a programmer, and I've been, like
I said, I've been using Emacs for a very long time, just that over time, I probably, you
know, just kind of have stayed in my personal sphere, and kind of worked, carved out a little
thing that works for me, so I, my perspective might be a little surprising, to come up,
you know, to people who might think, well, a talk like that, you're, you know, you're
still a beginner, or you're still on the fringes, I'm like, no, I don't think I'm, I'm neither,
neither beginner, feel like I'm a beginner, nor am I on the fringes of anything, I've
just, my path has taken me through a certain way that is, is personal, it just happens,
you know, but I think what you're saying earlier, is that, to identify, is, is that, that is
one tension, the tension you were just mentioning, of, want to do something, but the Emacs is
just one of those platforms where, where it's so, can entice you to do things, it can be
so interesting and enticing to do certain things that you, it can lead to a lot of pain,
and that you can, and confusion, where you can really want to learn something, and think,
in your head, I'm always, you know, I'm, you know, I'm always thinking of, it was a dialogue
with, you know, a dozen people when I used Emacs, a dozen other people whose, whose work
I've read about, and developers, I've, I've read their works and stuff, of, it's hard
to be doing something, and not be thinking about making it available for somebody else
to use, I think it's, it's both very personal, and it's also hard to have a personal barrier,
because I'm always, you know, I'm always thinking about, how would I expose this functionality
for general purposes, how would I, how would I publish this, and so I can identify with
that, and also, also, I want, you, you want to know, both, maybe there's just certain
personalities, and mine would be one of them, where you really want to know why things are
happening the way that they're happening, and I think Emacs is one of those places where,
when you come in, you come in on the ground floor, and you see, wow, I can go up so high,
but also, you, you can look down and say, well, there's a hundred floors below me, and
you get torn, you know.
I would ask a question like, do you, do you tend to look at the way Lisp primitives are
implemented in C, or do you just focus on the documentation of the Lisp function, and
then work from there, in terms of your Emacs, how far down you go?
Good question.
It's changed recently.
I'd say, up until a couple years ago, I was mostly focused on the, on inside, you know,
inside the Lisp machine, and going up, but I've started getting a little more curious
about the C layer below that.
One of the things I started looking at was some of the way that the key maps have been
handled, the key, the map lookups were handled at the C level, because of the, my Viper,
sort of affinity, my affinity for Viper, because there's some, some functionality there that
changed or was made a little bit, the implementation was made a little bit different.
So I guess, I guess both, but I, but I could understand that, yeah, there's, I, I never
felt like I had to understand anything below that level, but just, it's good that.
And do you go up, do you spend a lot of time thinking about the user level and user experience,
user interfaces in your other work even, or, you know, just to get an idea of the sort
of problems you'd like to sink your teeth into, you know, how you might provide some
feedback on the hyperbole side, if you were to?
I think I'm, I, I, in terms of technical stuff, I do like to stay more, I get more satisfaction,
I think, thinking about the, the problem solving, especially in Emacs, just how to build, how
to solve a problem in general, just, you know, UI level stuff or user experience stuff, I
think it's just, it's, it's harder, it can be harder to do it right, but I guess that's
something that I don't, I just haven't, I guess I haven't put, I guess I put more of
my energy towards the, the middle tier of things of kind of just building general solutions.
But if, but if it comes, I mean, I, hyperbole is definitely high, if not on the top of my
list now, coming out of today's presentation and hearing about it today, of things to look
at no matter what.
So, I mean, I'm, I'm eager to learn more about it and use it from, from wherever, wherever
I end up kind of landing on, on that, that spectrum.
Well, I'm wondering if you might have some time to, so we have, there's two other people
who gave the two other talks who work with me.
We do a Sunday meeting, Sunday morning, East coast time, you know, one guy's on the development
and the other is Ramin, who is a writer.
And I mean, he's an ML engineer too, but he's new to hyperbole.
So he's kind of, you know, converting some of what he did in a word to hyperbole.
So he's kind of a good feedback loop for us there too.
Matt and I have been, you know, deep in it for many years, so we can't, we can't see
it in an unbiased way.
And I'm just thinking, you know, maybe if you have a bit of time, you may want to, you
know, think about giving us some structured feedback or, you know, coming to one of those
meetings chatting with us.
Yeah.
You know, so, and I'm happy to answer your questions too, because I think, I just feel
like there's, I'll tell you, this is, so my background with Emacs, besides as a user,
I built something called InfoDoc, which was an extensive IDE to try to bring out Emacs
functionality.
Many years ago, it was an extensive set of menus, popup menus, pull down menus, and fixing
a lot of stuff like, like in our mail, the keys and the interface wasn't the same between
the summary buffer and the main buffer.
And I, I normalized all that fixed stuff in Dura.
All of that was like all rolled into InfoDoc so that a lot of these warts that people talk
about that still are there to this day, some of them I see got put together and that was
just built to top Zmax, the fork, XZmax fork of, you know, when Jamie Zawinski was doing
it.
And so I, you know, I still use some of that with Gnuely Max, but I never took the time
to repackage it and stuff like that.
So that's sort of sitting out there.
And then I built the OO browser, which was a small talk like a code browser for eight
different object oriented languages.
And that's sitting out there waiting for just a, I had it ready, largely ready except for
some documentation and I have no time to work on it.
So it's never been, the modern version hasn't been republished for people to use, but you
know, it sort of tells you some of the areas that, that I've spent a lot of time in and
I've built some pretty big things.
So I've gotten to see, you know, what's absorbable and what's not.
And, you know, there is a lot of people sort of staying down at that low level that I think
you do tend to run into with Emacs users, but there was like people love people who
use the OO browser.
That was a very good user experience because it was just very smooth and it had multiple
windows and, you know, did what people wanted.
And it was very fast because I focused on the algorithms and there was nothing else
that could do what it could do.
Now, now that we have all these language server protocols, which I still think are not quite
where they should be on the backend, but you know, it's nice that now they're integrating
Eclot.
So I'm not a big user of those yet, but I hope to get more leverage out of them if they,
in fact, you know, can give them, satisfy the queries that I really need in my work.
So yeah, I think you'll find, you'll definitely find some utility.
I think, you know, once you grok a bit, and I don't think it'll take you that long to
get enough of a sense of hyperbole to start building a couple types, button types yourself
and tailoring it to whatever your needs are.
But as you said, I'm kind of interested in your thoughts about what will make that easier
for people maybe with, maybe with not as much technical knowledge as you have.
And just, you know, that you're willing to put yourself in somebody else's shoes, I think
is a very valuable kind of way to be and something I'd like to.
Well, I certainly, I'm willing to, willing to try, can't promise what my mindset will
end up producing, but I, you know, it's, let's put it this way.
If I could, if I could benefit from what you've created, benefit from learning about it, and
at the same time, potentially give some benefit back, you know, that seems like it's a win-win-win.
So I'm happy.
Well, I'd be very surprised if you can't, but we, we accept that kind of feedback too,
is that, you know, there's too much of a barrier to entry for this reason here.
I love to hear those things too, because, you know, there have been things that weren't
there that we've built after, like there's a guy, Sean, Sean something, he's like a business
user who runs his business on this custom database that he's built.
And he uses hyperbole as a front end to that backend database.
He calls it, I forget it's hyper or something.
And he, he has a lot of deeper thoughts, you know, very specific, like he'll write it with
just one issue that he's trying to do.
And sometimes, you know, we'll implement things for him.
And that seems to work pretty well.
Sometimes he wants things that are further afield, you know, and we don't go there,
but he's, he's a useful, one of the users on the very low traffic hyperbole mail list.
So he's probably responsible for 80% of the traffic, right?
He's the Pareto subscriber.
Yeah.
So, but I look forward to it and I think you'd like Ramin and Matt, Matt is an engineer for
Spotify and he has implemented 260 test cases for hyperbole that are run against the three
major versions of Emacs every time we commit.
And that's proven to be very successful because, you know, sometimes we're modifying things
at the engine level and who knows what, what set of button types that affects.
So it works really well when we're, and we've had very good success that we have very few,
you know, bugs that we don't know about already being found by users once we make a release.
It seems like PlasmaStrike wants to jump in.
I'm sorry.
I didn't, wasn't.
I did see your link earlier possibly by the Emacs dashboard and I opened it, it looked
pretty cool.
Bob, you might, you might, yeah.
I've been getting my partner into LogSec with org, which is kind of like org-roam for knowledge
bases.
And I've been using that, having my knowledge base on LogSec.
He could look at it, it's getting synchronized with sync thing and he can see how I do the
stuff.
He can replicate it if he wants to.
Then I'm thinking about putting CRDT with Emacs so that we could both edit the same
document in real time.
And that way I can get Emacs to work with the same data set as org-roam and that way
he doesn't have to learn absolutely everything that Emacs has to offer.
There's also, I can use all that stuff if I want to use it.
That's cool.
I, you know, I've heard of that, but not necessarily, didn't know anything about it.
So that's, I'm looking, you know, all I guess all I can say at this point is that it looks
really cool.
It's, does it sounds like you're saying it's front, it's easy to, easy accessible, easily
to get into.
Well, you can also put it on your phone too.
So it would probably be a really good way of doing that, even though it's harder to
get Emacs on your phone and on iPhones as well.
You got to figure out, that's what people were asking about, touchscreens.
Have we thought about how to use touchscreens?
I think it's an interesting challenge for Emacs, you know, you even talk about mouse
buttons and people kind of freak out a lot of times because they're so keyboard driven.
Well, one of the great things about Emacs is it's a keyboard is a first citizen and
mouse can't be a first citizen because you're going to have to switch between it and all
the time.
If you go back to Engelbart's work, it was one hand on the mouse, one hand on the keyboard.
And you know, we do miss some of that, that ability to point at things and make operations
on them.
We have things like Avi, I believe it is, right, for where you can move around across
windows and buffers very rapidly.
So you can get to like an exact point in a buffer much faster, and then you could act
on it, you know, doing it that way.
So it's kind of like a replacement for that.
But it's amazing when you start to think a little differently like that.
And certainly people have done that with split keyboards and they, some people only use half
of the keyboard then.
So and they have all the modifier keys, you know, that's what we're doing.
In fact, Hyperbole has a module that isn't active, but it's sitting out there.
And it turns the mouse keys into two modifier buttons.
So it could be control and meta, or whatever have you.
And so if you want to operate that way, you can emulate what Engelbart was doing with
your regular keyboard and the mouse.
Didn't that, didn't he have like a weird mouse where it had like more buttons on it?
He was three buttons, actually, yeah.
He had the chord keyboard you're thinking of.
The keyboard was like five keys that you could press as chords.
So you could press all five or three of them, and they would produce different character
outputs.
I mean, they had a lot of things that we don't have.
You know, their file system was node based, and so everything could be hyperlinked to.
And they had permanent IDs everywhere, and they had journals.
And they had implemented almost all of this in assembly at first, and it was on a time
shared machine.
So everything was collaborative instead of individual.
But you know, so we'll get there eventually.
It's a lot of, a lot of things have changed that we've had to, you know, fight against
separating people from collaborating.
And now everybody's trying to get back to you and say, let's build collaborative software.
Yeah, I noticed that's another, another one of those cycles that I noticed was the talk
of, I forget who, it was the guy who did the SQLite thing and how he, how he was basically
saying, hey, text is great, but these, these somewhat relational databases have a lot of
things to offer.
And I'm thinking, yeah, of course, I agree.
But it's just funny how so much of the Emacs ethos has been, text can do so much, and they
were right.
And then now, like, this is, it's like a turning point to say, hey, text can't do all these
things, but let's use Emacs to take advantage of all this non-text stuff too.
That's just, that's just one of those, kind of those cyclical things of where we do what
we can with text, and then someone notices that, hey, we, maybe we could do something
without text, and then that, that balance might shift and just go back and forth.
And it sounds like it's the same, like you're talking about with collaboration.
Have you ever seen VisiData?
It's a curses program that one guy has written that can manipulate any sort of tabular information.
It's the, it's the Emacs of, like, you don't want to use a spreadsheet, and you want to
do data analysis.
It's pretty unbelievable what's in there.
It's written in Python.
But he has asynchronous slurping of super large CSVs that are compressed and encrypted.
So it's basically like a Unix tool.
You can use a command line wise, but then it gives you a curses interface, and you can
slice and dice and get histograms.
So it's kind of amazing.
I tried, the key bindings were so different.
I did some work to try to make it more Emacs-like in that.
But he would have something that would be so valuable if it wasn't connected to the
curses interface.
You know, it was an API, and, but he likes it that way.
And so he just keeps developing it.
But it's really amazing if you have to process a lot of data and don't want to use Excel
or something.
That's with a Z, Visi or S, or?
No, V-I-S-I-D-A-T-A.
You'll find it.
It's his name is Paul Swanson.
It's not Swanson.
It's something like that, though.
I think it is.
I think according to his website, according to the website, it says Saul Pwonson.
So I'm guessing that.
Yes, Saul Pwonson.
I get it backwards.
I was Paul Swanson.
Yeah, he's a great guy.
That's another thing on my list.
It'll go.
Yeah, check it out.
Don't blow your mind what's in there.
And again, it's like there's a small community, but it's like all these people that it's such
a simple download, you know, it's a standalone executable, but largely, you know, people
just don't know about it.
I tripped over it and I'm like, my God, how do you get this far without me hearing about
it?
I think that's one of those.
Maybe it's a case where if you don't get a lot of attention, you end up doing things
in a way that you take things in the direction that you want to take them.
And sometimes that leads to a bad place and sometimes it leads to a really interesting
and good place.
And it's probably somewhere in between that seems like he's taking this to a place.
He had some usability issues and then he got like two other people on the team and they
really helped him, I think with that, you know, he takes feedback pretty well and the
team takes feedback well.
So they've been evolving it, you know, from version one to like, I think they're on three
now and you know, it's come a long way that way too.
And now he's got a job, I believe, where he can work on it as well.
So yeah, that should advance it a lot too.
So yeah, there's so much good stuff going on, you know, and it's just what's not going
on is sort of what we had long ago was the reusability.
Nobody's really building libraries anymore, you know, that people can build on.
It's all like, well, we got to wrap a web app around our API and that's it.
And we're not going to make the code underlying the API shareable.
You have to consume it, but that's all you can do.
And so I think where everybody's rebuilding the same things again and again now, because
sort of what Stallman talks about, that sharing culture has been snuffed out so broadly, you
know, in terms of what people spend most of their waking hours on, right?
As professional developers and, you know, you kind of miss it, right?
From when you could, because having written that old browser, I mean, what I would do,
what I remember doing is saying, okay, here's a thousand classes.
I'll just run my browser over it and get to understand the interrelationships.
And it's like, well, where are those like, you know, they're out there, there's still
numerical libraries and things, but you just don't have the ecosystem because the energy
is going somewhere else, you know, to the finished products, more than reusable building
blocks.
I think.
Yeah.
Have you heard of Glorious Toolkit?
I think that's what it's called, but it's a continuation of Smalltalk and it has a lot
of concepts like that where you have multiple representations of the same data.
Like the, also that Mother of All Demos where Engelbarton was doing that.
Yeah.
I know, I've seen that many times.
I got to work with Doug maybe for a year or so.
By the way, Plasma Strike, I'm going to put that on my queue to watch because I've never
actually watched.
I know about it.
Oh yeah.
It's great.
It's nice to see him as a young man too.
Like that was 1968, he started like 1957 or something.
The stuff they had before 1960 is incredible.
There's also another spreadsheet, like what you're talking about, but an Emacs and that
talk right there too, but yeah.
All this, I mean, just those initial tips, you know, I was finding stuff that I need.
So I like that idea, I think might do something with that if we can get a good database and
link it into Hyperbole with some simple exposure that kind of gets people into some of this
but I'll tell you what I really want that I can't find.
There's so much effort at low code environments now.
I want a low code environment for spinning up web apps inside a company where it's not
your focus.
It's just for an internal app, right?
Like we want to do say time tracking for one small team and we want to build it ourselves.
You know, that's not the real use case, but if you took something like that, so you don't
have a lot of resources, you don't have a lot of time, you know how to program, but
you want something that lets you operate like you're building a Python command line thing,
but you want it to be a web app.
There's a cool project I saw for that that would be, that was a peer-to-peer KISS web
browser.
Because I've looked at a lot of these, you know, there's no code DB.
The best one that I came to but has been hard to set up internally was, it's like from a
German company, it's like designed in Germany and implemented in China, a lot or pieces
of it, and what is it called?
I'll have to look at my database.
There's like something like Seaborn or something like that.
There's a couple of projects that are named that way, but let's see, Seaborn, low code.
Let's see something, find it, but, oh, low code, so there's something, it's amazing to
me, oh, C table, that's it, C table, SEA table, that's kind of one we've been trying to get
to work, but there's still limits.
There's an environment where like if Emacs could let you do the mock-up of your web app
using Lisp and then could be fully deployable onto a web stack, that would be, I mean, we
have a web server, it's just a question of, and we have like C-based fast web servers
that you could interface to Lisp, so I don't think like the capacity is the problem, but
nobody's gone from providing the web server to here's how you could program the front
end and connect it to the back end all in Lisp.
That's one of my biggest issues is like, and you see it in the hyperbole work, is I want
simplicity and uniformity.
I can't like program in three languages at the same time, so I can't use JavaScript on
the front end and Python on the back end and then have to deal with CSS as well.
And HTML.
Yeah.
And HTML.
It's like my mind just cracks up and I'm like, why do, and even if you were brought up that
way, like how can you be a 22-year-old and say, oh, this is so simple, because they do,
they say that all the time.
Well, this is a really simple thing to do.
I mean, yeah, if you're copying and pasting all your code, which is apparently what has
become common now, right, is I'll just use this template, then yeah, that's simple.
But what about building it originally?
It's like, there's just so much for your mind to process.
And there was something called Meta HTML, which was really cool when HTML first came
out, and you're not going to be able to find this or even a reference to it, probably.
But this was two guys from MIT, and they said, okay, instead of programming at the HTML level,
let's write a list-like interpreter that uses HTML syntax, but will give you all the higher
level programming constructs you need.
And so you could write stuff that looked like HTML, but you'd be processing lists of things
and manipulating the DOM in these very abstract ways and very little code.
And again, you didn't have to mix a different syntax in like you have to now.
It was great, and it wasn't a lot of code, and it worked, and nobody cared.
Nobody did anything with it.
It died on the vine.
Well, we didn't need to endlessly measure every little mouse movement and eyeball engagement
and then monetize it and analyze it.
So you could focus on just doing what you needed to do.
Yeah.
Well, that's right.
Friction drives.
That's what I love.
I'm stuck in a Microsoft environment now where there's a little bit of Linux here and there,
but I'm either a Mac user.
I've always been a Unix user, so Windows is enormously painful despite the strides that
they've made.
I always look at it, and I say, well, it's a brilliant business perspective because they
know they create so many problems for people, so much friction that it creates enormous
economic opportunities for many, many people, and that's what they do.
They have WSL.
Do you know about that?
The Windows System for Linux, yeah.
They had a guy working on that who was leading it, and they were just making stride after
stride, and apparently some high-level executive probably did not like seeing this, and so
they moved this guy off, and now it's like Microsofty.
So now all you see come out of there is like we've improved Windows Terminal, and the whole
WSL thing moves at a snail's pace now, and you have to think that wasn't just like the
guy got promoted, but that there was a strategic decision that this was helping people too
much to live in a non-Windows environment in their mind, and we can't be supporting
that.
I was going to say, even though if you say, I want to use Kubernetes or in Azure, they
say, okay, use Linux VMs, so they'll do that all day long and tell you not to use Windows,
so there is still parts of the company that are like that and are open to it, but they
have it pretty well locked down.
I think it goes in line with the attention economy where they want to control the computing
experience, and you want to use Microsoft apps, Microsoft Office.
We don't want to make sure that you can reach out too easily into other ecosystems.
Embrace, extend, extinguish, right?
Is that the...
Yep.
That's it.
An interesting Windows feature is you can update Windows, see that it's all the way
up to date, reboot it, wait a day, or wait a day, and all of a sudden you have more updates
for like a week or something along those lines.
I don't know of any other operating system that does that.
You only have two minutes until your reboot is done, and then it's like it comes back.
Now it's an hour, and then another half an hour, right?
They only give you a little snippet.
Is PlasmaStrike, by the way, is that stack that you're describing with LogSec and syncing
and everything?
Is that something that you've published any examples?
I saw you said something in the IRC, but I just lost track of what was going on in IRC,
so I'm sorry if I missed that.
No, I haven't.
This is although now I'm thinking about just putting a whole bunch of some resources together
of HyperBowl does a really good job of showing you a knowledge base, plus enough configuration
to use an EEV does a really good job of showing you enough in-source documentation to play
it out and see how it actually works in practice.
Our Chrome needs something like that, so I don't know if I'll...
But you need some minimal config to work with that, so you can look at the more philosophy
plus packages combination.
How do you guys like the HyperBorg term, if we use that?
Does that strike you as a little...
Was that what you were going for?
Were you trying to conjure up the Borg?
Well, yeah.
Well, Sasha came up with HyperOrg for hyperbole and org, and then I thought, well, it'd be
funnier if we called it HyperBorg, because it kind of is like Stalvan talks about org
wants to take you into this environment, and hyperbole certainly does too, so if we put
the two together, we would definitely have something like the Borg.
My impression, and I said something to Kielaro, I don't know if I spoke wrong, but my impression
was that this was not something that was going to be created, this was just a way, just like
a...
Oh, right.
It's just a...
Yeah, the music kind of term, but I do want to do more work.
I've joined the org mail list, and I mean, just I did a lot of work for that presentation
and that sort of struck me, and I said, there's a certain level of work we need to do.
Years ago, we were thinking we'd put hyperbole into Emacs, now that org is...
There's no reason not to, and were it to be there, there are things that there's namings
that we would correct, and the interface points to org, we would want to do something about
and work out with them, especially the made a return key.
That's the main, if we could resolve that between the two packages better, and we've
done a pretty good job just on hyperboles in, but we've never talked to the org people
about it.
It kind of seems like the term would work better the opposite way, because org wants
to go around and doesn't have that modularity that your package has.
So you're suggesting like, let them give the key over to us, and then we'll support some
of their...
Well, it's more reading the board taking over everything, because org mode comes and they
take over...
All their code works with org mode, not K outline or markdown mode or anything along
those lines.
Yeah, more, so the board part comes more from the hyperbole side, yeah.
Well, but maybe it's fitting in the long run, because no matter...
Perhaps if you provide a, or if hyperbole provides a very convenient enhancement on
top of how people used to use org mode, it'll just become part of org mode eventually.
Yeah, that's something I can see too, is that they just become one big thing that Stallman
doesn't like, because we do have a bit of that in all of them.
I mean, I totally get what he's saying and I buy it, I'm kind of like a functional programmer
and I like bottom up development, but people ask us all the time, okay, if you have four
or five things in hyperbole, why don't you separate them into separate packages?
And it was the same thing for Engelbart.
Well, one, it would be a lot more overhead just in separate manuals and dealing with
separate communities.
We want everyone who uses it to have the same baseline experience.
And so even though, yes, you could separate out the button functionality from the K-outliner
and the Rolodex, and the Rolodex originally was a separate thing by itself, we find putting
them all together gives people the same thing that Emacs provides, it's sort of, you don't
have to use all of the libraries, but having them there ensures you that when somebody
references it, it works and you have a lot fewer of those kinds of, well, I only have
the subsystem, so when I invoke your code, it breaks.
Yeah, I think, and I think, I mean, I don't think there's any, I don't personally have
like a preference as to what the right direction is, I just acknowledge that the downsides
and upsides of each choice, but one thing I have noticed is I think something, I think
it was McGit, that's how I say it, but, you know, initially it was one thing and now I
think it's turned into a dozen or maybe even a couple dozen different packages.
And I remember I went to update it once and they had to, you know, navigate a few different,
like, what's the word, combinatorial, you know, they had to go two or three levels of
dependencies deep in each level or introduce two dishes, yeah.
So yeah, that can happen, there's situations where you can see those downsides, where the
more, you know, splitting things apart is...
We're fighting with that at work right now, it's like, do we create more repos so we can
deliver microservices or, you know, how do we split things out on the containers and
it's very, very complicated and even, you know, with years, we've got years of experience
with our architects and we're all like going back and forth on how far to go because one
of the people is very worried that we get into that dependency hell kind of thing with
some of our new get packages.
So yeah, I wish there were easier solutions and that's, again, for hyperbole, there's,
you know, there's none of it, there's no external dependencies, it's just what version of Emacs
you're using and people don't realize that, yeah, they say, oh, it's so big, like, it's
dependent on all this other stuff, but it's not, it's just, you know, I mean, it will
leverage stuff, again, that's in core Emacs, but it won't require you to load a third party
package just because, you know, it's useful or interesting.
I think Emacs does a really good job on this because unlike the normal GUI apps, if I want
to change my theme in Emacs, I get to change everything to a dark theme or white theme
or whatever and unlike, and you can't really do that very in any way that shares any of
the code or the settings with all your GUI applications, but also with a terminal, you
miss out on a whole bunch more stuff because, well, you don't get GUIs or unless you're
talking about TUI apps, but they're not really CLI apps because they're like a half stepchild,
they don't get near as good themes because they can't integrate into all the packages
near as well, you know, mouse and all the various other things like that.
Where are you guys located?
I'm in, I'm in Virginia.
Oh, I just had guests from West Virginia.
I'm in Connecticut.
Utah.
Oh, wow.
Utah.
So we're almost spanning the entire continent, almost.
If we round up, we can consider it to be the case.
I work with a lot of people in India, so we've got like a 12 hour difference much of the
year.
That's fascinating to try to work through all the time, but on Hyperbole, we have one
guy in Sweden and one guy in Japan, so we're all over the map too.
Yeah, I was involved with a little hobby group for something unrelated and we were in various
countries and it was always, the best thing that we could do was just find the time at
which all of us would be the least miserable and the least tired and not, you know, there
was no good time for a meeting, there was just the least bad time.
Well, I was struggling to finish up my presentation and just, you know, I would like want to show
an example and then I'm like, well, I need to change the code a little bit so I go and,
you know, I'd add capability and Hyperbole and it was just a lot more work than I expected.
So November 4th was the deadline to send in your video.
That came and went and then I couldn't touch anything until the weekend and I get maybe
half a day with the holidays and stuff.
So comes to be last night, still haven't sent the video in.
You know, I had told them though a week ago that I'll do it live if I can't get the video
in, but I'm like, you know, it'd be nice to have it recorded and they do all this stuff
to it.
So I finished the video at 5.30 in the morning and I just, you know, no, I was dead so I
just uploaded it and I figured, you know, I had tested snippets before of how I recorded.
So I sent the two of them, I go to bed, I get up and I have a message waiting.
The video cuts off at 18 minutes and it was 36 minutes long and I'm like, oh, come on,
it must be the software, like just can't handle a file that size and it's stupid.
But I play it back on my system and it plays perfectly fine.
And they gave me the checksum of the file, the size of the file, those matched up.
So we knew we had uploaded a good thing.
So I just went back to them and said, no, it works here.
And then they went and researched and found, you know, it was their software and they were
able to make it work.
So I was good.
But you know, that's like right at the edge.
It's like 5.30 this morning.
Yeah.
And you haven't, and then you got some sleep after that?
Yeah.
I got up at like 9.30 so I'm running on a little, not too much sleep, but no, I was
very happy because I got to, I actually, like Rahman who did his and he sort of had his
face behind an Emacs window, transparency through the Emacs window.
He spent like at least 20 hours, like just on the video part or something.
I literally did one recording.
I mean, I had done samples a little bit, but I sat down, I said, I'm just going to try
to run through the whole thing, no breaks.
I did both my face, you know, they were separating their face video from their audio for some
reason.
And they did all these separate tracks, one recording and threw it over the wall.
So it was pretty good.
I think it's easier to do with a longer video because I was in much the same situation.
And if any organizers are reviewing this recording, you know, I was a day ahead of you, Bob.
I submitted it a day before you and I went to sleep, I think roughly 24 hours before
you did.
But you know, it's, so I was scrambling to do a lot of those things too, but you know,
because of my own fault.
And again, if any organizers are listening, I sincerely apologize and thank you and admire
your saintly level of tolerance and patience there.
And I hope that they spend a lot of time and energy just hitting things with baseball bats
after this conference, because I think that they've probably suppressed a lot of negative
energy from having to process things like that.
They're incredible.
I said thank you like an hour into the conference because it was so, I was looking at all the
detail they had and you know, you see the way it's grown from year to year that you
could just tell there was a tremendous amount of effort put in to have all these different
formats and dealing with it.
People have disabilities and you know, I mean, they're just very thoughtful all around and
a great set of people.
So I think every year they get better at it.
Yeah.
Yeah, they're clearly, I like they took a DevOps kind of approach to it, which you can
also see, I guess they have some people, they're using Ansible to maintain some of their environments.
So it's like, wow, that's a pretty advanced way to do it.
And it shows they struggled in parts, you know, it's like, like this, they had trouble,
you know, I was asking multiple times, it's like, is the video going to be playable?
And there'd like be no answer.
And then it's like, okay, don't worry, we're taking care of it.
But they couldn't say because they hadn't converted it the way they wanted to yet.
And then they finally got there and they like 20 minutes before the presentation is when
I guess I got on with you, right, plasma strike, and we did prep before prep.
So it was a good experience.
But I have to know, yeah, I thought I would have it done, no problem, November 4.
So I think that and I did get very busy at work, but you know, that tells you something
just about and I'm not, I don't do videos much.
So that was part of the problem.
Yeah, it's Yeah.
I mean, I'd say the most concrete lesson that I learned, maybe not even a lesson so much
as a as a punishment is that if I dare to submit anything next year, I'll, I'll make
sure that I'm done recording it before I even propose it.
Because I wouldn't want to have them wonder, is he gonna wait until the very end?
Like, I'm gonna, I'm sure I am.
So I will, I will have it done in the summer of 2023.
And I will include it, I will upload it before I even submit it to them.
Did you not get that message?
Sasha was so nice about it.
She's like, you know, it's really not a problem if you don't have time, you know, we can just
cancel.
And I'm like, I've never canceled on a talk before, so I'm gonna get it done, even if
I have to do it live.
Yeah, you know, I got I got similar ones got go ahead.
How would that work?
If you didn't know exactly how much time that you'd have for the talk?
If you're going to do it all in advance?
Oh, oh, for you, because it Yeah, well, you can take a shot.
Don't give me a slot.
You say I have a 20 minute video ready to go.
Yeah, yeah.
Or, I mean, and plus, I think it's also it would be it doesn't necessarily indicate that
it's the final product, but it could be the final product, you could say, Okay, here's,
here's 10 minutes or 15 minutes.
And I will try to iterate on this.
But if I if I default on this loan, so to speak, it's it serves as collateral, maybe
it's not, not necessarily the final product.
But if it needs to be the final product, they could use it that way.
I think the thing that they're most worried about was just having to having to process
things at the last minute and having to run it live, if necessary.
So I don't think they they, you know, care that much about changing, you know, changing
the length or so.
Well, maybe they would, I don't know.
But I guess that that would mess up the schedule.
Well, the the subtitles were really popular, I understand.
So that's, that's a big thing that would have been nice to have, which I imagine you're
gonna process.
Yeah, yeah, I, I, hopefully, I can, I can help them with with subtitling some of the
things that didn't have them yet.
Because, yeah, there's still a lot of work that I think needs to be done even after after
the fact.
And, you know, with transcribing these sessions, even not all of them, but at least some of
the questions and answers and things.
PlasmaStrike, did you that I hear that I understand you say that you you were a volunteer for
managing the this year?
No, I just I was just asking the question.
I got you.
No, I thought I heard you.
I might have misheard something you said earlier.
Are you Corbin?
Me?
Yeah.
No.
Okay.
I thought you sounded like Corbin.
You know him?
Maybe a little bit.
I can hear it a little bit.
Okay.
But you use, PlasmaStrike, you were saying that you you do use a lot of theming and things
like that in terms of like your like various applications, like color themes and things.
I've used various, I've Solarize, Doom themes, I think there's a Tron theme that I use, but
now I'm just using the Modus themes, just simple black and white that's done really
well.
Yeah.
Simplicity.
That was actually going to be one of the things that I wanted to mention in my talk.
But again, those 10 minutes were turned out to be brutal.
I wanted to mention how how people like like us and when I say us, I just mean I don't
mean necessarily you two, just people that I was speaking for, are maybe a little bit
scared of themes.
You know, like I was going to mention that we like I try to stay the heck away from fonts
and colors and things because I just, it's, I don't know if I have the bandwidth to keep
them.
I kind of just declare advanced bankruptcy on those and say, you know what, whatever
it looks like, I'm going to live with it.
I just look at like 20 themes, pick one that suits my taste and then live with that.
So I found one called Cream Soddy, like cream soda, but S-O-D-Y and that's what I use as
a dark theme and I find it, you know, very appealing in general.
So, but yeah, I was noticing like the org people have so much, tweaking the visuals,
you know, it was kind of amazing.
Some people's presentations, I'm like, I'm really not into that.
But I do have a feature in hyperbole, which is kind of cool.
So there's this subsystem called high control, which lets you control your windows and your
frames interactively.
So it's, it's kind of like you go into a mode and it stays live until you quit.
And so you can use regular insertion keys to manipulate things.
One of the things it has in conjunction with a package called Zoom Frame is you can change
your default face across like all your frames with one key, grow it, shrink it.
And I found that, and not just the default face, but all the related faces so that everything
stays a consistent size.
Every time I would try any of the built-in things, I would always end up changing a face
or multiple and something else would stay tiny.
And it just annoyed the hell out of me.
So I implemented that.
This was in high control or Zoom?
Yeah, it's in high control, the Z keys, you use I guess capital Z for make it bigger and
lowercase Z to make it smaller.
So you're zooming both ways.
And the neat thing is that what high control has is a persistent prefix argument.
So say like you want to move a window, say you want to move a frame two pixels at a time.
So you set the prefix argument to two, and then every time you hit your arrow key or
whatever moves it, it moves by two pixels.
You can change that to 20 and it'll move by 20 pixels.
And the 20 will apply to every successive operation until you change it.
And to change it, you just hit a decimal point.
So you can say period one, zero, and then you get a 10.
Or just set it to zero and then it's off.
And so it's very rapid.
So you're doing these single keys NPF dot one, zero.
And so you can string these together in your key series too.
And you get this incredible operation.
It can place frames at any of the corners or the top center of the screen too.
And on a Mac, it will account for the toolbar and only grow so it doesn't overlap that.
All these kind of fit and finish things are just pre-programmed in there.
So when you're actually doing it, I mean, don't you hate that?
It's like you expand your window programmatically and then half of it's off screen, right?
For no reason at all.
And then you got to go manipulate it.
So I don't know, there was one time when I decided to do this and I just thought of those
pain points and I took care of them all in there.
So that's kind of a useful thing.
And one guy, his fingers, if you saw the presentation, he was losing carpal tunnel like problems
but very severely.
So he went to voice control and he was using Emacs and he discovered high control.
And he said that was like a life changer because he always wanted to manipulate his windows,
his frames.
And now he didn't have a good way because he couldn't hit all these keystrokes.
And now he can just say those key sequences and it does it all for him very rapidly.
Another guy, years ago I was working with, there's this brilliant guy named, oh God,
this is, what is his name?
Works for Google now and it's an Indian name.
I forget his name, but he's been blind since birth.
And he got a PhD in computer science and he's worked before Google.
He worked at like Sun and just all the major companies.
And I guess a lot of his work is on making technology accessible to the blind or disabled.
So he wrote a package called EmacsSpeed, yeah, Raman, Raman is his name, TV Raman.
And so EmacsSpeak is another whole environment that lets a blind person utilize Emacs as
an advanced screen reader.
Instead of reading you the whole screen, it knows what your context is and it just reads
you appropriate stuff.
So like he can understand code very rapidly.
Additionally, he can change the speed of the voice so he can listen to something at five
times speed and absorb it.
So he can actually get a picture of code and manipulate it.
So he and I got together years ago and he integrated it with Hyperbole and he was using
Hyperbole to give a macro kind of capability in a lot of stuff.
So I thought that was very cool.
And he was just a very cool guy out in Silicon Valley.
So glad to see he's done so well all this time.
He's got an example config in his package.
I don't know if it has your package configured inside of it or...
I don't know.
I haven't.
He's got some for using CSS.
I think that he was talking, something I read is it would change how the tones and voices
that the voice was using.
Right.
The funny thing is that he's so devoted to his seeing eye dogs, right?
He's had to have a number of them through his life.
So he writes these fake press releases every time he releases a version and they're all
named after the dog and the dog is making the announcement.
It's like so and so is proud to announce Emacs, the friendliest dog release in history.
So they're kind of fun to read.
I've seen his messages on the mailing lists, rather I've seen his subject lines on the
mailing list because I usually don't have, I don't give myself the time to read a lot
of those messages.
But now that I have that context, I'll dig into his messages and see because it sounds
very interesting.
Yeah.
I mean, it would be.
And if you're like my son has no problem seeing, but he has a bit of trouble processing words
when he's reading.
So he uses audible while he reads and it's too slow for him.
So he uses audible at like twice the speed and finds that that really helps him understand
passages.
So it may have utility for people without visual disabilities too.
Good point.
Yeah.
That's probably so much there that doesn't really get thought about because just think
this is what, how we have to do it.
It's in front of you, consume it, consume it the same way everybody else consumes it.
And if you have trouble, then it's on you.
Well, here's an interesting usability to bit, Robin, a different Robin, the Robin who
works on hyperbole was showing me his presentation and he had the text of the presentation there.
And every time he would say something, the word that he was saying would be highlighted
on the screen.
And I'm like, wow, that's very impressive.
And it followed his speaking perfectly.
I'm like, how did you do that?
And he said, Oh, I'm just highlighting each word manually.
Wow.
Now that it's, it's like being a drummer, you know, he had such perfect cadence that
I couldn't tell that this wasn't automated, that he did it so beautifully while he was
speaking or, or watching him self speak, played back.
It would have been nice if it was an automated thing, but apparently it takes the human to
do it.
I had to rig something up when I was recording my video, cause I, I wrote, I did it, I scripted
it all.
Um, and I, I just couldn't, I wasn't, I didn't have the mental bandwidth to try to memorize
it at that point.
So I just split everything up into, into half paragraphs basically, and tried to get it
up as close to my camera as I could, um, scroll my mouse wheel.
Every time I came to the end of a paragraph, I had to scroll the script with one hand and
my other hand was controlling the slot, the so-called slide show, which was just paging
through my org, my org outline.
Um, and I think about five to 10 times I had to stop recording it because I, I scrolled,
I got off sync with, with either my script or my outline or both.
And just, you know, with 10 minutes, like, Oh, I can't go back and I lost, I lost like
5% of my time.
I have to start over.
So I can't imagine doing it on a word by word basis.
It's strange we're still recording this, but we're getting into just the, you know, interesting
story.
Oh, it's the last thing.
So, you know, this is just kind of like, I feel like this is the, the after party, right?
Maybe they'll cut it off.
So I work with a British guy, brilliant, uh, mathematician kind of guy.
He's a financial guy and, uh, he, he has that, you know, often British kind of capability.
He, he speaks beautifully, but he can speak off the cuff about anything he's working on,
just like he has spent a week, uh, working on it.
So he gets called on like, you know, the bigger bosses will say, we got to show this, do this
demo for this client, literally like five minutes ahead of time, and he'll just go into
it and there won't be an um, there won't be a pause.
It'll just be this fluid sort of thing.
And I'm like, man, if you could bottle that, uh, you know, because do it, what you're saying,
doing, uh, you're on camera, doing a video thing, speaking, managing your thoughts, you
know, keeping your context, it's, uh, super hard, I think.
And, uh, when you see somebody who has that, like Steve Jobs, you know, he would practice
I guess, but he had that ability that he could communicate anything, uh, beautifully.
That's an art.
Maybe not.
Maybe it's just a personality trait.
It's a, yeah, I don't, I don't think you can train, you can definitely improve, but I don't
think you can train people if you're not born with that kind of silver tongue.
Yeah.
Right.
And maybe it has to do with not being conscious of things.
I think a lot of times it has, it's, you've never really thought about what, about what
happens if you mess up or something just hasn't, you're blessed to not be able to worry about
certain things.
Yeah, that's true.
That's why you see all the technical people that struggle, right, is, uh, but he's, you
know, he has that too.
He'll be very self-critical at times and stuff.
But I think when, you know, like all of us, I mean, if I start out, I may be thinking
about a bunch of things, but once I'm into it, you can see, you know, you sort of relax
and you're just focused on that and all those other things kind of fade away, right?
You can get into that zone.
It's there for all of us.
Well, as you become competent in things, the technology more and more disappears because
I don't, as Emacs users, we don't think about what keyboards we, our touch typing is generally
at another level because we split the windows without ever thinking about it.
Muscle memory.
Yeah.
And that's what I'm saying.
It's like, use that for like the value add and then, you know, literally have your muscles
almost take care of the stuff that's silly, like, you know, opening a directory when it's
part of a path, colon, separated, set of things.
I don't want to think about that.
I just want to point and go.
And I don't want to know what the key binding is or any of that kind of stuff, so that we're
definitely trying to like push it down to your unconscious and then see how far we can
take that, you know, like what, how can you fly?
Uh, I, you know, people sometimes have said there's some magic or that's why I mentioned
that term today, but I think that's an important concept.
You know, if it, if it seems like magic, then you've probably got it down to the right level
that people don't have to think about it anymore and they're just, it's in their subconscious
and they can move on to more interesting things, which is sort of why we build software in
the first place.
I think, right.
It's to automate the mundane and let us keep adding value at another level.
Yeah.
Although it's very hard to remember that sometimes.
Right.
When you're, when you're saying, Oh, move this pixel over here.
Right?
Yeah.
Like you were saying about front end development and how hard it can be sometimes that all
the business people want to put their two cents in, it has to be, it has to be making
somebody money at some point.
Yeah.
It's helpful, helpful when it does, but you know, not all you can build.
You can spend a lot of money on things and they, I mean, look at, uh, look at what's
happening to the tech companies now after billions of dollars invested and they're just
throwing away thousands of people and all their knowledge bases and yeah, it's, it's
competitive.
I mean, you know, it's like, we don't need a thousand task management, commercial tools,
right?
Project management tools.
So the market will shake out.
There'll be three big ones maybe.
And then everybody else is, if they exist, they're losing money.
So what, you know, so are you going to be one of those three?
That's that's the problem is that there's not enough room left for a lot of the things
that people are trying to do.
You talked about advancing things.
It's like stuff like hyperbole or this mother of all demos.
It's like sometimes we don't always have to move forward because all this mother of all
demos is in a lot of ways, way ahead of anything we have now.
And seems like it's ahead of hyperbole in a lot of ways and well, I've talked to a lot
of non-technical people and they always say, you know, the problem I have is technology
moves so fast.
I can't keep up.
And I say, well, actually in thinking about it over decades now that I've aged, uh, I
see it as cycles much more, right?
And like a sine wave that, uh, first of all, we, we do lose knowledge.
We don't have a good way of capturing it.
And I mean, I literally knew something about Engelbart's work and it was over a decade
later that I rediscovered it and, and then got in touch and interacted with him.
So, so we're definitely like forgetting about the past and get a new generation in.
They don't know the lessons.
They screwed things up.
And eventually we rediscover that somebody already solved this and we can go and use
it again.
And then we start building on that and then the war happens and it gets destroyed.
And then we got, so, so you actually get a lot of time, right?
Like ethernet, right?
To the masses from when it was invented to when it got deployed, uh, you know, hypertext.
So let's say if Engelbart was showing it in 1968 and before that Ted Nelson was opining
about it a ton, uh, so 1991 or two is when we got the web.
So 25 years at least.
And I think that's sort of cycles.
I don't think there's a lot of technology cycles that are less than 10 years, uh, but
you often see that the 10 to 15 to 20 year cycles from research to, you know, broad consumer
adoption, uh, you've got about that amount of time to deal with it.
So if you can have a research team that stays 10 years ahead of like what's out in the marketplace,
you have lots of time to develop your product.
It's not this, it's gotta be out yesterday.
You only have two months or the market's going to close up.
But it's very difficult to convince business people of that because there's so much chatter
on the business side and people will show their, their mockups and their demos very
broadly.
And then they're like, they've got it, you know, it's like, what have they got?
Well that I saw it, I saw it.
Yeah.
And what's behind that thing that you saw, you know, they just whipped it up right over
a weekend and there's nothing, there's no database, there's no, uh, there's no user
validation.
So you kind of have to contend with that, which is probably why a lot of Emacs users
are in academia and they don't want to deal with those issues.
Yeah.
It's kind of like also advanced by doing the, uh, doubling down on the stuff that works
like for instance, uh, cars like, Oh look, the car's better.
It's got a higher Bluetooth version.
See it's better.
But what about the gas mileage?
How long does the motor last?
But it's got a higher Bluetooth version.
See it's, it's more technology and then, then the job is to create the need and the desire
for that higher Bluetooth version.
Right.
Yeah.
Well, haven't you bought like the same brand of car, even the same model, like a couple
of years later and you're like, what did I just buy?
I really loved the one from five years before.
My, my first job out of school was in Motorola, which had a great engineering culture.
But there came a time when, uh, they, they brought in automotive designers to shape,
uh, the shape, the physical shape of the products.
And we had some very sexy, beautiful looking things that those guys left the company and
they hired a bunch of people pretty much out of college, you know, who had studied the
field.
And all of a sudden we had like these blocky kinds of things that like, nobody would want
to hold in their hand and, uh, and I'm like, what, wait, what just happened?
Didn't they document any of their work or anything?
But that's, you know, we really do need the knowledge base inside people's head because
we're nowhere near documenting it well enough.
Uh, the design principles that people use, you know, you look at, you can see it in Apple
a little bit too, right?
Since Johnny Ive left, it's like, yeah, where's, where's the next design language?
I just got an update to my iPhone and I noticed they changed some of the icons, but they just
made like the time on my home screen, like three times as thick, the font width, you
know, it's like ultra bold and I'm like, yeah, that it doesn't really look right.
It just looks like it's in my face and I'm like, well, somebody, you know, got that through
whatever they're running there now, but I've would have tossed that on the, you know, the
bad idea pile.
I think.
Huh?
It seems like a bit of an obnoxious change to make it for something that is so supposed
to be, it's when you want it, you really want it and when you don't want it, it's supposed
to be unobtrusive.
I don't know that way.
Yeah.
Oh.
Yeah.
I wonder if that uses more power since it's, if it's white using all your, all your pixels
there.
Oh yeah.
So I guess we have time in the end.
I mean that like, you know, we all have these crazy deadlines, but in the end to actually
move the needle forward, it's going to take a while and there's going to be certain steps
backwards.
And I think Emacs is sort of our shared community knowledge base, right?
As long as we have these libraries, even if they get a little out of date, we can update
them to the next generation when we're ready.
And that's something that a lot of people don't have, right?
They're just going from application to applications and they're losing all the core capabilities
every time they transition.
Well I think that's the, like when I was talking about the themes and the modularity and just
using all that stuff is, if you can use all that stuff and especially if you can use a
whole bunch of really old code, that's, that's the tricky question of how do you use as many
things as you, as possible at once without everything clobbering each other?
Well, I learned this lesson, don't, don't add a date created entry to your code files
if you don't also include a last modified date, because we had 1991 entries in hyperbole
files and people would download it and they look and they're like, this thing is ancient.
I'm not going to use this because we had pulled out the modified because you need certain
code to update the modified automatically when you save it.
And you know, not every developer would necessarily have that.
So, but when that started happening, I said, we'll put this back because they didn't want
to get rid of the create date and lose that, that you sort of know how far back it goes.
Yeah, yeah, I've, I've always gotten a little, I always find it interesting when I see working
with something and I, and I realized that it hasn't been touched for, or it appears
not to have been touched for a couple of decades and I think, oh my gosh, either I, if I found
a problem, I'm thinking, oh, I, this can't be right.
I must be missing something here because there's no way that this problem could have existed
for 20 years and no one ever noticed it or cared about it.
And sometimes I'm wrong.
Sometimes I'm right.
It's not a problem.
Well, you have this quote for Emacs, it's like Emacs is you want editors, like you want
wine.
I think it's wine.
It's like, the older it is, the better it gets because you get that composite of all
these philosophies, workflows, workflows and forming packages and if you're going to be
on the cutting edge, 95% of the ideas will probably not be good, 5% of the ideas will
be good, but versus looking at the older stuff where a lot more of the ideas will be good
and you'll get all like matured packages.
Like you were talking about how you have all the window control with the Mac stuff.
You just get the stuff, uh, Streamlint.
And maybe like, you know, if we look at Richard Stallman's Emacs environment and maybe yours,
John, you'd like to keep it simple, like you said, not beaming it because you've gotten,
you know, to a steady state that works well for you.
I visited Xerox park years ago and when I went around looking at all of the workstations,
they were all using like 10 year old window managers, just like the oldest look and feel.
Nobody was touching anything, right?
Because they were creating the future, they thought, and they really didn't care about
keeping up to date on, on their packages.
They had to write their own stuff.
So I thought that was kind of fascinating to learn that a lot of, you know, high level
thinkers don't necessarily treat their tooling environments the same way.
At least not, not every day.
They probably say finish whatever they're doing or, you know, reach five years or something.
That's what I'm sticking with this one Subaru car and I've had a bunch of other things,
but this one has an engine that they don't make anymore, a V6.
Now they're sort of like turboizing things to get the equivalent power and it doesn't
perform the same way.
So I'm like, well, I got to wait until the bottom of this car rusts out before I replace
it because I like so much about it.
Even though I'm missing some of the new technology, I just don't want to change it out.
One of the things I like a lot about how Emacs looks as it looks to me, really nice in a
real bullshit, ultra functional way where it's like, I like that it doesn't do the smooth
scrolling that it scrolls line by line by line, even though that's not as modern and
hip because it's more down or down to earth functional, I don't know, like a more engineering
or something that's just not as flashy normal way.
Yeah, no, I agree.
And it affects, it really affects how it feels like you're somewhere in your brain, you're
some kind of object that your brain thinks that you're dealing with, even if it's not
really an object, you know, part of your brain just has to really to the world that way.
And I think that's just one of those things is that if you can, your brain can actually
feel like you're, you can almost feel each line like passing past, you're going past
your scrolling action.
Your brain is like, you keep helps keep you oriented, like you can, it's like, it's your
visual experience creates a tactile experience for you.
I think that's one of the the VR problems that the industry is suffering from is that
it's so easy to program things that will entirely screw up somebody's, what do you call this
subconscious parts of our, our nerve nervous systems.
So right, I mean, they can scare the hell out of people, they can make them sense something
that's not there.
And it's like, you know, it's just, we're not ready for that in so many ways, and it's
just too easy.
And so if you can't depend that like physics will keep you from like flying off the earth,
you know, anything can happen.
I don't know how many people will want to really, you know, experience that for any
continual amount of time.
The other thing you don't get is like, you don't have to worry about how much time it
does a scroll.
So it's going to be a lot more performant, faster.
I love turn, as a counter example, I love turning off the animations on my phone because
it makes it snappier, faster, and I don't want to just insert animations on my phone
just to slow it down and you open up your contacts, it's like, I want to make, I turn
the DPI on my Android phone down, down, so that I can see more contacts at once.
So I don't have to scroll as many times and I want, I make the home screen have more icons
on it because I'm accurate with my thumbs.
So I want to see as many icons as I can so I don't, so I can much faster see and click
the right one I want to, I scroll less pages.
Yeah, and you probably have a hard time making it do what you want, I'm guessing too, because
it's just the one area where, for phones especially, it's just one area where you are not respected.
You're going to take whatever experience they figured was the right one that week and force
you to eat it, like a head of cattle.
You're eating that experience like it's feed and it'll change whenever you want, whenever
they want, and it's going to, I don't know if you feel the same way.
My first phone was a Windows mobile phone that the person was selling because they wanted
an Android phone and I've always been on custom ROMs, although lately I've been getting annoyed
about it because they've been losing all the, let's see, I remember reading this blog post
about somebody liking custom ROMs and they were saying that Android was becoming more
restrictive because they would be putting an image through the USB port so you could
have a Linux ISO connected to your computer through your phone and they wanted SE Linux
but they'd have to compile the kernel in a different way and have the patch and all that
type of stuff is just becoming more and more of a nightmare and you're not able to do that.
Right now I'm messing with a Linux phone.
Do you guys agree with Stallman and GNU thinking for FFF philosophy in general or sort of like
you're more middle of the road about it?
I mean I personally, I think there's a need for that philosophy.
I don't, at least now, I don't personally 100% dedicate my beliefs and actions to it.
I'm not certain about anything to be honest but I'm not ready to say that everything outside
of it has no place for me or has no place at all but I think about the commonalities.
I think that there's good that will come, there's a truth to it and there's a good that
it will do and there's certainly no reason to not offer.
You don't have to agree that it's the only way to agree that there's something good about
it.
That's my point of view.
I think that you have the philosophy, like the Emacs is a great example of an ecosystem
informed by that philosophy and it's an artifact of that philosophy because you look at an
Emacs package, chances are if you look at any of the Zettelkasten systems, they're not
going to be trying to, it's not going to be, let's see, you have org.roam.
It's not Roam because Roam requires you to pay for a Sass subscription and it's only
accessible online and it's like any Emacs package you use, generally you're going to
have all the data on your local machine and it's...
Is that, I think there was something called Roam, is that Roam research, is that what
you're talking about?
Yes.
That's right.
I thought Roam was just a verb.
Sorry.
They built the interface to be like that, yeah.
It's interesting, right?
Because yeah, you hear all these terms and you don't always know.
Like a lot of people are like, hyperbole has adopted this org thing because they don't
know it existed before org because the org obviously has a much broader reach right now.
So yeah, understanding that history and that Emacs is tied into the FSF philosophy, there's
probably a fraction of the Emacs users that even are very aware of that.
But I think, yeah, Stallman, he's seen a lot and he's somebody who does think a lot from
first principles and is very logical.
He doesn't necessarily want to deal with parts of the world that exist.
But if he makes a statement, it's usually fairly true.
So the fact that he's concluded this and been very definitive about it for decades tells
you that there's some truth in there that you should look into.
Yeah.
I think if I think of like today's earlier session where some of the questions were exposed
some tension there and I think one of the reasons why we see that tension is because
of the success and the kind of the more broad appeal of that org mode has brought Emacs
and it's a healthy sign.
It's a sign that there's people coming into the community who may not be familiar with
the origins, the philosophical origins of the tools that they're using.
I also think that you have a lot of the people who are interested in Emacs are probably interested
in the Free Software Foundation.
So it's something like the philosophy.
I mean, maybe, but right, they could just be interested in what, which is what Stallman
talks about too a lot.
It's like you may just want the functionality that some software has and you may not care
about free licensing, but you should.
And here's why, you know, so yeah, but you start using all the, you start using all the
packages and then the philosophy, then it kicks you into the philosophy from the reverse
direction.
And so I think as if you, if you start resonating with that philosophy, Emacs is the place to
be.
So we'll all be slanted towards wanting the GPL license or at least the BSD license because
it's the place that it's the place in philosophy that exploits all those advantages practically.
It's interesting because maybe, I don't know how many years ago, 10, 15 years ago, there
was that big debate about open source and versus free software.
And you know, it was just raging and it doesn't even seem like it's a topic anymore.
It's like the GPL has done very well.
Other licenses have too, but the model of software being free and open is established
at all levels in the economy and in the technical world.
So you know, Stallman is sort of playing the long game and what did they say, like the
justice system bends towards right, but it's over a really long period of time or something.
Eventually it gets to the right answer.
I think it's sort of like that, you know, it's that we're going to have all these ups
and downs, but eventually you'll have dictators and such, but eventually freedom will win.
People win out over, you know, being crushed under the boot like the Russians are today.
You know, what comes out of their society after they get crushed by the Ukrainians,
I think will be hopefully for them, you know, because they had such great intellectual capacity,
but they've had this broken culture for over a hundred years.
And so if you don't, going back to Engelbart again, if you just evolve your technology
without your process, your culture, you're left with something that may not work well
at all for you.
You have to take stock every now and then you need that time.
And that's another point that I wanted to make in my talk, but I just couldn't find
room for it is that if you know that you're going to make that time in the future, then
you can focus on the present.
But if you never make that time, and I don't mean, you know, it could apply to anything,
but whether it's societal or technical, but don't stop and really think about what you
are, you know, am I doing what I represent or are my actions representing myself and
my needs and my goals?
Every person, every organization of people, every society should really think about that.
And it seems like it just, there's certain ways that society can grow where it becomes,
you can't think about that because when you start to think about that is when you become
vulnerable or you, I don't know, I'm not a philosopher, I'm not an international scholar.
Does ZMAX rank up there on your hierarchy of needs, it's like number two or take that
away from me and my survival will be jeopardized.
And as much as my digital self is, absolutely, it's probably very close to, I mean, it really
did, I think, save me from destruction in terms of organization personally.
I think it was, what was it, it must have been 2008 or so, I was just so disorganized
and I was, you know, missing bills and things like that, just because I had a pile of papers
and I said, you know what, I need to be able to take notes, and I was taking notes, but
I had just a bunch of flat text files and I said, I need to be able to collapse my text
and I want to be able to take outline notes and I ended up, sorry, go ahead, I just ended
up finding, I think it was work mode at the time, I think it was still a separate package
and I was like, okay, finally, just this ability to collapse my notes into hierarchical structure
so that I could have one thing, that I could think about multiple, one file, think about
multiple things and collapse them when I didn't need to think about them anymore, and I was
just like, okay, finally, this is the thing that's going to help me stay organized and
from there on out, it worked, so in terms of whatever I am today, you know, I couldn't
undo that anymore, like that's committed to my identity at this point, so yeah, yeah.
That's a great explanation of it, you know.
Have you looked at the ARG narrowing at all, or Emacs narrowing stuff?
Yeah, I do that a lot, it helps me, it helped me focus on writing some of my notes for the
talk.
Yeah, that's very important because you can end up capturing so much, it makes it so easy
to capture and then you one day said, okay, I captured too much, I need to, you know,
that outline, having all those stars and whatever in your outline can be very distracting and
I use very old stuff, so I still have, you know, just regular, a series of asterisks
aligned to my left side, so I have a lot of visual noise in there, but yeah, yeah, I mean,
do you have any special ways that you use it, like in terms of the narrowing or anything?
I like using the VertiCo package because it allows you to set up different commands to
either like be in a buffer or mini buffer or various things like that, so I can choose
how to do that or change that over time.
For me with Emacs, I think that is the most useful about it is I generally like trying
out new things and Emacs is a program that got onto my computer, never left because anytime
I want to try something new, I can just try out the packages or parts of the configs or
variables and I get to try that stuff out, some stuff has stayed, a lot of stuff doesn't
necessarily stay, draw up my files and...
The first time when I'm bringing up a new system is I always like get some micro Emacs
version just so I can edit my config files and then I get the OS stable enough and then
I install a new Emacs and it's like I never used VI, I never learned VI, I was lucky,
I guess, you know, they taught us first year of college we used Emacs, so all these people
I bet they've gone through 7 to 10 editors and I'm like, well, I've gone through versions
of Emacs and that's it.
So it's been a little different and it is, it's crept into my subconscious, you know,
so much so that the talk about getting Emacs, using Emacs to fill in your web form fields
was very interesting to me because years ago I did that, when Sun was popular there was
also Apollo which had a better networking and a better OS and so we were using some
of their workstations and they had every shell and every window had an editing capability,
was essentially an editor field but it was their own editor so I modified it so it was
Emacs and you know everywhere on Apollo and it was a really beautiful environment and
like then HP bought them and killed the OS in favor of HP UX so that went away and I
couldn't use it anymore but we had built a really cool environment on there but that
again, I wouldn't hand over the workstations, I was setting them up for a research team
and I wouldn't hand them over until I had built this environment so that they all had
the consistent editing experience and they wouldn't go off and just do something random
with it.
It's funny how you describe that bootstrap process because the way that I think about
it is that a lot of times you end up, what's the path they talk about is that you need
to learn enough bash to install Python or something like that and that's the joke is
that that's the only amount of bash that you need to know but if you go to the Emacs path,
you might not even need Python.
You mentioned having it installed to edit configs and things like that and edit what
you need to do to get another version of Emacs installed but I could see, I would love, maybe
that'll be my inspiration for next year's talk is to find a way to, yeah, everything,
just use Emacs as a substitute for Python and Ansible.
I could probably use some of the packages that were out there like, what was it, Anthony
or Tropin, Andrew Tropin, he had the RD, the reproducible Emacs, I could look at that and
use that.
It tells me about living through, we're always manipulating JSON now and I'm like, why does
JavaScript have such a crappy format, it could just be S expressions and then we get rid
of all this noise that we have to keep dealing with and it represents the same things but
instead we settled on this crappier thing that's a little closer to the way we would
have done it in C probably and because it is JavaScript's object format and it's like
it's annoying to know and of course you could write a processor so it converts bi-directionally
but nobody will do it.
If you've ever used Lisp to replace your HTML, same sort of thing, you don't have to deal
with your closing tags and you get all the auto editing and it's just like even without
abstracting above any of the tags, just replacing them one for one, it's so much better but
can you get anybody to do it?
You look at Gix and you have the init system, that's written in Guile or scheme and then
you got the cron program, it's mcron, that's written in Guile and you can use the normal
cron syntax for that or a different one where you can do that and you can start labeling
it with like say how many hours I want to do.
I think the example they give in their documentation is like I want it to do the first Wednesday
of every month or you could put if statements in there or a whole bunch of interesting things
like that and it's like their package definitions are in Guile so it's like the whole operating
system is in Guile.
That's what we're trying to do, right?
That was going to be the scripting language for Canoe, was going to be Guile and they
were doing that which again, this is all like from MIT, right?
Stallman's from the MIT AI lab, all this stuff, scheme, it's all evolved from that environment
and they were right, this stuff is pretty good but it's like it's interesting to listen
to him say if we were to update Emacs and allow another language to be the programming
language, it would be scheme.
It's not even on the radar of anybody in the industry to do that but he doesn't care.
He's like he's the Mekana class, he sees the value, he sees what's technically good.
Have you ever read any of his compiler code or something, I mean read his Emacs code,
it's so clean, it's so beautiful, it's not like super abstract but it's like even the
C code to implement the list of primitives, I mean now you don't know what he wrote versus
somebody else and you can see in Emacs that it's gone away from the sort of stuff you
used to write but his mind is just like so clear when doing things like that, that like
you can learn an infinite number of things from kind of looking at the way he structures
stuff.
I'm going to have to, I'm making a note for myself to go seek that out specifically because
I don't think I've ever, I've seen some of the code that he's written, I've just never
seen it in that context of specifically going in to try to get a sense of what it is.
I mean when you read, like read the Emacs manual, right, I mean at least through version
19 he wrote that, right, and it's like step by step he takes you from what a point is
to marks to windows and it's just, it's very thoughtful and you're like well he's been
embedded in this for years and like this is second nature to him, he doesn't even think
about it but when he talks about it, it all comes out from first principle and I think
that's what made him a master programmer and some of the stuff that they tried to do, build
an operating system from scratch even though they didn't have all the success they wanted
but you look at how good they made the Unix tools compared to what they were in Berkeley
and elsewhere and you know it's fabulous programming as well, I think very impressive.
Cool, I know that he got, at least I saw some people praising that C manual that he recently
published, I think it was in the last, somewhere in the last year, probably more like six months
he released some kind of C documentation so I would wonder if he would ever consider doing
something for Elisp or for Emacs or anything like that.
Yeah he did talk about, that was one of the things he wanted, to update the Emacs list
but I mean I think the intro of it if I remember, right, Chiselle's book right, I wanted to
read it, I think the manual is pretty good but yeah, I mean there's so much to keep up
with, I mean Ellie is so productive and I mean the rate at which they're adding stuff
to Emacs is pretty, and that I mean if you ever look at the developer list it's a massive
number, it's the same with the org, I don't know how people get anything done, they have
so many, and Ehor processes like every message on there, this must be his job to some extent
because it just, it would be so much time and like the hyperbole list, there's nothing,
I mean it's no problem at all, it doesn't take any time but they have so many topics
that people are talking about, it's very impressive.
I don't understand how they get by without a better tracking system, I mean DevBugs is
certainly good but it's not as, trying to find the right words here, I don't think I'm
not trying to insult it but it's like a backlog, like a more kind of elaborate tracking system
that kind of like separates, all right let's put this in our backlog, let's prioritize
it, let's analyze it, but no, it just comes in and gets immediately handled and gets resolved,
whether it's a no or a yes, things tend to be addressed and finished very quickly.
So you're saying it's topics that concern me, I should bring up with them and they'll
actually get dealt with pretty quickly?
Whether to your satisfaction or not, I think so, my sense is in general that things don't
come in and then get planned, they come in and they get done or they don't get done ever.
My issues with the org, I think they've done a lot of great stuff from a user perspective,
my issues have been with the way it was written, was very sloppy code for a long time, now
they've spent a lot of time rewriting stuff so I think it's a lot better but I was looking
at something the other day and it was clear that this should be at least a separate function
or abstracted out and it was all hard coded in the function, so I think they sort of do
that on a piecemeal basis because they've got a lot of legacy code from the way it started
and they knew that it wasn't written the way they wanted, like having to write a totally
new parser is a good example and yeah, we all go through that refactoring and stuff
but I think it's because it was a quick and dirty solution for Karsten to solve, the same
way the web was, right, I mean they just wanted a publishing platform for physicists, so now
the guy who wrote that is a true genius, what's his name, the web inventor, so he took a broader
approach to it but basically they had to get something up fast and running and that just
sort of proved the concept and then you had to have the whole engineering team at Mosaic
come in and actually do a lot more with it but they lost, the original web had full editing
capabilities like in wikis and they lost that almost immediately when they went to the graphical
web and so we've been hurting, you know, like every time I used to go when I was, early
days of the web, I'd look and I'd look at this form and I'd say okay, so this is like
you enter this data and then it runs this program and it does this thing, so how do
I see what the program does, how does it process the form, it was never connected, the code
was never connected to the form of like why would you want this set of inputs that is
totally disconnected from the way it's processed, right, it was hidden in the back end, right,
which you had no access to, it's like I guess good for proprietary vendors but it's like
so for engineers to understand the system, it was very, very difficult, what if I have
a hundred forms, so I see, yeah, that there's like one function that's referred to in the
form but I don't know anything about that, I can't even see it's calling invocation
a lot of times, right, so it's like that's just broken architecture and nobody cared,
they just like let it go on and now you have all these, what, I mean was there an alternative
to that, did it start somewhere else and then, well you encapsulate it as like the processing
is part of the form abstraction, that it's an active entity and they can be separated
if they live, right, like you have the front end and the back end piece of the form behavior
but maybe you want that abstraction to be able to migrate front end to back end across
time and so you need to have these two parts and we see this in building things now, right,
what are we using, we're using TypeScript on the front end and we're using C sharp on
the back end, so I imagine there's some impedance mismatches going on around there but we actually
introduced a Python validation framework, I don't want to get into this too much but
we are using those technologies and we can share those now across the front end and back
end and so, you know, a lot of languages that you need to understand and I just think, so
like closures, right, you're familiar with closures, right, so I mean that's what you're
doing is you're passing around the environment so that you can interpret the data properly
because you have the closure which wraps around it and so many things get, when you want to
deal with unwinding state, you know, through many levels, having the closures allows you
to do that easily, sort of the lexical binding versus the dynamic binding and so, you know,
the callback hell that they talk about in Node.js is reflective of not having a good
closure-based environment, when you look at most of the list-based web environments are
closure-based and they can do much more interesting application building without dealing with
a lot of the plumbing than if they didn't have that.
Interesting and when you refer to closures, are you saying that there's a certain paradigm
of form processing on the web that's more like a closure-based solution?
That's right, yeah, look at the common Lisp, like Hutchin2 and frameworks built on top
of that and you'll see.
I definitely will do that but I meant more like when you're talking about the early days
and how they separated the form from the actions, are you saying that that's a situation where
like something that would be like a closure is more or are you just strictly talking about
that?
That would help solve that problem, I would say, because it gives you, you know, sort
of you're seeing some of it in React now, they're like, oh, we've discovered components
and so, you know, we only have to do partial updates now because we can like walk our tree
and know that only this subcomponent, you know, and it's like, yeah, by building all
these abstractions, you simplify your state management a lot and you simplify that and
you localize where any of your issues can be.
And so, if I have my processing engine totally disconnected from my input state, you know,
it's going to cause a lot of problems and you saw it in the early days of the web where
everything was, what was it, CGI, is that what it was, right?
You just sort of, you had a totally separate back end and there was just this very thin
kind of connection to the front end and everybody's rediscovered, they rediscovered sockets, okay,
we need sockets and then everybody's fighting, well, I have to replicate the data on the
front end and the back end, you know, just handling tables is such a bear on the web
for similar reasons, right?
So you had, what was that company Apollo or that was one of their frameworks who was trying
to do real time front end, back end framework so that you can do all these pushes to a million
clients, right, of any change and you could get like real time updates.
You know, that seems fundamental to me if you're going to have a Facebook like kind
of environment and you look at how much money Facebook had to spend to just build their
basic application that scales at the level that they needed it.
I mean, it's just nymph.
You're talking about hot reloading, right, of data?
Yeah, yeah, but I'm talking about like how it flows and where it's maintained and, you
know, is there a single source of truth, right?
That's what we really want.
So people try to push stuff to the back end, but then you get all of this problem of the
front ends out of date.
So what's your method?
You keep web sockets open, you know, it's like, well, then I have too many of those.
So yeah, and what's your programming model for pushing all that data around anyway, right?
Pushing, pulling, it's complex stuff, but if you solve it, there's a guy who wrote a
web server, like tiny, tiny WB or something.
I could look it up, but it's like, and he shows benchmarks of what he can process from
this one like C-based program.
And it's like five times the speed of other things just based on the algorithms that he
implemented and so, you know, so you get your scale right like that and then you keep adding
on some abstraction layers because now you can afford it.
And then you simplify your programming model and like, we could be building the kinds of
web applications that we want, you know, with menus even without, have you ever figured
out how to do a good menu on a web app, you know?
It's so much energy, right, when like in Emacs it would be just, here's my menu item and
I'm done.
So I think the baseline of what your programming model is matters so much from the syntax down
to like the lexical scoping and, you know, and we're just lucky that Lisp got a lot of
things right, that we have that as sort of like the thinking man's programming environment
while all these other people were stuffed into Java, you know, in the 80s and they built
Java beans and if you've ever looked at J2EE, I mean, that was such a monstrosity that it
just collapsed literally of its own weight sort of.
I mean, people are still using Java but it's like nobody wants to field a new web app,
you know, in J2EE, it's just not done.
So unless you have, you know, a ton of legacy investment that you have to keep up.
So I think these design choices matter a lot and I think Apple's renaissance has been based
on, you know, really saying, well, we'll iterate through our designs before we subject the
users to them.
We're not going to just make everybody one big beta test like Facebook or Microsoft and,
you know, you see that like people have, you know, certainly in the consumer space have,
you know, the shops are always full, I mean, wherever Apple store you go to and, you know,
Microsoft is trying, Sony tries to have stores and stuff but you don't, they're not filled
with this traffic, you know, because people aren't attached to the design aesthetic the
same way.
True, yeah.
Yeah, they got something, they certainly have something that people want.
Every program grows until it's a half a common list implementation or it's got a mail server
in it, like you got those two sayings, oh, have you seen this at all?
It's kind of lets you make desktop like apps with Common Lisp.
I like the name though, Omnificent GUI Builder, you're giving us a lot of great links today,
it's making me happy.
It's for a YouTube video but they also have a GitHub page somewhere.
I wish I did more Common Lisp but this is, and this is pretty new too, this is about
a half a year old only.
Well, does it look decent?
Is it real or is it like?
Well, it seems kind of like React.js where you're not writing, where you're, it's not
the pure HTML post Git model where it's more like an application and like if you look at
the screen, like you have the applications, you can move them around like it is in this
up.
It certainly looks functional, that would be my way to say it.
And then you just write it in all one language.
Just like Smalltalk, like what their environment used to look like.
Oh yeah, and that, the glorious toolkits is the thing I was...
Well there was a time when we had single UI builder environments and then you would just
say what theme you wanted, Windows, Mac OS, and instantly it would look like the other
environment and you had to do no work to get that.
It's like, wow, that would be nice these days.
Another thing with that philosophy of the copying the programs, you had Keanu Reeves
talking about NFTs and it's like, what do you think about these NFTs with the matrix?
You mean we're gonna have a computer, let's see, you mean we're gonna spend all this,
you mean we're gonna have, you want me to be on board with charging people for these
digital things on a computer that's designed to make copies?
The whole person just like completely stopped because they're trying to, yeah, showed you
how the idea was fundamentally wrong.
Yeah, get your baseline, right?
I mean, I've had to, I'm very pro-Ukraine and so I've learned a lot more about Russian
history.
I also have a number of Russian workmates who are very nice people, but they left Russia
as well and a lot of what's going on seems to be from decisions that were made eons ago
in the back to the Mongols and the way they ran their systems.
So it's like when everybody says we've got to run so fast and we don't have time to really
think through the design, they can't see the impact that that's gonna have on their enterprise
or anything else.
And if you're a long-term person, you obviously have to do things fast enough so the company
can survive, but you have to think about that strategic level as well.
Those who don't know history are doomed to repeat it.
Yeah, exactly.
Sometimes very badly.
So how do we get Lisp to be something again?
People are worried about Emacs dying out.
I don't think that's happening so much, but certainly Lisp missed its position in web
development, it seems, even though it can be quite capable there, but because of its
image model and lack of focus on threading, it seems like you can't get anybody to even
look at it now, right?
I mean, unless you're talking about Clojure, like you talked about.
You're talking about how Scheme would have been a lot better for JavaScript when JavaScript
was first released, or like Emacs, because Emacs is good for a platform for distributing
apps versus HTML as a document reader that they shoved applications into.
I like the way you describe things.
Yeah, I can't argue with that.
But it is interesting to me.
A lot of people don't know certain systems that are Lisp based that have been super successful,
like Orbitz was based on the technology of a Cambridge company that implemented the bulk
of their flight scheduling software in Lisp, and they had a very active kind of Lisp community.
So you know, it's still-
Hacker News is another one.
Hacker News, yeah, that's built in Lisp?
Yeah, the person who founded it was using Lisp and Paul Graham.
Sam Altman?
Paul Graham?
Paul Graham.
He founded it.
Oh, I didn't know he was-
Or at least he was involved in it anyway.
Yeah, yeah, yeah.
It was either that or Reddit.
It was one or the other.
He had an interesting Yahoo shopping experience where he wrote about that, how he leveraged
Lisp to his advantage.
So yeah, I think Python was that way until it got discovered.
I worked with those guys back in Silicon Valley for a little while, and when we were trying
to show the world that Python was something good, but it hadn't been noticed yet.
So there's a lot of leverage that you can get if you're careful about it.
One thing that I thought was interesting is you look at the- Google did some survey of
the most efficient programming languages to run, and I think C was number one, and you
look at the list, and the only one that even looks remotely high level is Common Lisp,
where it's sent per the TDP or whatever that would be called, sent per execution or whatever.
Everything else is more like C.
Have you heard of Pico Lisp?
A little bit.
On RosettaCode, where they write the different implementations of algorithms in different
languages, look at any sort of algorithm and the Pico Lisp implementation next to all the
others, and it's always super tiny, and you've got just a ton more code and everything else.
And then Pico Lisp is like Lisp with a database, maybe a triplet database built in, and it's
pretty small and efficient.
But I don't think anybody uses it.
But it's an interesting example of a special case Lisp that you could embed in other things
or use.
One guy in Germany has been doing it for many years.
Is that like an internet rule or a computing rule that we could come up with?
No matter what you could think of, no matter what you find, there's one guy in Germany
who's already done it.
Well, I knew some Dutch people.
I was in embedded systems at Motorola.
We were working with very small microcontrollers with no memory.
So we needed these super efficient cross compilers to build anything for us.
And this company in Amsterdam seemed to have some skills.
And so we started talking to them, and then we flew over there to do due diligence and
check them out.
And God, if they did not have one of the most advanced software development operations I'd
ever seen, total quality assurance, great people.
But everything was like to the T. This is how we do it, boom, boom, boom.
So that's the only way you could get the efficiency out of compilers at the time.
And so we worked with them.
But they had that German kind of culture of the fit and finish has to be just so.
So we used to have to do things like there was 256 bytes of memory.
There's no K in there, of RAM.
And so you would like to use overlays where you're repeating what you store in each word
at different times in the program, and you had to manually keep track of the lifetime
of objects.
And it was a nightmare.
But it was the only way to kind of squeeze some of the stuff in there.
And we started in assembler, and then we went to C. And then we had this one time that was
really fun that we had, God, I'm really dating myself now, but some of the people in product
had these terminals, like 12 inch terminals with eight inch floppy disks on the terminal.
And they were using those to interface to the microcontroller boards for emulator boards,
where we would test out new software for a board that hadn't been released to production
yet.
And we would be able to iterate on that.
And right next to these things were sun workstations that the engineers used for their normal development.
So I was moved from research to product.
And they said, so this is how you're going to have to do your code on this monochrome
terminal.
And I'm like, well, what about using the sun workstation?
And it's just a serial port, so we'll just interface it.
No, we tried that two years ago.
It didn't work.
We can't do it.
I'm like, I am not going to sit here and use this dumpy thing for a week.
So that afternoon, I figured out the protocol and got the thing, the sun workstation, talking
to it.
And then I wrote a disassembler tool so I could work the assembly, the math, behind
it at a higher level.
And I had all that going the first week.
But people came over, and they're like, what are you doing?
How is this possible?
They just had started from the vantage point that they really had to live here, and they
hadn't done enough of an assessment.
So I would just look back at that when people say, this is the only way to do something.
That's one of the great things about computers is it can speak too many languages.
So if you want to just speak Lisp, you can just speak Lisp, relatively, anyway.
Or if everybody else wants to speak that worst language that you don't like as much, you
don't necessarily have to speak that, I guess, except for the www, but anyway.
Omnificent web development language, and tell everybody that this is the be all and all.
I think what I like the most about that is that I don't believe that omnificent is actually
a word, so that can be accused of being incorrect, because there is no definition of omnificent
that they can be shown not to conform to.
I could be talking about that, but that's...
There's a Latin word.
That's why you know what it means, is because omni is everything, efficient is something
about knowing, or everywhere, like the all-knowing GUI builder.
Isn't that kind of how you read the omni-efficient?
I think that's actually omniscient.
I think...
Omniscient, yeah.
Oh, omniscient.
Yeah, that's right.
You're close.
I think, yeah.
C-L-O-G, so it's the clog builder.
That sounds like a Lisp-y kind of thing, you know?
It doesn't have any sexiness to it, but we've invented the clog builder.
You know, that's funny.
That was another thing I wanted to mention when I was writing this.
It's just to clog how everybody else does things.
Just clog it up.
No, you don't have to do it that way.
Is that something that is real?
I feel like a lot of Emacs users are maybe just that type of person in general.
We want things that look, not look, but sound, like clog.
We prefer things that are awkward and are stupid acronyms, and if it seems like effort
has been put into something to make it sound sick or market or anything, it's like, I don't
know.
I'm not sure.
I think that goes back to what I was talking about with the scrolling down.
I want it to not have animations.
It's just spending CPU cycles to make my experience worse.
Why would I want to scroll down half a line so I can read half of a text?
Well, if you scroll half of a finger, that's what it would be, if you just do this.
Oh, is this the guy?
I think this is the guy, the one, the G toolkit, yeah, the glamorous toolkit.
I read about this a while ago.
This was one Google guy.
We had a team, and then I think he left Google, and he's trying to do it, implemented in Faro,
the pure object-oriented language.
Yeah, this sounds like one of those things.
Yeah, that's what it is.
You know, there's, yeah, it's like, just get the base right, right?
That's what Lisp did.
Just give me Kar and Kutter and Lambda Calculus and go for it.
What?
And I will move the world.
Yeah.
Well, when you think, you know, I mean, look at the opportunity that was lost with Lisp
machines.
I was around for those too.
I'm near dead, I guess.
But I was young, at least then, and they microcoded Lisp, right?
So everything atop that was Lisp.
The Windows system was Lisp, you know, sort of like what Jobs was trying to do.
He was trying to do, I don't know, well, when he did display PostScript, or he was trying
to get common experience at different levels.
But like, if you really have a consistent programming model across your whole damn system,
you know, it's probably thousands of man years of work that you just eliminate right there
if you have a decent language, right, and then a debugging environment.
I mean, we still use stuff that there is no debugging environment for, right?
Because it solves some problem that exists in the industry, and we haven't gotten rid
of it yet.
I want to set up some Raspberry Pi lights.
If you have like that with an embedded controller, if you run that with Lisp, you're probably
going to get a REPL for free that is going to allow you to remotely control your lights.
You know, they have MicroPython for that, if you're into Python at all.
That was a physicist, I don't know if he was German, but a physicist who implemented that
to do controller hardware, and it's pretty good.
He's moved a lot of, I think they actually got money behind it, and then started moving
all the libraries into that too.
So that runs pretty well.
And you got stuff like CPython too, but I think part of the thing that makes Python
appealing to people is you got all these libraries that people can use to build their apps with,
and if you're running MicroPython or CPython, do you have access to those?
Right.
Well, that's what I'm saying, they like have been moving on that to get a lot more of the
libraries available, because at first, that's right, that was part of what they were lacking.
But just, you know, being able to put your language at the hardware level without a separate
operating system is kind of an interesting concept too.
And at that time with the Lisp machines, they were making the CPUs in line with, you had
somebody making CPUs specifically for the Lisp machines, and ever since then, we've
always been making CPUs to specifically target C, and I wonder how much that kind of like
the philosophy and artifacts that you design, I wonder if like CPUs would look different
and stuff like that, because we'd be optimizing them for Lambda calculus or something, and
Reples, and if that would result in anything different.
Well, I always ask my friend in London who knows everything, or he knows something about
everything, why I remember the fastest computer I ever used was a DEC Alpha in the 80s, and
it was, or maybe the beginning of the 90s, so it was a 64-bit machine at the time, and
it used SCSI disks, and I would, you know, compilation took a while of programs, but
I would go to compile, and I would just see these messages fly by me, and it would be
like Go is today, right, be done in an instant, and like, how is that possible, I go over
to this other machine, and they were emulating, I thought it had 128-bit data paths, but we
looked it up, it was 64-bit, but they did have 128-bit words.
You're talking about like boot up speed, and like how fast when you press a letter G on
a keyboard, how fast it appears on your screen, and stuff like that, right?
No, compilation of a complex application, how long that would take, and how long I would
have to wait, and it was near instantaneous in many cases, and I had never experienced
that before.
So their disks were super fast, the throughput on the data buses was super fast, and I mean,
it just worked like if you wanted a fast computer, it felt right, and I've not, you know, despite
all the hardware I've had access to, I haven't had that same experience on any other machine
to do.
I know the Zig programming language has recently gotten an incremental compiler for it.
Nice.
So it would.
Yeah, they're doing good work, they're doing good.
Have you seen Vlang too?
That's sort of interesting.
I've seen that a little bit, but I haven't looked too much into it.
There's this one Russian guy, and he's building his own Go-like replacement for C, because
he likes Go a lot, but he wants to solve some other problems that he didn't like in Go,
and the things he says about it are incredible.
It doesn't, well, it didn't have garbage collection at first, right, because he wants to do all
those machine-level things, but they seem to be able to build things that they promote
as doing a lot, like an entire web framework they have already.
They have their own graphics system and, you know, should be able to do very fast compositing.
Who knows, you know, and so a lot of people say that he's over-promising, but he keeps
delivering these snippets about, well, V, originally he had to translate V to C to get it to compile.
Now it's self-hosting, and he can compile the whole language in 1.8 seconds from start,
right, things like that, and so he's bootstrapping these super-efficient things to get to a very
Rust-like systems programming language, but potentially cleaner.
But it doesn't have, you know, people behind it like Rust, and you don't know if what he's
saying is actually true, but if it is, you know, it might be like Zig and be something
really interesting.
Zig did cached compilations, so if you compiled something and then you changed a little bit
and you compile it again, you're not going to compile very much.
Right, so it'll be super-fast that way too.
Yeah, I mean, memoization, that's caching if you can do it right, I'll save your ass
every time, right, that's sort of.
Then they have a self-hosted compiler, so I think that's one that will do the incremental
compilations, so like that one will just be much faster and give you more debug stuff.
But it is interesting, it's like, yeah, start with the REPL, right?
Can you do a REPL in your language or not?
Can you give me an interactive environment, even if everything has to be compiled?
Like Julia, I guess, is going for some of this, right?
They're taking some from LIST, they're taking all these efficient scientific libraries,
and they're trying to meld them into a functional environment that gives you the most efficient
code for any line that you write, right?
Because it compiles it based on the dynamic types or something that it experiences, so
it's very interesting.
Have you seen the JANET Lisp language?
It's kind of like V, where it's a very small language that has a web framework for it as
well.
No, I haven't seen that.
I got a link on it right there.
Yeah, I see it here, JANET Lisp, not too hard to find.
I like their logo, 1950s JANET.
Functional and imperative programming language runs on Windows, Linux, Mac OS, and Steam.
Entire language is less than one megabyte.
This sounds like REBOL, called Sasslerath, it did a lot of FORTH, and then he wrote REBOL,
which has now evolved into REDLANG.
It doesn't seem like a great language, but it's got that FORTH efficiency, and it's super
small with its super small graphics, but it's not that easy to write, I think.
This is cool.
This sounds really interesting.
So who's doing this, JANET?
You know where it comes from?
What source?
They don't have about.
Tell us about JANET.
Oh, Calvin Rose and contributors.
So again, we have one guy and contributor.
That's well, you know, that's modern.
That's how it is.
You know, we talk about repeating the cycles of and how old problems are going to manifest
with new technologies, maybe that's the problem that we're doing is that now everyone will
have their own language and their own system and has become so satisfying and easy to do
that that every single person will write their own programming language, their own architecture,
and everyone will become it's like a it's like a monkey's paw or the genie granting
you a curse.
Everyone will become perfectly competent at this stuff, but not be able to communicate
with each other because everyone's has their personal language.
It's like the new Tower of Babel.
You know, that's the claim that like my my guy in London makes about Lisp, that it's
so efficient in making DSLs that nobody can communicate with each other.
And I've heard that said about groups working in Lisp together, but I've never seen it.
And it doesn't make a lot of sense to me because if you build your DSL for the domain, well,
then it's like if people have any concept of the domain, it's going to be quite understandable.
And because it's representative, you know, they're not going to struggle with it.
It's only if you like, you know, make up terms that don't relate to anything and use that
all over.
Or if you take the scientists and they use their single character variable names, that's
going to be a lot less understandable than something tailored for the domain that you're
working in.
Right?
Good point.
Yeah.
I wonder how much of it has to do with going back and forth.
You know, like if you can't spend all of your time or dedicate a long enough time, if you
just go in and look at whatever this DSL is, switch back to idiomatic stuff.
It's like, oh, you know, my brain is, you have to context switch all the time, maybe.
One of the RACQ talk that was like the best talk for free software, and one of the observations
they made was that most of everything was made by one person.
And even if you look at a lot of the projects that have more than two people, you have one
person and then a maintainer takes over.
So it's still really one person working on it.
It's like, that's going to be like 95% of everything out there, and everybody chooses
a language that's not for that purpose.
This was kind of the law of what they were.
So if you're going to be doing that, you want to, if you're going to be working on a project
over a long period of time, you want a language that has more features that you can master
over a long period of time rather than how fast you can write hello world that can keep
you interested in over a long period of, like Emacs for instance, Emacs can keep you interested
in it for decades.
And I think it's a cognitive mismatch.
Go ahead.
It's good to know that when given the freedom, like in software being such a new technology,
to do whatever you want that humans will still recreate the Tower of Babel every single time.
We'll never be able to agree on what's a good or right looking language.
But I think the reality is that there are better ones.
I think languages, written languages without accent marks are fundamentally better than
those with accent marks.
And so if you're stuck on one with there, you're probably going to get left behind even
though you can produce the same meanings.
And I think languages without Lisp type macros are never going to be able to solve the problems
even though they're computationally equivalent that Lisp people attack because they just
can't wrap the complexity in their mind enough.
You'd have to have somebody who's 100 times better with a weaker language to do what the
essentially average Lisp guy leveraging the macro capability could do.
Like in hyperbole, one of the things that we solve that you can't do, I think very well
in other languages.
So we have our implicit button definitions look like regular defunds, but they have two
parts in them.
One which is the pattern match, am I in the right context?
And then the one that calls the action.
But you need, so to make it look the same, like there's only one path that you're running
through this code, even though you have to do the pattern matching when you're called
one time and you have to do the action invocation when you called another.
There's a macro that we created called the hacked, H-A-C-T, and the macro actually takes
a, there's a function that it uses that's implicit, that is set to different values
at different states in the program.
So when you're just looking for the pattern matching, that's all it does.
And it sort of drops through the other behavior.
And then when it comes back around and you're not doing pattern matching anymore, it executes
the action.
But looking at the code, you only see that one defund straight kind of path through it.
So the engine handles all that, and I don't think you could write anything quite like
that without the macro.
It's magical, it's probably the closest thing to magic that we have, I guess.
Well, you guys have filled up my brain, so I'm going to get some sleep, too.
You deserve it.
I'm a day ahead of you in that respect, so I'm amazed you've made it this long, to be
honest.
I don't know if I, did I, was there any, like, is there anything that you guys had, that
I had neglected or anything that I should focus on?
Well, I don't know, but I'm going to sign off.
It's been a real pleasure talking to you guys, and John, I'll get in touch about, you know,
give you a chance to take a look at Hyperbole a little bit, and then we could talk about,
you know, how you could feedback some stuff, or if you want to interact with, meet some
of the other guys in the team sometime, and just talk.
Yeah, any of that, yeah, and you've got, I think, I mean, I'll email you if I, or you
email me, email me either way.
Okay, and on PlasmaStrike, if you're interested, it's open, too, I mean, we need smart people
like yourself with lots of ideas and understanding of where things come from to just help out
on that.
If you have any cycles and you want to get involved, let me know.
My email address is all over the Hyperbole code, so easy to find, just rsw.cadu.org will
work as well.
Yeah, if, yeah, and either of you guys feel free to, if you have any interesting ideas
or anything, reach out and email me, I'm on the, I'm on the chatroom, thanks so much,
I can't wait till they get this session, and they're like, wait, it's 180,000, it's the
easiest thing I've got out of control, I guess, but, you know, they'll want to keep this because
it's a great wide-ranging conversation, posterity.
I have a feeling they won't run all of it through voice recognition.
It definitely belongs with a 10-minute talk.
Well, I'll tell you this, and I, not to prolong things, but this is, this is very representative
of the amount of time that I, the proportional amount of effort and time that I spent preparing
for this 10-minute talk, because for, I'll tell you something that, first, is when you
realize that you have a 10-minute talk and you say, how am I going to get 10 minutes?
Then you start preparing, and you start, and somehow you wind up with 100 minutes, and
then it takes you 10 times as long to cut out, to choose which 90 minutes to cut out.
So this is appropriate, it's appropriate for me, this is like my bookend, that I can talk
for three hours about that, or at least starting with that time.
You should give a talk about that, sort of like how Michelangelo went from the piece
of marble to the David, and it's like, you know, I had this infinite amount of material
coalescing it to 10 minutes is a 100-hour effort, because it's really true.
I like it, because that's, that's a lot of what these tools do, is they allow you to
capture your stuff.
They allow you to organize it, and they allow you to formalize it, and that organizing part
is what, is what gave me, well, isn't, isn't that what they say, that a professional programmer
is somebody who will spend an hour automate, spend 100 hours automating something that
only takes an hour, one time.
I think that's what, I think maybe some professional programmers may say that.
I don't know if their bosses would agree.
There's some truth to it though, right?
So have a great night guys, appreciate it.
And yeah, and PlasmaStrike, I don't know if you, if you do end up posting anything of
your, of your setup or anything, if you feel like it, just hit me up if you're interested
in any of my shit, looking at it, because if you do, I'd, I'd be interested.
That's all.
No pressure.
Yep.
All right.
Take it easy.
Great, great meeting you.
Great talking to you.
Yep.
You too.
See ya.
You're currently the only person in...
you