CppCast - 40 Years of Programming and Embeddable Programming Languages with Mark Guidarelli

Episode Date: July 13, 2026

Jason and Mathieu are joined by Mark Guidarelli to discuss the history of C++ and esoteric programming languages, Mark's own development history spanning four decades, and what "merging" used to mean before source control. News The code::dive 2026 call for papers is open Gor Nishanov, author of C++ coroutines, recently passed away C++ Documentary was released Check out the C++ Perf Quiz Links trix - Mark Guidarelli Mazes for Programmers - Jamis Buck Game Oriented Assembly Lisp - Wikipedia OpenGOAL Practical File System Design with the Be File System - Dominic Giampaolo (Internet Archive)

Hello, and welcome to the 409th episode of CvPCast, the first podcast for C++ developers by C++ developers. I'm your host, Jason Turner. Every fourth episode of C++ Weekly is a crossover episode for CvPCast, for those of you who are watching this on the C++ Weekly YouTube channel. You can choose to watch the podcast on YouTube or listen to it on your favorite service, and there have been questions. I'll just go ahead to clear those up right now. We're having a little bit of an issue coordinating the exact release, these times for both CPPCAST and the podcast services on the YouTube channel. And we're sorting that out. Hopefully, it'll be sorted out soon.

I hope. I hope. Anyhow, I'm joined by my co-host, Mathieu Rappere. How are you doing, Mathieu? Hey, I'm doing good. I had lots of travels over the past couple of weeks, and I've been settled in the same place for a week, which is crazy. I had conferences.

I had climate meeting, had family trips. So now I've been in the same place for a week I forgot how that feels I guess compared to you Jason That's nothing But I've also been in the same place For a week now And that's kind of weird

Because yeah we had been traveling For a full month up to this point here Well that's a story for a different time I guess But you and I did just see each other At ACCU on C Yep Yep

Exactly And after that I had to take a flight To Finland for a client And then I'm back in Stockholm Oh we should talk about whether or not you would want to move to Finland. Let's bring in our guest. This week we are joined by Mark Guiderrelli.

And Mark is kind to animals. He is a real-time embedded system software engineer, machinist, fabricator, cat servant, and pinball. I read that in a weird way. What was that supposed to say at the end of there, Mark? And it's just pinball. And pinball. It's just pinball. because that's a non-common thing.

It is definitely a non-common thing that we all spend some time chatting about here, I am quite sure. Would you move to Finland, Mark? I would be interested in Scandinavia, yes. So I mentioned you, Sweden, and I love Sweden because they know how to make a great breakfast. Of all the countries I've ever been in, the breakfast since Sweden were the most amazing. I'm sorry, which country are you from? Because that's not possible. Like, there is good things about Sweden, but food is not one of them.

I like glutafisk and stuff, so that's good. Oh, my, no, oh, please no. So what I've been doing recently is yesterday at my company's term pinball, we released a Fourth of July release for all 34 games that we've done recently. So me and my team were quite busy for the last couple weeks. Wow. Yeah, we do that occasionally. I do an all-game release to catch everyone up on the platform.

So games that are 12 years old will get an software update. We, oh, just for the sake of our listeners, by the way, the reason I asked you if you had moved to Finland is because I had getting ads on Reddit telling me to move to Finland, basically. And that's, you know, I thought it was humorous. Anyhow. Honestly, Helsinki just feels like a slightly smaller stockholm. They use euros. So that's a bonus for me because it makes more sense.

Finnish is a bit impenetrable, though. Swedish is not an easy language, but I think it's much more easier to understand. It's a Germanic language. So if you know English, you know, it looks like a weird English role with German to some degree. can kind of guess some things. It's not like completely out of like, uh, Finnish is just its own thing. Finnish and Basque are on a different tree of the language.

Yeah. Yeah. It's just a small anecdote about language. It's not very important. But a guy I met there told me that, uh, you know, in Sweden, in Finland you can speak Swedish or Finnish as the two we could nice languages. And funny enough, all the expats and immigrants who run Finnish nationality speak, because you have to take one of those two to take the national citizenship test and everybody tells the new immigrants do not pick finish it's impossible to learn pick swedish it's

much more easy to get the like whatever level you need to pass the test and then get all with your life huh oh that's uh it's kind of funny i guess that you get the choice i wonder what it's like when you move to switzerland if it matters which canton you're in i should know the answer to this question but I don't. Perks of being an international podcast we suddenly sometimes get interesting random question about what it's like to live in another country. All right, we're going to cover a few news items. Code dive 2026. So dates have been actually announced for this. Is that right? Yes, yes. It's going to be the week before meeting C++ actually. So if you if you're interested in attending, oh speaking in both, you may have a shot

because it's like you have one week to spend in a we have the weekend to spend to visit ralcliffe and then you can take a train to uh to berlin from uh from boch lab i think it's two or three hours pretty scenic and that's that's it that's i've done it once i know some people have done it more than once it's when very aligned it's actually nice when conferences align and you can just take a train between two european cities it's uh i think it's a really nice experience yeah and uh co-dive it's a great town but i don't know one of my main motivations we're going honestly is that they tend to have it right when the Christmas market opens. And I don't know if that'll be true.

That should be true, actually, if it's going to be that... Yeah, it's going to be late November, like 18th or something. Is the call for paper still open on that one? Yeah, yeah, yeah, yeah. I haven't seen it yet. Usually they send me an email to tell me it's open, but I think it is already open. It is open, yeah.

I will not be able to make either of those conferences, unfortunately this year, but I'm hoping to go to all of the European conferences next year. do a big tour. They have changed venues, so I don't know what it's going to get, but in the past, and I think you've been there too, Jason, right? The really cool thing about code dive is that their venues is cinema. So if you get to speak, you get to speak in front of like 500 people in like an IMAX

sphere or something. It's not IMAX, but it's a big, big room. I've never seen my slides so big before. Yeah, yes. Big projector screen and they tend to have a lot. lot of attendees. It's just a single day conference, though. Yes. It's free. If you happen to be in the area, if you can make it to Rochav, it's entirely free unless we change the formula. No, that should be right. It's all sponsored by Nokia each year. Okay, so the C++ documentary has been released,

although I don't know if it's publicly available yet. Are they doing screenings of this? I believe it's on YouTube. I watched it on YouTube. It was quite entertaining. Oh, okay. Oh, very good. I missed that. I knew that they had done a private pre-screening like a month ago in Chicago or something. I didn't realize that it had been completely public now. But did you think of it, like you said it was funny or entertaining? Well, not funny. It was interesting. I mean, I lived through almost all of it. So it was very familiar and it was a retelling of history that I knew. But it was fun to see the actual people saying the actual stories that I had heard or read about. It was informative and you know documentaries are one of the major things I consumed so I enjoyed it

yeah definitely check it out I should watch it as well and on some sad news here gore nishinoff who is the author of the co-routines that actually got accepted in c++20 if you recall there's there were several different competing proposals for co-routines gore actually passed away very recently here at the time of the airing of this it will have been a few weeks ago now. Yeah, it's sad news. I don't know if I ever met him, but the work on Coaches is certainly something.

Herb put up a memorial page to him and had some really kind things to say about him. We'll link to that in the for the episode. Yeah, that's the one I read. I liked it too. It's interesting stories from Herb, like things that I did not know. I have met Gore, I believe.

I interviewed him on CBB cast in very long. time ago. And Herb said that during that proposal period for co-routines, that Gore was actually helping all of the competing proposals to become as good as they could be as well, so the best one went. That's interesting. Oh, yes, for people who want to go back in history, that was a piece of 110. 2017. Oh, wow, that's even before I started listening.

It was, yes. Well, that's, yes. we're getting into personal ancient history at this point. The CBV quiz link that you put in here for Boolean Short Circuit ordering. Yes, yes. I liked the idea and then I tried the quiz and I think after two questions it went on like, do you know all the atomic sequence like by heart? Yes or no?

And then I gave up because it was like, and I know if it's random which question you get in which order, but I kind of felt there was like a gap. I would say like a canyon between the levels of some questions. I think it's a really interesting concept to like, oh, what is your intuition as a programmer of like which is faster? I don't think it should maybe go for like that tricky. Like do you know the atomic difference between the atomists like sequence acquire, sequence release and whatever is the other ones?

That's the kind of thing that will get you a talk for like advanced people at a conference. But I think for the basic things like, hey, which of those two loops is faster? what happens if you do this or that. I think it's a very good idea. And I think that would be very good for people who get into C++ or just want a refresher. I'm like, hey,

are you aware of what's faster than what? I think maybe just a better data set would make the concept go a long way, in my opinion. I don't know if you tried the quiz yourself. I tried the first three and they were the first one, I was immediately on guard because I'm like, this is so obvious.

There must be a trick, but it wasn't. So then once I got over that paralysis, I did the first three and there were increasing difficulty but fair. I didn't get to one about Atomic. So I'm not sure if I didn't go to number four when that happened. I got the first three right and said, well, this is cool. I'll do it later. And then I forgot to follow three on it. But I thought it had value and it's something I would use to talk to some of the younger engineers I mentor to walk them through some of the thinking.

process. So I thought it had value. Yeah. I suspect it's just that the questions are random and I got like an interesting draw. Yeah. Yeah. I just like my atomic's better. Maybe I should know my atomic's better. But I would not say I know atomics off top of my head. I have to run this EPP reference when I start playing with them to choose between the flavors. I actually, I agree though. That first question about, you know, which of these is faster made me stop for a second. I'm like, wait a minute, I'm pretty sure I want a short circuit on the first. This is a trap. But then I started to wonder, so I can guess myself, I'm like, well, what if it's very rare

that the first one short circuits? Maybe then it would actually be better for the branch predictor. If I did put the expensive one first, right? Like, I don't know. Oh, that's the article I forgot to mention that I should have mentioned. Speaking of branch prediction, have you seen the GCC news? I think it's from a couple of weeks ago now. Some guy tweaked a branch prediction heuristics in GCC

and made every test program on 10% faster on like X86. And it's a one-line change that changes what is the number from like 3 to 10 before you consider that a branch prediction is actually like more expensive. I need to find the thing to just not stop talking out of my ass and get you the actual data because it's a one-line fix. There's a headline about that when you read the paragraph and then when it's always saying it's against a known test suite I get skeptical sometimes. Yeah, although I mean I would agree with you but on the other hand, GCC's test suite is

absolutely ginormous and if they can manage to make all of their tests run fast. Right, if it's a GCC one as opposed to another curated one where someone's trying to win There's a cost that they do some math to figure out what's the cost of making a brand's misprediction. And he changed the number from 2 to 5 by doing plus 3 on the math. And they report 12% faster on both Intel and AMD. Just by saying, hey, optimizer, this is the penalty if you guess that wrong. Right. And apparently makes the code generates differently and be like,

Oh, yeah, no, I'm not going to risk it anymore. I wonder if that's something you can tweak anyhow because a lot of those thresholds, well, at least with Claying, you can tweak some of the like inlining thresholds and stuff. I wonder if you can. Hmm. So you feed it through a G-Prof loop or you train it on your actual program and a representative data set.

Yeah. There's a caveat that this is for the, yeah. There's a caveat that's for the generic, like not the architecture tuned version. If you target like, you know, if you do March Native and you compile for your own computer, it will probably do some math that is maybe better. But for the generic case, they kind of figured out that for the average computer now, the pipeline being deeper, they should increase the penalty of mispredicting a branch when they figure out how the optimizer make a decision.

That makes sense. But it wasn't funny, like, oh, I tweaked a number by adding. I changed the two into a five. and now suddenly it's 12% faster on the average computer. All right. Let's get to the interview going, I believe, if there's no other news items. Thank you for joining us, Mark, by the way. I don't know if I feel like I did a proper introduction here since I got stuck halfway through your,

well, not halfway through your bio. Your bio is very short and succinct, and people tend to give us larger bios, so I didn't know what to do. But I know that you have actually had a pretty long career in C++. You just commented that watching the C++ documentary was like watching a replay of your career, basically. So like, I don't know. If you want to start here, do you just want to give us like an overview since there's

that teaser there, like when did you start with C++? Oh boy. A co-worker of mine bought Cfront 2.4. the fall of, whenever it came out, what was that 18 something, 89, C4 and 2.0 came out. And also we were using Zortec C++ very early on. So we, another engineer and I were working on a fascinating project. I've been very lucky to work on a lot of interesting projects throughout my career. This one was interesting.

We worked for a company that made soft. for the movie industry. Things for budgeting films, scheduling films, doing script writing, formatting. They were all written on the Macintosh. They wanted to get into that PC market that was much bigger. So what's the natural thing you do? Me and another engineer took Inside Mac volume 1 through 4,

opened it up, Reddit, and wrote a software library that implemented the Macintosh library as it was documented, made it a linkable library, and you can now run your Mac program on a PC with overlapping Windows before Microsoft Windows existed. Wow. It was really a fascinating project. And we're talking this is back in the day of CGA and Hercules graphics cards. So really early on.

It was a fascinating project. So we tried to write good code, and we are really jealous of not having function prototypes, because this is the days of K. So what do we do? We buy C-front purely to get function prototypes really out of it. We didn't really use a lot of the C++ language because we still had to work with WOTCOM, C, and a lot of the other C-compilers. But we wanted C-front to have a better C and used some features as it was convenient. So we started out really or started out really early with C++ in those days. Zortec, C++, the early C-front. And then as the language started to get more and more mature,

hopped on other compilers and kind of rode the wave of all the compiler technology. Also that engineer and I also back in like 89 bought Sun 350s, the head, the discless Sun 3s. I had a friend that worked for Sun and we were able to get these workstations really inexpensive and, you know, upgrade the memory through a hard drive on it and had a Sun 3. So I was starting to work with Sunview and all the C and C++ and rode the wave of GCC and kind of hopping to one of your things. What was a seminal moment in C++ for me was GCC 1.37.1. That version was one of the best early version.

of GCC with G++ that was really solid on a 68K and other processors. Actually, I think 60 or 20 maybe it was on the Sun 3. So we were in on it really early. And you were using at sea front in SORTECH. You said on a Mac and on DOS? No, not on a Mac. On a Mac, geez, early bad days of C programming, Aztec C for Manx on a Mac in 1984 or 5 was a painful time.

to be working in C. Now, Zortec was on a PC and C-front was actually, we had a 386 PC running System 5. We were running System 5 Unix to have Seafront on it to do all our development. And the final product was shipped on WOTCOM with the Far Lap DOS extender. If anyone ever remembers those bad old days to make the product. Wow, goodness. It's kind of crazy to me how some companies, some projects were like really interested in the whole idea of like stronger typing from C++ back in like late 80s. I went to school in the early 2000s and still everything was C and even if we were talked to C++, like the default was still if you want to make a systems program, you're just going to do C. Maybe it's influenced by the fact that a lot of like a GNU and Linux and other like things were all

see and I mean still are to this day but it's kind of like it feels like it was 20 years like they all 10 15 years they happened but only for that specific projects or industry I think there is for the longest time and there still is in the games industry and other areas suspicion of c plus plus what I don't see a constructor does this a destructor does that the the fear of an expense that I can't see and of course with compiler Explorer and now you can really see that it's pay as you go. But there are still a lot of people that are naturally suspicious of what happens behind the scenes on C++. Because they haven't chosen to learn about the costs, you know, whether hidden or not.

I hopped on C++ very early to be a better C. I got better warnings out of it. I got better code out of it. I got better type safety. For me, a lot of what I do is, I write it all in C++ and I use classes for data encapsulation, but do I inherit? Not that often. Do I do multiple inherits?

I've never done it in my life. Those are things I avoid. But, you know, Jason, I've shared with you my warnings list of I have like 43 different warnings on GCC, no implicit conversions. I will cast, you know, I will do a static cast up and down just because I want to know what's going on. I control the size of the data. I want no implicit conversions ever. That's a choice that I've lived by it.

So I started with C++ to get a better type safe C, to be able to get better warnings and grew into the features as they happen. Namespaces, you know, things like that are just wonderful kind of gifts to me as a systems programmer for me to be writing better, safer code. Yeah, no, that presents a lot with me. I think there was, and I think this is clearly not the first time, like, on this podcast or us or anywhere else, someone has said this. But I think there was a lot of harm done by people teaching C++ as luck that you can do CLAV. Because that's what I was taught in school.

The first time I was given C++, I immediately started writing a class hierarchy because that's cool. We have OOP now. And maybe, you know, when you get it from C as just like, hey, this is an improvement over what we can already do. and maybe you already, I don't know how long you had been already programming back then. I guess you had more experience already to be like, oh, I see the limitations of like KNRC and the lack of the type system. And oh, those things make sense and that's why I want them. I suspect this is the main issue. People are, I can't you see the press.

You're going to have virtual. You have like, only if you want to. You don't have to. Right. I had been programming professionally for at least five years at that point, Fortran, even on punch cards and things like that before that. One thing you touched on, class library, things like that, another seminal moment in C++ was National Institute of Health's Class Library versus STL.

I don't know if you've ever seen the NIH Class Library. That was the thing that was available before STL. I forgot the gentleman's name that wrote it, but it was basically the entire small talk class structure written in C++. It was a very fateful implementation of that, but by modern standards, I would say, boy, that you're biting. To do one bite, you take the whole apple, right? Because it's kind of like Objective C where you have a base object and everything has to descend from it. and it kind of goes into madness from there as far as complexity and cost. You know, you take a bite of the entire Apple when you go into that.

And that's another kind of jumping forward in your seminal moments for C++, the war or battle of NIH versus STL. Similarly, C++ versus Objective C. In Southern California, where I was amongst the defense contracting companies, and I worked for General Dynamics for a number of years. There was an internal battle. Are we going C++? Are we going Objective C?

And there was advocates very, you know, pushing their point of view on each. And for a long time, Objective C was kind of winning. I forgot at what point. I think it was the STL. I think it was 89. That just wiped out kind of Objective C and the industries that I was working. in at that point. Apple, of course, hold on to it forever. Yeah, I was going to say, sadly, the people who knew Objective C all managed to find

their way into Apple. And now every time I have to do something on Mac, I have to deal with those dot-MM files that drive me nuts. Right. And it is still the default. Like, I am kind of losing my mind every time you're like, oh, you want to do system programming with Mac. It's still like the base library, everything that they have not ripped off of like a BSD. It's, it's, I'm or Linux, it's just, it's just like I do graphics programming. I had to deal with metal recently. Yeah, it's all like Objective C. And it's kind of curious, I'm not going to claim to know a lot about Swift,

but I did read the initial papers that they chose to stay with the Objective C runtime model, which I'm not sure if that's the strongest feature of that language, but now Swift inherits that and that's still the runtime model for everything. Well, Objective C is what was chosen for Next, and it became part of the Apple core system after Steve Jobs was reacquired. Yeah. And the Next was wonderful. I was the next developer for a number of years. It was a wonderful machine.

That's cool. I don't, I've definitely never programmed for Next. I feel like I read some docs at some point forever ago. Did you ever have the BOS machine by any chance, Mark, since you're talking about it? No, I never did, but I did admire. the file system on BOS was very nicely done. I've had the opportunity to write a real file system before, and there was a very good book.

The person who wrote the BOS file system wrote that taught me everything I needed to know to be able to actually write a file system. That's cool. Do you happen to remember who that was? What book that was? I will send it to you offline. It's not in my memory bank at the moment,

but I'll find it. That's fine. I just remember BOS was, Well, you know, B and next were things that were in my consciousness as an early university student. But, you know, things that I couldn't afford to access, basically. I thought BOS run on X86, but am I confusing that with something else? It did in a second generation. Yeah, sorry to interrupt.

Next, the final gasp of Next step, they had an X86 version. For some reason, BOS sounds like 60, 30 or something. I can't quite remember. I think they were a dual core power PC architecture initially. And then when they knew they weren't making money by requiring people to buy their B boxes, then they apported to X86. Makes sense. And it lives on as haiku today, basically.

Right. Oh, okay. I think when I was in tech school, you know, you always have like a guy or two that is like willing to wheel distributions. They're willing to introduce you to something exotic. And I had a guy who had a BOS. I think the one thing he demonstrated is that with the cheapest sound card on the market, you could still open it and play like 20 million MP3 at the same time. And he would somehow work while Windows will immediately explode if you try to play to wear a thousand parallel at the time.

So that was, I remember a thing that impressed me like, wow, they can have. have audio drivers and they can make sound. It just works. Sorry, flashbacks from the first time I tried to play an MP3 on my Linux system back in 1995. My computer was exactly fast. I had to, I had to do a five-minute pre-buffer for the MP3 decoding. It had to decode the entire MP3 before I could actually start playing it. Otherwise, it would hit up against the buffer. Anyhow, Mark, I'm curious. And your history of using C++. Did you like, in those early days, I'm kind of surprised that you didn't like run into like, you know, compiler bugs and stuff that would have just put you off the language.

So C-front was actually amazingly, again, we weren't using it very stressful. Seafront never gave me any fits that I remember. Zortec C++, Walter Bright wrote that he was very upfront. It had a read me that came with it and said what works and what doesn't. He was very upfront saying these features are solid. Be aware some of these are a little sketchy. Here's corner cases. A pointer to a virtual function.

You know, things like that might not be so solid. So he was very upfront about it. And as I recall, did lots of updates. I never had fits with it. What I had fits with was Watcom was buggy. Far Lapos extenders were buggy. Aztec C was buggy. All these early compiles.

were just really not very robust. So, but Seafront and Zortech, for the way we use them, they worked very well, very well. You know, for our younger listeners here, how would you find out that Zortec had an update and how would you acquire the update? That is a great question. I think White Magazine or Creative Computing,

I would see the ads, and I would probably either mail or phone call and order it. This is, you know, things like this were, yeah, there was no instantaneous, there's no way to know about it. You would see an ad and bite magazine and go, holy moly, Zortex up to 1.3. You know, I better call and order it. That's awesome.

I have expected you to say that they had a BBS that you could sometimes download patches from. You know, BBS is, man, when did we start? really touching BBSs. Okay, I, I don't, I remember doing that personally, but not for commercial software. Yeah, I don't remember downloading patches or anything like that. It was always snail mail buying something.

Mel, you a floppy back. Pretty much, yeah. Yeah, I guess, is that a commercial software? Because I assume it's a commercial software and your client, maybe they will extend like a courtesy of like, you know, either directly mailing you the update or at least giving a call to someone, which I assume can absolutely get lost because it's so easy for a phone call to get lost. Back then, you either didn't get the call or you had an answering machine.

But yeah, that would be another thing is a flyer in the mail like a postcard, you know, saying, hey, you know, buy the upgrade. Right, because they would sell the upgrades at the time. They would not send them for free. Right. I remember going to a computer store to buy my, DOS 6.22 upgrade floppy because that one was just a single floppy disk and it costs like $10, but Microsoft is not going to give that away.

Right. Anyhow. But also these didn't happen very often. So it would be, let's say six months. So it would be, you know, it's not like the patch of the day club and getting something like that. Oh yeah. No, it's an absolutely different distribution model. Obviously, I still remember back when we had to buy, like, mostly for video games, you know, you would get a, you would get the thing.

They started already when I was playing video games in the late 90s to get, like, updates that you would get by, like, buying video games magazines, because usually they would come with a CD. And the CD would have a bunch of patches for the recent version of the game, some shareware, maybe like a demo or something like that. But yeah, that was already like in motion. You could already send patches to some measure. But it's interesting how the economy of software has completely changed. And I'm not saying like just how you sell it, but like the economy of how you run it, you patch it. Going back to that, does that mean that's because it's a discussion that keeps going back and forth, especially like people love that in the video game industry.

Like the fact that back into the day when you release software, you could not just reason on the fact that, you know, if there's an issue, it's fine. we'll just fix it tomorrow or we'll have a day zero patch or whatever like you had to ship something and it had to work i was around for the cartridge era and i was around for launching you know did games on nintendo 64 launch titles for playstation one that's one and done you're going to manufacture you're making millions of units you have uh exhaustive in-house testing and then you have to go through sony or nintendo's qa testing so if you have to go through sony or nintendo's qa testing so It was there was a lot of rigor to that to make sure it was correct before it went out. And I assume it was the same for industrial software, right?

The thing you would get on a CD or the thing that always surprises me is we keep talking as a, you know, CI, CD unit tests as kind of like a new thing, you know, like something that the old God needs to get in line with. But paradoxically, they were the generation that could less afford to have box found in production than the current one. So it's always like bug me that we seem to be more rigorous on unit testing now that we can actually afford to have a bug slip because we can fix it on the day. Well, back in the day, you had none of that and you had to make sure it worked. So here's kind of funny things is at many companies I worked at, the CI's would be called the merge day. and you would stop work and everyone would be walking from desk to desk with a floppy, giving their version of the code to the other version to meld them together.

The one engineer and I used revision control system, RCS, on that one project. That was the first time I started using revision control in like 88, 89. And that was a little bit unheard of in a lot of companies. So I was at major companies doing, you know, video game development for the arcade. And we would walk, you know, with floppy drives from desk to desk and spend all day resolving, you know, gosh awful merge conflicts. And, you know, standing it up. And then one person's PC would be the source of truth. And everyone would gather around negotiating how the conflict gets resolved because no one wants to.

to have their code be the one that's getting butchered. So it was a different era. It was the bad old days. There's nothing good about that. That was the bad old days. And we've learned better. But to your point, we had limited resources, limited machines, limited technology,

but we had some of the most hard constraints. Because like in the arcade, we would be burning eProms or even worse, masked ROMs. You have to commit this. and burned once ROMs that, you know, if you mess up, you have to flush all that inventory, and no one's going to be very happy about that. So we would have a combination of masked ROMs and then EPROMs and do weird patches around the mask ROM if you found an error.

It was, yeah, it was not for the faint of heart. So you shipped cartridges for in 64, like, games you worked on? Did I hear you right? I did not know that. What? Mortal Kombat Trojee. For the sake of our listeners, Mark and I have known each other for a little while here. So that's why I'm more getting surprised.

Mortal Kombat Trojee was the big one on Nintendo 64. That was a fun project. And then Mortal Kombat 3 on the PlayStation 1. And then I helped doing some tools, support on Doom and Final Doom for the PlayStation 1 and some other titles. Oh, nice. Dabbled with those. One other, I hate to harp on the bad old days. Multiple companies I worked at, for example, I worked at VersaCAD back in the day before we got crushed by Autodesk.

We would have an engineer whose sole job was to write the installers. So back in the days, you would have someone whose sole job would be making the install program for the PC to be able to unpack, you know, the multi-stack of floppies and put in all the, you know, TSRs that no one knows about these days and stuff like that to make a, program actually be able to be distributable. Oh yeah and then some guy had to make the thing to help you configure your sound card. No, what is your IRQ? What is your you're actually? Oh my goodness. I remember those. My professional life starts after source safe and and installers were available. We did not have to hand roll those things. Yeah. Well lots of war stories of shipping software in the early 80s for the early computers. There was a lot of infrastructure that

didn't exist that you had to create and everyone was creating it uniquely. I am still curious. What do you think about the evolution of C++ in all these years? I love it. It's gotten better and better. We stagnated horribly between 89 and 2011. It was a dying language. I had to deal with all of the Java people that were saying that that's the next great thing. And they were on a positive trajectory and C++ was on a flat line dipping down trajectory. So it was a very sad time. But C++11 really kind of shot it in the arm and created it. So some of my notes of the seminal things for C++, since you gave me some things to think about,

I already touched on a couple of them. You know, the C++ versus Objective C, the National Institute of Health Class Library versus STL, all of these were just foundational C++ finding its way. GCC1.37.1 was a very important point for me. It was on several processors reliably and it worked. C++11 was obviously added so much. a lot of issues. It gave, honestly, to me, new hope that it's in a live language and we're in a good

direction. Then the C++ committee setting kind of the cadence that we're going to do this every three years. We're going to start thinking about this. We're open to getting papers. There was a lot of energy. You have a clang starting to happen with LLVM. There's so many wonderful things. And we've marched forward on that. 11 was a big one. 14, 17, for me, less significant. 14 felt like the things we missed. 17 had some nice items. 20 started to get some things. And the things that are important to me probably aren't important to a lot of the world. But little things like source location and stack trace are so important to me. They as a systems programmer, they made my life so much better. And then some of the the syntactic sugar and stuff like that,

structured bindings, things like that are just wonderful things to be able to write more expressive and clean code, things like that. And these are all things that you're using in embedded development on your pinball. Absolutely. Subject to the hardware I have with the libraries and compiler that I can get on it.

Because on certain things like pinball platform, I have one platform we call, about Spike 2 that we shipped nine, 10 years ago, that kernel and compiler are kind of stuck in time because the cost value risk of moving that up doesn't buy me enough versus the, you know, I've shipped hundreds of thousands of titles on that known kernel and compiler. I'm hesitant to move it on that platform because it is ancient obsolete hardware. a couple years ago, last year or something like that, I launched Spike 3, which is much more modern.

Modern kernel, modern compiler, life is a lot better. So I can use features on that. But I have a common code base, so that adds more complexity as well to be able to pick and choose. But on the day job, 2014 is about the level I can support on both platforms. Okay.

And you're doing bare metal development? I'm sorry? Bare metal development? Do you have any operating? Okay, I do bare metal development, and that's, when I do bare metal on the pinball machine, I have 32K of flash, yeah, 32K of flash and like 4 and 8K of RAM. It's in C. I write my own CRT zero.

I don't have a standard library. I have to hand roll or cherry pick the GCC library routines. It's like, yeah, I guess I do need shifting by a 32 bit in this library. So it is a very curated experience on that. It is lean and mean, but it's true real time. I have an event loop that has to execute every 1280th of a second. And that's all in C plus plus as well. No, that's in C.

There's no way it's such an ancient processor. or even I can't tolerate the bloat that you might get of it trying to be more efficient and therefore increase code size. Even I have to freeze in time a version of GCC because I've had GCC go versions and suddenly the 68, not that these are 68K, but one product I was on 68K, suddenly the 68K co-generator just got terrible. made a choice and didn't think about it and suddenly code was twice as big. And I had to regress back to the previous version of the compiler because it's a dead

processor. No one mainline cares about it anymore. Right. And if you do OS, it's not going to help you that much, I suspect. Right, right. Yeah. I mean, just as an aside rant, they both have OS and OZ now, which OZ is supposed to be even smaller than OS. And I think in every single time I have tried OZ has produced a larger binary than OS. I do not understand why that flag exists. Yeah, I think I did that test as well. I use OS.

I don't remember having any success with OZ. Yeah. I tell students when it comes up, this means try even more harder to make it smaller. And yeah, anyhow. And one of my favorite hidden flags that I think I mentioned to you, Jason is make the dump of all the stack sizes at compile. Oh, yes. You know that that is.

And that's another one I live and die by is on my compiler line. I set my stack limit to 16K. And of course, I'm W error. So if I get more than a 16K stack, it's going to abort the build. Yeah, that's awesome. I think I did an episode about that after you told me about it at some point. Yeah. That's cool.

Is that per function? It is per function. And in my day job on the pinball machine, we used to limit, we do a cooperative multitasker, and we used to limit the stack frame in some cases down to hundreds of bytes, but we relaxed it up to 4K. Right, because you have to suspend and then go come back. Yeah, okay. And we have, in a pinball machine, we have, yeah, I don't know, 40, 6. 96 processes at any given time.

And they're all small and bite size. And they can be as trivial as a process that wakes up, turns a light on, sleeps for N ticks. A tick for me is 16 milliseconds, and then wakes back up and turns back on, back off, back on, back off because they're so cheap. And sometimes that's the easiest way to do it. And fun bit of history, why do we do 16 milliseconds? because we're back from the old days of the refresh rate of an TSC monitor, you know, 60 frames a second.

I mean, yeah, I mean, I work in video games. So obviously 16 milliseconds is not a random number at all to me. It's your target 60 FPS. Why 60 FPS? Especially because, you know, I mean, you're up, right? The first question you ask is why is it not 50 FPS? Because PAL monitor is a 50 FPS. But no, I think now every monitor is 60, targeting 60 or 120.

All right, battle days story, porting Mortal Kombat after you do the US version to the PAL version and making all of the logic and physics still work right, not pleasant. Yeah, I have a co-worker who likes retro consoles and he's trying to get something to run on an old, I think it's Apple. But the problem is he's trying to go by the biggest library you can find for it, which is all based on the American version. And because of the refresh rates, he has the same issue. He's been trying to look up a board on eBay for a while now.

And he says, I keep finding, like, European conversions or just European imports. And they just, they have been converted already to 60 to 50, to 50 hertz. And that completely breaks all the code he's trying to write because it's still like targeting the old like NTSC monitors. Because that's kind of all the things you can find online. Right, right. And these hardware is harder to combine Europe. And the hardware is dying. You got to replace the capacitors.

You got to do all sorts of things to bring these things back to life. Yeah, when you're watching a retro video and someone's like, I'm just going to plug this thing in. You're like, no. I want to give a shout out, Jason, though. The other thing that's exciting me in C++ today, and I hope someone funds them is Kalilo's exception handling. I am all in on exception. Yeah, yeah. And I love the work he's doing, and I hope it gets mainstreamed in some of the efficiencies he's talking about into, you know, client and GCC.

I'm a big, I use exceptions, and a lot of times I'm only throwing an int, and I really want that to be less expensive. Right now, it's way too expensive just to throw an int. Because for example, in my multi-processing and co-oper multitasking system, when you kill, you know, I, since it can be a C++ object, it has to get an exception thrown to it. So there's like a wrapping thunk

that will trigger the exceptions to do RAII cleanup on everything. So, and I only need an int for that to know why I died. So I did, I just made a note so that I'll try to remember to link to that for our listeners to Khalil Estelle's exception handling work that he's been doing for improving exception handling specifically targeting Arm with...

Yes, but I think it also works for 86. Because I think it's... If I recall correctly, it also works for like X86 System 5, like the 64-Bits API, basically. Yeah. Because I think it's the same concept of structural exceptions and whatnot. A lot of the work he's done is the framework

for Clang and GCC have a lot of methodologies that then are back-ended to each one of the processors, but showing how you can override the allocation of the frame for propagating the exception and things like that. So I really hope someone with some funding helps fund him at some point to get that mainstreamed, because that will help all of us. That would be great. Has he written something new since the last presentation I saw, which must have been ACCU of last year? No, there has not been any new presentations since then. Okay.

We've been going for a bit here, but I want to absolutely make sure that you tell us about the programming language you've been working on since that's been your main project lately. So I'm a firm believer, and you always have to have a passion project. That's not your day job, because that's a project where you take risks. That's where you learn. That's where you advance yourself as a software engineer because if you're not learning, you're rusting away, my humble opinion. So my day job, I work with C++14. I work on certain hardware platforms.

I work in certain frameworks, things like that. And I was looking through my list of projects I've done in the past and on my own that may or may not have been finished. And way back in 89, 90, I wrote a PostScript interpreter, the language, because I really liked that language and I wanted to use it as a scripting language in video games. I thought it would be perfect for the shell of a video game. This is before Lua. Loua didn't exist yet. And there are certain aspects of that language that are very interesting if you haven't ever programmed in postscript or understand it. It's very memory conservative.

The entire program never exists in memory. It's as if it's a stream, a paper tape coming in of text or binary that gets consumed into building a postscript object. And you only need one of those and then you activate on that object and then you do the next one and the next one. So the entire source of the program is never in memory. You'll get byproducts of the objects that are created from the post-exam. script text and then you can do interesting things with it. So I thought about that and I said, yeah, I should take another swing at that. So about four and a half, five years ago, I started from scratch and then I got a little bit of a way and I said, boy, post script is, you know, this, this is, it's got implicit conversions.

It's got this and the other. It's like, ah, I don't like that anymore. So I sat down and rethought about it and came up with a couple of things that I wanted. And a lot of them are from my holistic, 40 whatever years of programming, the things I liked from different parts in the world. I love prologue. I did some programs in prolog in the defense industry. I played with small talk, and there was aspects of that I'd like. There was all these functional languages and things like that.

So I started to imagine a scripting language that would encapsulate all the cherry-picked ideas I liked from different things. From Smalltalk, one of the things I liked is you can save a snapshot to disk and then restore later as if, you know, nothing ever happened. So I made a new, what I would say is the bones of what PostScript was about, but totally different. There's some elements of it that I built upon, but it's a type safe language. It's a memory type safe language. It has transactional bump out. allocation as well as a zone that's garbage collected, free store. I needed that. I'm a person that I've never done a garbage collector before until I wrote this and now I understand them and I appreciate

them. And I did a very deep dive on that and really optimize the heck out of it. But I needed a garbage collector for my prolog. I wanted to be able to do backtracking and things like that and be able to do it in a small memory footprint. So what I'm would say is there's a million things this language does and I'm selling it short go to the GitHub and take a look at it it's 100% there oh there was other things I wanted to challenge myself with it's a single header it's 90,000 lines of C++ code no no it's one header that you include and includes 68 files come on I'm not going to put it all in one file but it is you have no build system dependency. Because I'm a header that's writing on anyone's code, I have 45 different

warnings and stuff like that. So I compile clean no matter. I can't imagine someone being more pathological about the warnings than what I tried. I did everything possible. But you include the tricks.h header. And then in your C program, C++ program, you instantiate a tricks object. And now you have an entire VM and it's highly tunable. You have a whole block of parameters. How much memory is its VM space? Do you want to hand it a block and say how big it is? Do you want it to malic its block? That is the only malloc it will ever do is that one malloc. Stacks, everything else. Every possible parameter can be tuned on it. I can instantiate that tricks object. I can 10 of them if I wanted them in one program, and it is a compute engine. You can pass a script to it to have it execute. You could have it execute the script and then stay resident and get information from a pipe and get data back out. It can be a, you know, a compute engine that's sitting there all the time. One of the choices I did was it is type safe, but it also exposes everything about ICE,

IA754. So, and it has a RIMPL mode. You can interactively just do programming it on as well. And then you can snapshot and save everything you did and restore it later. But the IA754, every C++ supported standard library math function is there for 32-bit, 64-bit, including all the rounding modes, all the environment modes. So one of the things I also wanted it for is it's a rapid prototype for. doing formulas and floating point.

Instead of doing a edit, compile, execute cycle in C++, you could sort of do a mat lab type expressions and prototype rapidly on an interactive command line, commit your algorithm or your concept, and then write it in a real language, right? I tried to make the scripting language as efficient as possible. The scanner is very efficient. It does one character look ahead.

It only has to push back the character in one spot. The interpreter executes about 47 million op codes a second on my M2 Mac laptop under parallel, so it's losing a little bit of performance there. Very rich, other things I wanted to do because the environment I work in coin op industry, I'm not gonna say we have the best practices on everything because Jason you always bust me like you wrote a test

suite for that bug you found. It's like, well, no. So one of the things I did here is it's lipped fuzz and it'll stand up. I've run it for 24 hours on the scanner and the interpreter without it finding a problem. But I also have about 24,000 regression test suite now to run through on it on every major feature, every component. It's not at 1.0 yet just because I want other eyes on the ABI before I settle it down. I've got all one person who's forked it. So, you know, hopefully someone else will find this interesting. It's not for everything. It's a concatenative language. That turns everyone off immediately. Unless you like fourth or postscript, it's going to be alien speak. But some of the things I did to try and soften that is

you can do infix mathematics. You can go into, and it's all scanner syntactic sugar. It'll, you do a dollar sign and a print C's, and then everything in there could be, you know, A times five plus 12 divided by three. And the scanner is going to turn that into post-fix, shove it into a thing. And as it digests objects, it's now going to get them post-fix. So it doesn't know any difference. Zero cost. It's also the language has got the philosophy of zero cost. If you don't want to use a feature, it's not going to cost you anything.

But it also, you know, here's something that's kind of unique in a small memory footprint and a scripting language. It does the full Erlang, OTP, actor, supervisor model, multi-cooperative multitasking. It's got prologue backtracking engine. It's got reactive cells where you can link cells together like a spreadsheet and they'll fire. And all these are pay as you go. There's no cost to them. I think at the end of the day, personally satisfying, I got to explore C++23, got to learn garbage collection, how to actually implement a very efficient garbage collector.

I think there's a lot of things in the code base. Like I said, it's not small. It's 90,000 lines. I'd like to think it's well written. It's got a lot of things as a teaching tool for someone who wants to understand how to do things. as far as like basic compiler, memory systems, things like that. It's also, because I'm a bitmiser, it is very thrifty on its memory. It can run in a very small memory footprint.

Architectural choices that were made up front to make it trivial zero expense to do a snapshot. There's no pointers. Everything's a base offset, like the bad old days of Windows or DOS, where you had a base address and an offset. Now you can freeze at any time without any concern. So it's, you know, go look at the page. There's also a rich set of showcase applications demoing different parts of the technology.

Two of them that I put a lot of effort in. One is a full Z machine for the Infocom games to be able to play any, you know, infocom game written in the tricks scripting language for the whole interpreter. And then another one, I had a lot of, fund in with is a pretty much state-of-the-art maze generator. Just about anything I could think about to do to a 2D maze generator. It supports.

So if you go to the Read Me page for the GitHub, you'll see like four pretty pictures of some mazes the program generates. And those programs like the maze generator, I think, is like 9,000 lines of trick script. So it's not a, you know, trivial program. There's a lot to it. So it's a post-fix stack-based language, right? Yes, concatenive language that can be embedded into a C++ program as a compute engine. Now, what does the inter-off look like?

How easy or hard is it to expose a C-function to it or to get data back in it? Trivial. Trivial. You can add new operators to it, and there's a couple of the example programs. Like I have a Tetris written in it that runs, but if you want to do it. the AI playing Tetris. That math is a little heavy to do it real time. So those are those operators are written in C++ and exposed to the script to be able to run. Recently I added a full visibility the other way, a full 32-bit 64-bit big Indian little Indian dwarf reader. So it can now

read all of dwarf and you can say, I want you to have access to simply, to symbol foo and now it knows because I had written previously peak and poke to be able to map from virtual space to C++ space now I added the layer of dwarf so now you can do it symbolically wow okay so it can load binaries basically I can load binaries and do things one of the initial items I wrote this for and you'll like this matu for say you're in a video game before it got big and has a little bit of a footprint. But say we scale this tricks back down. It's a one of my original design goals

was a resident monitor that would live within a game or any program I'm in and suddenly, oh gosh, part of the program wedged. I'm never going to be able to reproduce it. So you fire up this little RIMPL scripting language that has access to the C++ memory. And I could write my own little, oh, geez, the memory I know is structured like this.

Let me take a look at that and dump it out. Oh, by the way, Tricks also supports records and tagged types and all sorts of things like that. So I was just thinking like, I still think the question of what is a good scripting language to marry with C++s is, I would argue still in open problems because else Game Studios would not stop trying to reinvent everything all the time. Like, I know Lua is a big one.

I tried to contribute to an open source project. They didn't pan out super great, but they were using JavaScript, which, yeah, unsurprisingly, a lot of their VM time was spent, like a lot of their logic was spent in running in script. I know different, I think, I don't know how blueprints in Unreal compiling to anything. On Unity, obviously, we use C Sharp that is then transparent

to C++, all that is run from Mono, depending on your platform. But yeah, I think it's still like, we're still trying to figure out what is the good way to have a scripting language that runs fast enough. I looked up at tricks, I think the syntax will, I don't know, because the main issue usually is that you want, like the reason you have a scripting language, whereas that's two-fold.

The first one is you want something that's fast to iterate, so ideally no edit, compile and restart time, depending on your engine and platform, the compile, all the restart time might be the issue. Some games restart fast. Some games takes like 10 minutes, not 10 minutes, but a couple minutes to load. I don't know how long it takes to link,

but it can be an issue. And the other one is usually the people who script are not programmers by trade. So they need to, and maybe it's kind of an unsolvable problem because you're asking non-programers to write efficient script that's going to run fast.

Maybe it is just by nature of the wrong question to ask. But I think there is still like a search for how do we, give these people something that is easy enough to understand if you don't have a CS background. And also, you're not going to make it run like 10-fPS. I think it's a solvable problem. And you're absolutely right.

The syntax of tricks is not for the faint of heart. And I acknowledge that unapologetically. And so one of the things is it was an exploration tool, but I do think it has value. And I hope some people look at it and use it. I did make it Apache 2.0. Use it for whatever you want. Just give, if you use it somewhere, I'd like, you know, a thank you somewhere. But it solved a lot of problems.

And there was a lot of, it could be a launching pad for me if I were to try and make a more palatable scripting language. Because there was a lot of problems that I had to solve mentally on to do the items I wanted. And some of that ended up making some of the syntax. that's not for the faint of heart. It's not as bad as APL, if any of you kids know what APL was. They used to have to be dedicated terminals to be able to use APL,

and the characters would over strike. It was really rough. So it has to be, it has prefixes and suffixes to be able to do things, to be able to manage the memory when I'm allocating an object if it goes into the save,

restore journal heap or does it go into the general purpose malloc garbage collected heap so you know you have the ability at any time to define if something's read only what memory store it goes into that's incredibly powerful but it comes out a cost of some syntax that might make you go uh so and jason you and your cousin and i talked five years ago about suffixes and that was for this to to be able to do things. So, and it's shipped in this, some of this. So it's a solvable thing. Are you familiar with the scripting language? I think it's Nottie Dog did called Gold, G-O-L-D. That was what all their games were written in by, and I think it was a LISP derivative scripting. Again, rapid iteration, interactive, you know, writing it as they're doing it might not be the most performant,

But it was pretty darn good. I never worked in it, but I've read about it. It compiled down to assembly. So it did a Jit type thing. I think it was Naughty Dog. It was one of those companies. Yeah. Well, to be fair to, I mean, you know, we're not, well, how do I want to say this?

We're not talking about the days of needing to hit 120 FPS or something like that. But you already just mentioned that you're, that you've got an inform interpreter. Yeah. And Inform is possibly the earliest example of a scripting engine for writing games, right? And then that inspired, I believe, at least indirectly, the scripting system that Sierra used in their AGS and SCI engines. And they had an incredibly successful company. They could write their games in the scripting engine and then easily port it to, like, 14 different platforms, right? So maybe it is a solved problem, but maybe it's not yet a solved problem when you care about writing a scripting language for a first-person shooter.

So that's an interesting point. And it's actually fascinating to me why Infocom and some of the other stuff was one of the natural first programs I wrote my scripting language is the only reason why I ever got into computers was in 76, 77. I got access to a bank, mainframe and played adventure and I wanted to discover how the heck this thing worked. And I taught myself programming and then got into computers. And I always had a dream because I loved Infocom games. Wouldn't it be great to work at Infocom? Lo and behold, I went to work for Activision and helped write the engine for return to Zork,

which was, it's got the name Infocom on it. It's not really an Infocom texture game, but whatever, it was close enough. But there was a article, um, and I, I, AAA computing about put a dungeon on your desktop, which was written by the founders of Infocom, the Z machine was the earliest, one of the earliest examples of a virtual machine that Java inherited that technology from.

It is a virtual machine in every sense of the word, like the modern thing that they wrote as a domain-specific thing to port their one megabyte ZIL, which was a Lisp like, language at MIT down to a 32K personal computer. It was one of the most elegant solutions ever. And then that's what became the Z machine on all the home computers. And that's what I ended up implementing a version of that Z machine in the Tricks language.

So they chose a Lisp type derivative for their language. When we did return to Zork, we did. an object-oriented Lisp language as well. So it's kind of there have been many scripting systems that you or programs that use a scripting system. And a lot of them have ended up being LISP or scheme or something like that because it's so essentially easy to implement. It might not be the easiest to program in or digest, but it is straightforward to implement

in a, you know, as an embedded scripting language. In a small, yeah. In a small footprint. And easy to parse, too. Very. Yeah, that was the point of one of the keynotes at ICCU, I believe, right? That, like, to implement the LISP, you have to implement, like, how is it, like, seven or ten, like, base, base functions? Yeah.

Yeah. Yeah. So, Jason, I got jealous of your ConstExper scheme. So in tricks, I implemented a mini scheme with call on CC and all of that as well. Yeah, that was, I mean, you know, you said that your language isn't yet ready for release, but, you know, I did release a 1.0. It is released. I just haven't called it 1.0 because I want peer feedback, you know. But it's ready to call it. It is production quality. those showcase programs are real.

They're not one-line things. They're 9,000 lines of doing things. That's a lot. We should wrap up the episode. I don't know if any closing thoughts from anyone. I had a stupid question. You mentioned postscripts several time. Is that the thing about printers?

Are I confusing that or something else? No, you're not confusing it. So PostScript is a imaging language, but it has a full touring. complete programming language lurking under it. Oh. Without all of the operators that, you know, stroke a path or fill a path, you have a full compute, you know, engine under there with, you know, data and control

structures. I took that and then ran with it into a modern kind of view. So again, sales pitch, read the read me if you're interested. Oh, also there's 60, 80. documents on implementation details and description of the language. So it's well documented, well tested, you know, things like that. Good examples. It's a fun thing. Again, everyone should write a passion project because that's how you learn and evolve. Yeah, no, absolutely. You give me some ID because I'm giving a talk at NDC Oslo, actually,

not Oslo, well, it's a careful slow, but tech town. And it's about how I learn a graphics programming, but I wanted to be right. I was not happy with the first rendition that I've done at a meetup. And yeah, I kind of started because I've like, oh, I've done some graphics, but I kind of had no idea what I was doing. I want to catch up. And I had time between clients. I just decided to write my own like rendering engine.

And I should have brought in both interviews. Yeah. There's a little Raycast demo in the demos program as well, doing it all with asking characters. So I got a question for you guys. Are you at your work desk? And if so, what books do you have on it? What books are at hand right now?

Oh, I literally got rid of all of my own. Okay. So my answer is I only have one book that is close to me. And it's the paperweight that's holding my project. So it can project on top of my PC. And that is now Shalec C++ software design by John Lakers. because I don't know if I have his blessing to use it as a paperweight now, but I know it's a book in the 90s.

I bought it after I met John because I was really interested in Holy Stocks about how you should structure a C++ project. I read it. I realized that it makes stuff like, oh, you should use classes to emulate namespace. And I was like, oh, that's a book written from the 90s. So it's been used as a paperweight since. That's the one C plus book I have closed by.

Sorry, John. I still like you work. So here's what I have hanging around because you can see what I've been working on. Oh, there you go. My small talk book. And here's a book if no one's discovered this. This came out 10 years ago. This is one of the greatest books on domain specific I've ever run into. So it's amazing for programs.

This thing is amazing. I did make a note to make sure that was in the list because I knew that that you told me that it inspired your examples. And just a quick aside, Matthew, I first became aware of the fact that PostScript was a touring-companied language, probably late 90s, because I remember that there was a Post-Script file that had gone around, that every time you printed it, it would print a different maze. Right.

Oh. Yeah, makes sense. I remember the main reason I know about Post-Crypt is because, when you were buying a printer in the early 2000s, you had to check. Every nerd on Linux told me, if it has a Post-Cupinterpreter, then it doesn't matter what driver you have.

You don't have to fight like CPL drivers and Windows or whatnot. Just plug it on your network and you're done. So I always remember that. I just, I have a printer somewhere that I've been in a box for like eight years since I moved because I don't need to print anything. But yeah, that's how I remember it.

But that makes sense. Since it's a programming language, you could actually use it to print something different each time. Yep. I was just trying to think, I was only going in my head, like, but you need a random seat, but I guess maybe it has a random. CooScript has a random number service in it, built- Okay. All right.

Thank you for coming on, Mark. This has been awesome. Yeah, of course. Well, as usual, right, we do not have a sponsor, but we are always looking for new guests to come and join us. We have a short list of people we would like to interview, but it's always nice to have more people who want to come and talk us about their hobby, their hot texts about C++ and anything related. We're always happy to talk to you.

As we mentioned earlier, you can find us on YouTube and your favorite podcast API. We are fixing the fact that they don't always read at the same time. Yeah, I think that's about it. So with that said, I guess see you next month. See you next month.