K Lars Lohn

Hello, and welcome to podcast.init,

the podcast about Python and the people who make it great. I'd like to thank everyone who has donated to the show. Your contributions help us make the show sustainable.

Linode is sponsoring us this week, and you can check them out at linode.com/podcastinnit

and get a $20 credit to try out their fast and reliable Linux virtual servers for your next Python project.

We're also sponsored by Rollbar, which is a service for tracking and aggregating your application errors so that you can find and fix the bugs in your project before your users notice they exist.

Use the link rollbar.com/podcastinit

to get 90 days and 300, 000 errors tracked for free on the Bootstrap plan. You can also visit our site at pythonpodcast.com

to sign up for our newsletter, read the show notes, and get in touch. And to help other people find the show, you can leave a review on Itunes or Google Play Music and tell your friends and coworkers.

We also have a discourse forum where you can find out about upcoming guests, suggest questions, propose show ideas, and follow-up with past guests. And your host as usual is Tobias Macy. And today, I'm interviewing K Lars Lawn about his career, his art, and his work with Mozilla.

So, Lars, could you please introduce yourself?

Well, hi. I'm Lars. I work for the Mozilla Corporation,

and I'm speaking to you today

from a yurt on an organic farm in the central or Willamette Valley of Oregon.

And can you tell us a bit how you got introduced to Python?

Well, there's a story behind that, just like there's a story behind everything I do. But I actually must thank Microsoft

for leading me to open source software and Python.

Back in 1999,

there was a dotcom crash.

And ironically, I weathered the dotcom crash by opening a dotcom.

I, started,

with a nursery,

selling rose bushes online.

And I hadn't done any research ahead of time and it was turned out that we were the only nursery online in 1999

that had a buy now button. We sold everything we had in the first 4 hours that we were open,

but

the business was actually really quite successful.

And fast forward to 2, 002,

and I got a letter

from

people called the Business Software Alliance or Association or something like that. And it was a threatening letter telling me that I had,

pirated software in my business

and that they were preparing to sue me. But there was an amnesty program, and if I paid this certain amount of money for all of these licenses for these Microsoft products, they would go away. I was stunned. There were 7 computers

in my business at that time. And the only software in them was the software that came from Dell

and the software that I wrote myself.

I, like I said, I was stunned. I didn't know what to do about this. And I know I couldn't find a single 1 of those certificates of authenticity

that came with the machines. So I had I guess no way of proving that I owned the software that was on my machines.

So after several sleepless nights and pouring over my budget,

I realized that I was gonna have to lay off an employee

in order to afford

to pay the amount that I was gonna have to pay. I finally decided which person I was going to lay off and then came up with a plan on how I was gonna get through an entire shipping season

short and employee. And I pulled out that letter and suddenly was shocked by something I hadn't noticed at the beginning. My business name was called The Uncommon Rose,

and the salutation

on the letter was dear miss Rose Uncommon.

What had happened apparently

is this business software group had purchased

marketing mailing list, and they just spammed everybody with the same message. I realized they knew nothing about my business at all. They didn't know anything.

I even had computers.

So I realized it was just some sort of protection racket.

I took the letter, copied it, sent it to the attorney general's office explaining what was going on,

and, then decided to ignore it and decided that Microsoft has no business having their hand in my revenue stream whatsoever. The software had been written entirely using Microsoft C plus plus, the Rogue Wave C plus plus libraries,

Microsoft SQL Server, and various other

Microsoft technologies, I decided to eliminate all of it. All the Microsoft keyboards and Microsoft

mice went to,

electronics recycling. I started doing some research. I discovered this language called Python,

which looked like a very good language to rapidly rewrite the entire software for the business.

I chose the Postgres database

and Linux and in 2 months, I entirely wrote the entire suite of software that ran the business

from

the greenhouse management

all the way through the website generation.

So like I say, I must thank Microsoft

for introducing me to Python and open source software.

It's funny how many times I've heard people say that they came to Python because they had to completely rewrite an existing project in a short matter of time, and then they were surprised by how quickly they were able to actually achieve that.

It was amazing. I I was really, really impressed with the Python language at that point. Having been a c plus plus programmer for

many years, and I started c plus plus way back in 87,

and the whole

cycle of writing and testing

was an order of magnitude faster. Yeah. Having the REPL for being able to do things interactively and in an exploratory manner has really been sort of foundational in how I've approached my programming career.

Yep. When I was going through your blog to prepare for this interview, I noticed that you have an interesting pair of articles on your website

trying to detail how you perceive code and why you think that code formatting should be able to be configured in a manner similar to CSS. So I'm wondering if you can explain a bit how your particular way that you perceive code affects the ways that you program.

Certainly. It is only

recently that I have really come to understand

how my brain is different

from most of the other programmers that I know.

I have a minor form what is called a synesthesia.

A synesthesia is when,

certain perceptions

are mixed up in the brain. People taste colors and things like that. Well, I see

complicated

twisted lines in colors

Even if they're not actually

done in colors.

To me, code

is the same sort of idea. I see it in colors

and that became first apparent to me when I was in graduate school. I was in an artificial intelligence class using the language lisp. The professor was giving

some sort of lecture on recursive pattern matching algorithms, and I probably was just doodling,

and not paying close attention. But I noticed all of a sudden a flash of blue

caught my eye, and he was writing on an overhead projector in black ink. And I stopped him and said, wait a minute, there's something wrong with your algorithm here. And then I said something vague about,

you lose context in the recursion at this point. He smiled at me and said well I've been using this example for 10 years and we know it works, etcetera, etcetera. And I backed down. I wasn't gonna tell him it's too blue.

So I backed down and he continued with his lecture. After a few minutes,

he suddenly stopped in mid sentence,

scrolled the overhead projector back to that algorithm,

looked at it for a moment, and then looked at me and grinned,

and said nobody has ever caught that problem. I didn't know it was there myself,

and ever since then I can say I can look at code

and if I see something blue,

I know there's a problem. I may not know what it is and it's not always completely reliable.

So

the way I code

is is kind of unique. I'm very and a very exploratory coder, and I believe very much in being very verbose

in writing code.

I believe that a variable name

shouldn't be a word. It should be an entire sentence describing what it is. A collection of

something.

Variable names such as looping variables.

I rarely ever use x or I.

I want to say what the object is, and I'm gonna use an article in front of it.

A blog post.

A integer, a rather an integer. Something like that. Because then the code to me

reads like English sentences.

If a blog post

is greater in length than etcetera.

So that's how code looks best to me. If it's written out in long form like that, I can go back to it and read it again. Unfortunately, it doesn't fit with many people's

or many organizations coding standards

and, you know, most of the people I know know never to actually talk to me about PEP 8,

Because for me PEP 8 is a disaster

and honestly,

it gives all code

a bluish cast.

It almost blinds me

to finding problems in code if I can't use this synesthesia that I have. The main problem and and it's certainly has been addressed in PEP 8 is line length. I have always felt that limiting line length to 79 characters

causes you to overload the meaning of white space. It no longer just shows structure, it also shows that you have,

lines that are too long, And with my variable names being long sentences,

almost every line is too long. And so I've had to modify how I I write code, and to me it becomes far less readable. Wouldn't it be great if we could find a way of looking at code and seeing it in the form of which we can read it the best? Now, the only thing I can think of that can do that sort of thing is the same way that HTML is styled in CSS.

I would love to see some way an editor of some sort to enable me to format my code in a way that I can read it

and then when someone else looks at it in their editor

it's formatted in the way they can read it most easily. I don't know the feasibility of this. I've sat down and tried to, think about how I would program this, played around with a few things, and really didn't get anywhere with it. It may never happen, at least in my lifetime,

but it's a great fantasy. Yeah. It's definitely an interesting problem to ponder because as you said, different people view code differently,

Particularly when Yeah. Particularly when you're saying, for instance, the long variable names, you know, as far as the CSS system, 1 potential approach would be to have

maybe a long and a short form of the variable so that you could have a toggle that will determine how those render so that people who want shorter line lengths can use the abbreviated form, and people who prefer the more expressive variable name can view it in the in its original context.

And then once you get to that point, then do you want to have, well, the variable in a different language

and etcetera like that, that, and then, it becomes impossible to write code at all. Right. And and and then you have to deal with I a t n n before you can even actually write your program.

Exactly.

Yeah. It's an interesting interesting problem to ponder at least if not solve.

Right.

I'm curious if the manner in which you perceive complicated expressions

has contributed to some of your fascination with complexity theory, which we'll touch on a little bit later, but also your,

your interest and

proficiency in drawing, what I must say, are quite beautiful mazes.

They're certainly quite closely related. Do you know of the language called APL?

I am familiar with it. I have actually recently listened to a podcast on,

for somebody who was very familiar with the language, it was on the Functional Geekery podcast. So I'll put a link to that in the show notes.

I love that language. When I lived on the Blackfeet Indian Reservation, I happened to be working for a man who was on the original design team for that language.

And we shared a love of it and its complexity and its ability to do an amazing number of things

in just very terse and brief,

statements

is very exciting to me. Of course, it doesn't fit well with my long variable name idea, but still I still appreciate it in that respect. So the code that I write, I often have a difficult time with the rest of the people on my team because I write code that is complex.

To me, many things that are complex are really quite clear. I love recursion.

I love multi threading. They are both make things so much simpler in my mind, but

complexity

is kind of a bad word in programming today, that there's always this move to move towards simplicity because it's easier code to maintain, but to me it makes code less interesting and I often

see code simplified to the point of being incorrect.

No longer properly modeling what it is you're attempting to model because I guess I can say that if the business process that you are attempting

to to model is more complicated

than the code you have written, then it's likely wrong. You have taken let's say, you've discovered that in the business model, there are 2 cases, x and y, and you realize in your mind that, wow, these 2 cases are really very similar so I'm gonna roll them into 1, but the business model didn't get changed, only your program got changed, and I'm gonna say that your program is now wrong because it merged those 2 cases, but it made the program simpler and perhaps easier to maintain, but it didn't model the business process anymore. Now

take this on to my

interest in mazes. I drew mazes as a kid. I found many programmers or people with with mathematical

backgrounds

were very interested in mazes as a kid. I stopped drawing them when I was in high school, and just never returned to it. Until about a year ago, when I was in an office depot, and I saw that they still make flare pens.

That's what I used as a kid to draw mazes. So I bought a set, and sat down and immediately started drawing mazes and thought this was this is amazing. I love this. After drawing about 20 of them, my husband suggested

that I try drawing them on a tablet instead. And so I got my Android tablet out and I bought a a

a pen for it and started drawing on that, and wow, it was amazing. I could really do some interesting things, and I realized with these drawing programs, I can do layering and make layer masks and put these things in the colors that I actually see them in in my mind. And from then, all of a sudden, these amazing things started coming out of me. These,

represented,

botanical drawings, and I stunned myself with these things. I've I've done I think I finished the 44th 1 just very recently. Some of them take up to 80 hours to draw, but it's as if maybe perhaps sometime a year ago, it's like I had a stroke

or something. And all of a sudden, I have an artistic ability that I never thought I had.

It's great to discover something new at age 56.

Yeah. It's definitely an interesting story because viewing the images that you produce, you would think that you've been doing it all your life because I must say they're quite astounding and incredibly detailed.

They're very therapeutic

to draw. I can sit for several hours

and just in a mindless state, almost

zen like meditation,

draw these things. They're drawn in several stages. I first draw the lines,

just on a whim exploring different sorts of patterns

and then I use the feature of drawing programs of flood fill

to find out what regions I have made connected lines in and then I engineer the maze from that using, I guess, my programming skills.

Maybe I should say I should use use my my skills of deceit

to try and to try and make these, mazes as difficult as possible. I don't think I don't know of anyone who has ever solved 1 of my mazes.

I know they all have solutions,

because I I prove it to myself before I publish them. I actually had an art show in my little town here in June. This show went for a month and I think for an unknown artist in an obscure gallery in a small town, I did extraordinarily well for selling 7 pieces

that went for from 350 to $500 each. It was amazing. Perhaps I have a new career if I ever get out of this programming stuff. Yeah. If you get tired of slinging code all day, you certainly have the talent for it. And for anybody who hasn't seen them, I'm gonna put a link in the show notes. But, you know, if you look at them from a distance,

you would never guess that there's actually a second layer of purpose behind them beyond just visual artwork. And

the amount of detail that you can get out of it at the same time as incorporating

such complicated mazes is just astounding. And the fact that you start with just sort of an exploratory

approach

of seeing what sorts of shapes and patterns come about and then using that to then direct the creation of the maze. And I'm assuming as well the actual content of the image is pretty remarkable.

I decide what the content of the image is going to be ahead of time. I don't just it doesn't doesn't spew out just whole. I'd said, okay. I'm gonna do a poppy here. And now I I sit and look I look at a poppy and and decide that what shapes are interesting and then start drawing them.

And playing again on the subject of complexity,

at Mozilla, you've helped with the creation and stewardship of a project called Socorro, which

you mentioned in your keynote. You utilized some aspects of complexity analysis for being able to correlate the stack traces that you receive into this project. And I'm wondering how you sort of came across or approached that idea of incorporating that sort of level of theoretical application

to something like error monitoring?

Well, the, the actual use of fractal dimension

for

categorizing

our classification of errors with something that never made it actually into the production code. We built the system over the last 10 years

and it's a complicated

multi process, multi threaded,

application

with my signatures all over it. And, at the final iteration before I've left that group, I create what created what is called the processor as a rule based system, so that classification

systems can easily be written and then just plugged into this system at configuration time. And so while writing the,

keynote, I was thinking about different uses of complexity and I thought, well, you know, or rather fractal dimension, I could write a classification system for Socorro

that used fractal dimension. And so I coded it up in just a few minutes and inserted it into my own personal copy of Socorro and then ran a a 1000000 crashes through it and discovered

that I could do some correlations

between crashes that the rest of the system hadn't detected that were similar crashes or from the same root cause. But then at that point, you know, I was doing that for the lecture not for Mozilla.

I found some counterexamples

where it didn't work as well, where it found some correlations, where there were not actual correlations. There may be something to it, but it would take a little bit more work, and I'm not with that group anymore. So it's kind of gone by the wayside.

Well, it's still a very interesting

application of that kind of, analysis,

and it it'll be curious to see if that does evolve further and maybe some of the other areas that it might pop up. Mhmm.

So can you describe a bit about how the Socora project is architected and sort of how it works under the covers and maybe what the evolution over time has looked like for it? Certainly.

I started on the Socorro project

in, I think, 07 or 08

just, before the release of Firefox 3. It had already been started, by some of the platform engineers

and then I was brought on to complete it. And, in some ways, it was kind of like after some nuclear disaster and all of the developers were just gone and all of a sudden the code base was given to me and there was no 1 to talk to about it or what it was. And the idea was that I had to make it work in a very short order and of course, Python is really good at that. And so I hacked the thing together to make it work and it worked mostly,

but it was an awful hack. And then for the next few years, we

did,

a group kind of formed around me and we did what I call retroactive

forethought.

We refactored the code and took the hacks out of it to make it, more of an engineered thing rather than something just thrown together.

So it consists of several,

independent parts running on separate machines.

A collector, which is just simply well, at the time was a Python,

It was actually a mod Python, I think, running under Apache

that,

catches the crashes as they come in from the field and stores them, on disk,

on the the web head. And then another process takes them off that disk

and sends them into,

long term storage. At that time, it was another disk and Postgres.

And then another process running on several machines,

pulls them off the disk and out of Postgres

and performs a miracle,

using

the stack walker and remarries

this binary blob of stack information with symbol tables,

so that,

we can find out exactly what the code was that crashed. And then there's a

a web app in front of that that, allows the developers then to go in and look at these crashes, categorize them, look at aggregate

information about them, and actually drill down into our source code system to find out exactly what lines and look at the lines of the code. It's all multi process,

multi threaded stuff.

I went from multi threaded from the very beginning back in 07 because I love multi threading and then over the years,

I started to do generalizations.

1 of the things that was most apparent about the project is it needed to be very quick on its feet for a changing environment.

We decided we were gonna in 2010, we decided to move and use HBase

to replace the file system storage. And so we built 8 HBase modules and and linked them into the system, but I wasn't satisfied with that because I knew that we were gonna add other things in the future. And so I came up with this library that I call ConfigMan

that does dynamic loading of modules in Python

so that like connecting Legos together at the configuration

time, we can change the front end or back end of this system at will. By the the climax of this in well, I can't remember was 4 between 14 15 that we had dropped HBase and we're moving all of our data to Amazon S3. We were able to put Amazon S3 module in and just tell the applications to sig hop, and so they added Amazon S3 in parallel with HBase

without shutting the programs down even. It just reload like reloaded configuration and kept right on running, not losing a step. Ran that way for a month till we verified that the Amazon s 3 and the HBase data was identical,

and then rewrote the configuration to take HBase out, sent sick hub to all of the,

applications.

HBase was gone. Again, the applications didn't even have to be shut down.

That's quite a remarkable feat of engineering.

It I I was very proud of it.

Unfortunately,

it adds a significant amount of complexity

to the system with the added benefit of the flexibility.

You know, I say that

in my career,

any of the software

that I hard coded any external resource,

that software is long gone. It had a 2 year life at most. But software that I've written

that allows to have dynamic configuration

and dynamic loading of modules, in other words future proofing it, it still is running today. I did something similar to this way back in my career in the 19 eighties

in the language Fortran to drive

flatbed plotters. A couple years ago, I went back and visited that company that I did this for and found that my Fortran code is still in use 30 years later.

Speaking of somebody who hasn't had a technical career anywhere near that length yet, that is my my hat goes off to you, sir. Thank you. Thank you.

At this year's PyCon US out in Portland, Oregon, you presented the closing keynote, and I have to say that it was 1 of the most engaging

and

engrossing presentations that I've ever seen. And I'm wondering

where you got the inspiration for that talk, how you conceived of the mixed media approach to it, and as a follow on to that, how much you had to practice?

Mhmm. Well, there's a story behind this too, and it all revolves around the regional conference, PIE Tennessee.

About 3 or 4 years ago, PIE Tennessee was looking for sponsors. They went to Mozilla.

Mozilla

sponsored them and they were look Mozilla was looking for someone to speak and I happen to have a whole bunch of friends that live in rural Tennessee

and so I just said I will volunteer to speak

and talk about Socorro. And so we arranged it and I spoke the conference and of course, you know, it's 1 of those multi track things. And I think I had about 5 people in my audience.

And I think the organizers of Pi Tennessee felt kind of bad about that. So the following year, I decided I was just I would submit papers,

proposals to PyTennessee,

and I submitted 3 proposals.

2 very serious very academic proposals. I think 1 was about multi threading and the other 1 was about configuration.

And then I decided I would send in a joke.

And so I made a proposal

about parallels

in software engineering

with baroque music from the 1700.

Well, they called my bluff.

They rejected the 2,

proposals,

the academic ones, and chose

the music 1. So I had to follow-up,

and that became my lecture called The Well Tempered API,

subtitled, I can play 300 year old music, but I can't open a Word document from 1990.

And,

it was multimedia.

I,

hadn't played a musical instrument since high school, and so I learned to play this,

electronic woodwind of mine and,

gave the presentation. There's a couple different recordings of it out there if you want to find it.

You can go on to either Air Mozilla or on YouTube and find Well Tempered API and you know there are a whole bunch of interesting parallels between music and software engineering. I was

realized that

cooperative multitasking

was done by organists in the 1700.

In fact, if you look up baroque cooperative multitasking

in, YouTube, you'll find a, an excerpt from my original talk at pi Tennessee that year. Then just as I was I'd finished that and figured that I was gonna be done speaking for a while, the Py Tennessee people invited me to do the keynote, the opening keynote for,

this year in 2016.

And I decided, well, let's just see how long I can stretch out this music thing. And

at that point in at Mozilla,

I was

getting very frustrated

with complexity

and the inability of so many of my co workers to understand my code because it was too complex. And then I decided to demonstrate

how if you don't think about it, everybody loves complexity.

If you look at a a soap opera, they constantly you have these like 7 or 8 second scenes that constantly jump between story lines.

That's cooperative multitasking, and we eat it up in entertainment, but we seem to not like it in programming because it's too complex. And so I made a,

a talk for their keynote that I called,

Fractal Dimension Music

and the Art of the Left Turn. And that was the genesis of my,

PyCon keynote because just like the day before I gave the keynote at PyTennessee,

I got the invitation to do a keynote at PyCon. And, so

I modified that talk to become the PyCon keynote.

I took out, the reference to to music. I changed a whole bunch of things in it. I shortened it a little bit.

I took out some very nice things I thought but I only had a certain amount of time to fill. I could well, as you're finding out in this interview, I can just talk on and on for hours.

And the idea in the the presentation

was to make

a as complex

a presentation as I could possibly make. Jumping back and forth between stories

and yet engage the audience as much as I can and and everybody was gonna get something different out of it. Everyone was gonna notice something different, but there was gonna be something for everyone and every skill level in there. When I was,

invited to do the the, PyCon,

I asked,

Brandon Rhodes about what should I talk about?

And he said, talk about motorcycles, talk about mazes, talk about music. And so I said, okay. I'll talk about everything. And that's what I ended up doing. So

as for how long did it take me to rehearse all of that? Having the Pi Tennessee experience behind me and doing parts of that presentation,

I'd say that I ran through the whole presentation

3 times

ahead of giving it at PyCon. However,

the music

in there,

I practiced to death.

I,

that is the the most stressful part of the presentation.

Playing music in front of a whole bunch of people. I am not a professional musicians. I have I have a high school music education

and well, I like my maze drawing just a very short time as an adult,

playing music. I know very little about music theory except what I learned for when I wrote the Well Tempered API talk and so that part of the presentation I rehearsed an awful lot. Still made a lot of mistakes. I can't stand to look at the video of PyCon because I

cringe at so many of the errors that I made in the music.

Well, speaking as somebody who isn't as,

adept at musical theory or musical analysis, I thought it was very enjoyable. Thank you. And it seems that you've got a bit of incidental virtuosity

in as you, continue on in your life,

putting a lie to the fact that you can't teach an old dog new tricks.

Absolutely. Absolutely.

So another part of the presentation

that I think tied it all together quite well was the fact that you managed

to integrate a rather personal and impactful story

as

a, sort of it was almost a

secondary plot throughout the overall presentation

as sort of a subtext of complexity.

And so I'm wondering what what inspired you to bring that element of the presentation and mix it in with the complexity analysis and musical presentation and fractal dimensions.

It was the realization

about how different my own mind is from other people's. I've spent a lot of time in the last year asking people how do their minds work? What do you think about? How do you program? How do you think? And in the same manner that it has become so evident

in the tech world about our lack of diversity,

not only in race and gender and gender identity, but there's also a lack of diversity

in our own minds.

If you are,

familiar with,

the professor, I think at Colorado State University named Temple Grandin, She has given some wonderful TED Talks,

about the way her mind works. And I think that we very much need

to embrace the different ways that people's minds work. We seem to push in software toward a monoculture.

We want everyone to code the same way. We want because it's easier to maintain. We want everyone to think the same way and sit in a cubicle, and there are lots of different ways to live one's life and a lot of different ways that our minds

the

the recursive partition sort. I wonder what how his mind worked and how he was different from his peers.

How he was different to the way mine my mind worked. And then it was such a tragic story that I never found out. And it was during

the Pi Tennessee

writing the the present at the keynote presentation for Pi Tennessee that I got out my copy of that book and discovered the translations

of what had been written in there, which was just stunning. I had I had no idea. It still brings tears to my eyes to think of how much regret I've had over my whole life and not knowing that the my absolution, so to speak, was in this book that I have been carrying with me for 30 years.

Yeah. It's a very it's a very powerful story, and I think that it went well along with the presentation that you made with the motorcycle video Mhmm. Which I thought was well presented as well as the musical presentation, and it just it it blended all together really well. And I actually came home from the conference conference with, and they've said, you know, I I had to

show this presentation to this other person,

they've said, you know, I I had to show this presentation to this other person who isn't necessarily technical, but they were still able to appreciate what you put in there.

Well, I was totally amazed by the the talks reception.

I knew it was a pretty good talk, but I had no idea that it would,

be that well received.

Plus, I must also say that I am proud of the fact

that

I can bring

that kind of emotion

to a group of technical people.

Yes. There were That is an achievement in and of itself.

Without violating the code of conduct.

Yes.

So in addition to your

extensive technical career, you're also very focused on living in a manner that is sustainable and in tune with the environment

and your philosophies. And so I'm wondering what kinds of synergies and conflicts exist between your professional

and personal ideals.

Well, I get pretty disgusted with the technical world

in how much energy and hardware

is wasted.

The fact that our computers and our phones

get turned over every 2 years and people who are lower on the economic scale, who have old computers because that's all they can afford,

but they get no support

and can't have the levels of security that we have.

I have some friends who live in rural Tennessee,

who use Apple Computers that are 10 years old. They can't get software updates anymore,

but it's all they can afford. And it really bothers me

that we have this stratification

of of technology.

Now as for

living sustainably,

I live on an organic farm,

I live in a yurt. 1 does not live in a yurt to be energy efficient because it is just a tent. Fortunately, my climate here is mild and our heating needs are fairly minimal,

but I do like the fact that my home

will last many many many years

and has a significant lower

significantly lower footprint than a house does. And at the point that I have to retire 1 of these tents, the yurts.

I can repurpose almost everything in it to some other other use.

I've started living in a yurt in 1995.

That particular yurt has been retired and there are pieces of it all over the farm serving all sorts of different kinds of duties from the parts that that didn't entirely wear out. We run our farm here as

essentially an incubator for people who wish to organically farm learn to organically farm. We lease the property out for 2 or 3 year blocks

to optimistic people,

and they

use our property to learn to farm. At the end of that 3 year period, they either graduate

and go off and buy their own properties and become farmers,

or they walk away glad they didn't spend more money learning they're not farmers.

And we have,

actually started at some very successful,

farm businesses

and had some pretty spectacular failures happen here too.

And as somebody who is technically inclined, do you have a lot of agricultural automation or any sorts of, I guess,

sort of sensor driven,

agriculture?

Not currently. When we were running the rose nursery, I sold the rose rose nursery in o 7, fortunately, right before the Rose Industry crashed. And,

I was just then starting to explore

using,

tagging,

of RFID tagging in plants to help track them in the greenhouses.

The system that I used, I I wrote for the for the uncommon rows in Python did some pretty amazing things that I still haven't seen reproduced

in other nurseries where customers would order plants,

to have them shipped to somewhere else in the country, and they generally in the rose industry, plants are ordered in the fall, they're shipped in the spring. The software that I wrote would go out to the websites

or the weather websites

and scrape data to find out what the conditions would be at the, destination locations for shipping. And if

the shipping route was likely to have bad weather or the destination was bad weather, it would automatically send an email to the customer suggesting we would like to delay shipment by 4 days because it's gonna be freezing in Denver, the likely route the plant will travel through in a truck and our customers love that and so we had that kind of sophistication

in our operation here, but that's all gone since we don't have the nursery anymore and the people who are doing farming here aren't particularly interested in that level of technology.

They're just trying to get plants to grow in the ground.

That's great. Are there any other topics or questions that you think we should cover?

Oh, I think we've talked often quite a bit here. I can't think of anything offhand.

I probably will, of course, 10 minutes after we

part, but

I can live with that. Alright. Well, if you do think of anything else, you can feel free to join our discourse forum and continue the conversation there along with anybody else who cares to partake. Okay. That sounds great.

So for anybody who does want to follow what you're up to and keep in touch, what would be the best way for them to do that?

My

website,

2 braids.com,

twobraids.com,

is where I do my blogging. That's where my portfolio of my art is,

and most of the stuff I do. I I tweet on Twitter at 2 braids, but it's the digit 2, braids.

Couldn't get

the spelled out 2 braids.

Unfortunately, the the poor woman who has that gets a lot of stuff directed to her that was supposed to be directed to me.

And and for anybody who isn't familiar with your appearance, can you describe a bit about what the genesis of that name is?

Back

in well, when I lived in the Blackfeet Indian Reservation, my beard is very long down to waist level, and I generally keep it braided into braids.

And,

you know, when I was teaching there,

I I gotta say I had 2 types of students, the men and the women. The women would say my name. The men

never would say my name. They'd always just call me white guy 2 braids. And so I embraced that and took the name 2 braids.

That's great. It's a great story to go behind that. Alright. So with that, I will move us into the picks.

For my pick today, I'm going to choose Terry Pratchett because he is a wonderful author who has brought a lot of humor into this world and a lot of enjoyment for anybody who has read his books. I'm currently reading his last book that was published posthumously. So for anybody who has never discovered him or who has but has recently forgotten, I definitely recommend taking a look at anything that he's written. And with that, I will pass it to you, Lars.

My pick for the day

is an old 1. I'm gonna say Johann Sebastian Bach's

tokata and fugue in d minor.

That's a great piece. If you listen to the fugue,

you will hear examples

of multi threading

and cooperative multitasking

in music.

Alright. Well, I really appreciate you taking the time out of your day to join me and tell me about some of your

work history and philosophies

and, the wonderful stories that went into your and, the wonderful stories that went into your presentations and everything that you've done. So I appreciate it, and I hope you enjoy the rest of your evening. Thank you very much. It was an honor to talk with you, and have a good evening.

The Python Podcast.init

Summary

Brief Introduction

Interview with K Lars Lohn

Keep In Touch

Picks

Links

The Python Podcast.__init__