STEVE_EDWARDS: Hello from very cold and rainy, typical April, Portland.
CHARLES MAX_WOOD: We also have Dan Shapir.
DAN_SHAPPIR: Hi from a warm and sunny Tel Aviv.
STEVE_EDWARDS: Quit saying that. Makes me nuts.
DAN_SHAPPIR: What can I do? It's almost always warm and sunny in Tel Aviv.
STEVE_EDWARDS: I know.
CHARLES MAX_WOOD: I'm Charles Max Wood from Top End Devs. It's also warm and sunny here in Utah, but by the end of the week it won't be that anymore. Welcome to Utah Weather. We have a special guest this week and that is Thomas Randolph. Thomas, do you want to introduce yourself? Let people know why you're famous.
THOMAS_RANDOLPH: Sure. As you said, my name is Thomas Randolph. I'm not famous. Let's start with that.
STEVE_EDWARDS: Yeah. After this podcast, there'll be people clamoring for your autograph.
CHARLES MAX_WOOD: That's right. You'll be infamous. Yeah. There you go.
THOMAS_RANDOLPH: I would say my only real presence is kind of on Twitter. I interact casually with folks like Diane and other people. I work at GitLab, so you may have heard of GitLab. I come in from Denver where it's also kind of warm and sunny, although like Utah, the weather could change at any moment. So,
CHARLES MAX_WOOD: yep.
THOMAS_RANDOLPH: expecting maybe to have snow even this this month. So who knows?
STEVE_EDWARDS: Yeah, we already had snow here in Portland last week. We just had one here in Portland, closed all the schools and everything. You know, here they close if you get an eighth of an inch, but it was a lot of snow for one day. So yeah.
DAN_SHAPPIR: Yeah, that's another thing about Tel Aviv. It never snows in Tel Aviv. Actually, it did snow. I told that it snowed once in the 50s, but you know, since then.
THOMAS_RANDOLPH: Wow. Yeah, 70 years.
CHARLES MAX_WOOD: I remember when I lived in Italy, I was living in Tuscany and it didn't know what to do. So anyway. We're going to be talking about TC39 stuff and upcoming features for ECMA script.
Hey folks, this is Charles Max Wood from Top End Devs. And lately I've been working on actually building out Top End Devs. If you're interested, you can go to topendevs.com slash podcast, and you can actually hear a little bit more about my story about why I'm doing what I'm doing with Top End Devs, why I changed it from devchat.tv to Top End Devs. But what I really want to get into is that I have decided that I'm going to that I always wished I had with DevChat.tv and I renamed it to Top End Devs because I want to give you the resources that are gonna help you to build the career that you want. So whether you wanna be an influencer in tech, whether you want to go and just max out your salary and then go live a lifestyle with your family, your friends, or just traveling the world or whatever. I want to give you the resources that are going to help you do that. We're going to have career and leadership resources in there. And we're going to be giving you content on a regular basis to help you level up and max out your career. So go check it out at topendevs.com. If you sign up before my birthday, that's December 14th. If you sign up before my birthday, you can get 50% off the lifetime of your subscription. Once again, that's topendevs.com.
CHARLES MAX_WOOD: Thomas, do you kind of want to, you have this list that you kind of rounded up for us. Do you want to kind of tell us where this list came from? Like how you figured out what you were excited about or what was coming and then tell us, yeah, why you ranked them the way you ranked them. And then we can dive into the individual bits.
THOMAS_RANDOLPH: Yeah, that's great. So we're going to be talking, we'll talk about a bunch of proposals and I'll note the different, the various stages that they're in, cause that's been important to know like how likely it will be in the ECMAScript specification. So a bunch of the ones that I'm excited about are stage one, which is they aren't even sure it's going to, it's going to happen, but I'm interested in it.
CHARLES MAX_WOOD: Right. So where do we start then?
CHARLES MAX_WOOD: Defying used.
THOMAS_RANDOLPH: So, I mean, obviously constructing a date and just being like, what's the string for that date? That's not that painful, but as soon as you try to do any sort of math on it, like, oh, what's four months in the future, things get hairy things get pretty messy, especially if you're trying to do it between two people, right? Like a calendaring system. Like what, what is, what is this time and date on this other person's in insular person's time zone, for example, that stuff is, is hard.
CHARLES MAX_WOOD: Hold on. I'm having heart palpitations. My stress level is gone through the roof.
THOMAS_RANDOLPH: Exactly. And there's, there's, there's like no built in way to add, right? Like just add a month to this and this just, it just doesn't exist. You could do something naively and add a bunch of milliseconds to the underlying value of a date, but that's, it's, you're getting into really bad territory.
DAN_SHAPPIR: I too have encountered many, many projects that bundled Moment.js and a big issue with that is that Moment tended to be fairly large. And also the fact that I've actually seen projects that for various NPM issues bundled three different versions of Moment. So like 80% of the projects download was actually just Moment.js. which is pretty unfortunate.
THOMAS_RANDOLPH: Yeah. And I mean, Moment doesn't even ship by default with useful time zone handling. Of course, your browser can handle your own local time zone pretty easily. But if you need to do translation across time zones, even Moment ships that as a separate library because it's such a huge amount of data. There's so many little tweaks here and there and like, oh, we skipped a month in one year, 120 years ago. And like you just have to have that encoded somewhere and that data is a separate download. So any project that needs to do any sort of interesting date time manipulation is shipping one of those libraries we talked about like moment or date functions or some of the moment contributors or creators created a library called Luxon which shares a lot of Interesting DNA with moment, but it is it creates immutable objects Whereas moment is always mutating its own objects Which can sometimes be pretty tricky because sometimes you want to add something to a date and have a new date not change the original one. But all those, all that work was done to paper over this frankly, pretty bad date implementation that's that we've kind of been stuck with. And temporal is, is how we're fixing that or how I say where, but I really have to give huge props to the people who've been working on this for years, Maggie Pint and, and Matt Johnson, Ryan Cholson, and like, there's a, there's a long list of contributors to this, this proposal, but I mean, they've done amazing work and it's to the, like, The complexity of this is to the point where they are actually, they actually need to change the standard ISO 8601 format because while the standard date time format that you're used to is good, it doesn't include things like different calendars. So it assumes the standard Gregorian calendar that we all use, but there are other calendars around the world in different religions and different people groups that use different calendaring systems. And that kind of string permanence doesn't encapsulate that.
STEVE_EDWARDS: So do you know, does it include like the star date calendar from star trek?
THOMAS_RANDOLPH: Well, I don't know that it does by default. I think that the beauty of this proposal is that you can kind of, you can put any calendar you want in. I think I'm a little out on the limb there because I'm not a hundred percent sure, but I think you can say use X calendar, use this other calendar. And maybe they have to be built in, but maybe you could provide your own too.
CHARLES MAX_WOOD: So one thing that I'm wondering is, is what we've seen with some of these other proposals is that the proposal looks a lot like something else that's already out there, right? It doesn't, it does, doesn't adopt all of it all the time, but pieces of it. So how, how does this compare to moment or something else? Right?
THOMAS_RANDOLPH: I think if you will first say that that moment is a huge step forward off of the built-in date object, but incremental, right? So you still have kind of a single object that you're doing, adding, subtracting, diffing on those sorts of things. And it's basically a, a quote unquote moment object, whatever that is. Temporal introduces a bunch of new strong types. So you no longer just have a date type, you have a zoned date time or a plane time or a plane month day, which doesn't have any time, just the month and the day. So there are all these new types that are introduced. So it does look a little bit different from Moment in that way, but if you're familiar with, or if you're a fan of Moment's API, where it just has the.add or.subtract, those things are in the temporal proposal. So when you need to do kind of the typical web application math arithmetic, it's there. It's built in. And that's, I think that's probably the part that will look most like moment.
CHARLES MAX_WOOD: Makes sense.
DAN_SHAPPIR: I, it's a shame that AJ wasn't able to join us because I, as I recall, he actually implemented the library on top of temporal because he had, even with temporal, he ran into some challenges doing time zone math in some cases and he tried to make it simpler than the built-in functionality. But be that as it may, it's my understanding, I'm looking at the spec, I see that it's stage three, which means it's highly likely to be accepted. And I understand there's already support for it, some support for it out there. What's the situation with it?
DAN_SHAPPIR: I think I actually confused myself between temporal and the internationalization functionality, which is already baked into browsers and is also a huge step forward in terms of the ability to support various locales and stuff like that.
THOMAS_RANDOLPH: Absolutely. Yeah. And actually the library that I mentioned earlier, Luxon, which was sort of an offshoot of Moment, uses the internationalization API to avoid having to ship time zone information because using internationalization, I think helps you with most of that kind of stuff, which I think is why Temporal doesn't have to ship its own sort of localization internationalization information because it can rely on the internationalization API, which to answer your question about what's the support for that internationalization is well supported across most ever room browsers. So that's, that's an API that you can rely on. And if, if that's what you're talking about with AJ building something on top of it. I totally understand. I've used the Internationalization API. It is close to the metal. It's not easy to use. So if you are trying to make that easier, I get that.
DAN_SHAPPIR: I guess it also has some potential performance issues due to the way in which it works and reaches out to the operating system and stuff like that.
THOMAS_RANDOLPH: I've heard that. Yeah, that sounds plausible to me.
DAN_SHAPPIR: Cool. Anything else to say about the temporal proposal?
CHARLES MAX_WOOD: Are you ready, Steve? It's about damn time. Perfect.
THOMAS_RANDOLPH: I think it is about about damn time. And I'm really excited for this one to get in. It's a big change. Like we were talking about earlier and I'm sure the browser vendors have a lot of things on their plates to get this in. Man, it'll be, it'll be good when it does.
CHARLES MAX_WOOD: Yeah. Life will be good. Yeah. Cause that, that is probably one of the more painful things that they hadn't addressed.
THOMAS_RANDOLPH: I mean, at the very least, like if you're still including moment and you get the latest moment version moment can just be a thin wrapper around this browser API and you're shipping one kilobyte instead of 40 kilobytes or whatever it is. So that'll be a big improvement.
DAN_SHAPPIR: And like you said, there are polyfills for it already, which will make it safe to use. And between you and I, it's getting to the point where it's pretty quickly safe to use modern APIs in any event because of all the evergreen browsers and the fact that you know with Node, you're usually just running the latest version anyway. So even the polyfills are often not as needed as they used to be.
THOMAS_RANDOLPH: Yeah, and a well-designed polyfill will...just not even load itself if the API is there. So I mean, it's almost free upgrades if you do it carefully.
CHARLES MAX_WOOD: Cool, well let's move on to whatever's next.
THOMAS_RANDOLPH: I think a lot of people use JSON as a sort of a portable format. And so rather than requiring a networkless, like let's say you're running a Rails application, right? And a bunch of-
CHARLES MAX_WOOD: I love Rails applications. Sorry.
DAN_SHAPPIR: I think that another motivation has to do with the fact that, like you said, certain resources are so core to the operation of the application that the application is really kind of meaningless without them, and it's preferable to be declarative about their use and basically obtain them upfront. So for example, if I have a certain configuration, like you said, determines how the application actually behaves, then maybe without that configuration, the application can't really run. So by specifying it as an import, I see upfront that this configuration is actually used. And if that configuration load fails, then the application actually fails to load because the way that static imports actually work is that they all need to succeed for the application to actually load. If one of them fails, the application effectively fails to load. That being said, you can use dynamic import which effectively do become an alternative syntax to an extent to actually doing a fetch plus JSON.
THOMAS_RANDOLPH: Yes. And I think what you said about the kind of the declarative nature of like that config scenario and then importing them is really critical. We can do a lot of things in code. And in my opinion, it's always better to do them in a more explicit way. Like if it's just an import statement at the top, we know that that's part of the dependency tree of our application. And if it's just some function call or something in the start up of our application, that kind of implies that it's a little less important. And I think making it an import is a really great signifier that like, this is something that our application depends on, config or whatever it is.
DAN_SHAPPIR: So basically I think we covered both points number two, which was the import assertions, as you said, which is stage three, I believe. And also JSON modules, which I guess, yes, it's also stage three. And like you said, they kind of go hand in hand. You said that they originally were like one spec and then got split in two.
DAN_SHAPPIR: Do you think it'll be primarily used for this purpose or simply as a means to load resources that are not yet part of the spec. So for example, I could theoretically create a YAML parser and then import the YAML file or something like that.
DAN_SHAPPIR: Cool. So let's move on to the next one, which I think is built-in modules or did I skip one accidentally?
THOMAS_RANDOLPH: No, that's right. Yeah, we kind of skipped JSON modules, but we've already talked about that pretty in depth. So yeah, that's built-in modules is the next big one. And this, unfortunately, this one is a stage one. And if you, I assume that you talked about it in the JS Jabber episode about the proposal process. I feel like I probably would have heard that in the 400s, but I don't recall it. So, um, go back and listen. Yeah, I need to, I missed it.
CHARLES MAX_WOOD: And for the listener, we'll put a link in the show notes too, so that you can go back and listen and go, Oh, when he says stage four, what is it? Right.
DAN_SHAPPIR: So, yeah, yeah, basically stage one is like, is like somebody expresses an interest in it more or less within the committee. That's more or less what it means, but not much more than that. Yeah. Yep.
THOMAS_RANDOLPH: There's a committee champion and that's about it.
So I'm here with JD from Raygun. JD, when I talk to you, I mean, I really feel the developer vibe and I know that's your background, but is all of Raygun that way? I mean, you know, it just kind of feels like when I talk to other companies, they're a little more corporate, a little more, you know, focused on maybe, you know, raising money or doing other things, you know, but it seems like when I talk to you, you're just, you know, down to earth developer dude. I like to think of myself as a down to earth developer dude. Yeah. Yeah. Right. Raygun is a little bit different. So you know, we're not heavily VC backed. Um, you know, my business partner and I, when we started, we were both nerds. You know, um, I might be the CEO today and I don't write code on the product. Um, but you know, the joke internally is, you know, what's the definition of technical debt Chuck, it's CEO code. Stuff to go with. But, uh, no, we're, we're, we're. Stories. We're a cashflow positive business, you know, we're not heavily VC funded, you know, but we are at a size now where we are expanding and more and more folks are discovering what we're about. But yeah, we often look through things through that lens of a developer, you know, I wanted a 30,000 foot view, but I also want to go right down to an individual data point. Similarly, you know, I don't believe in averages, I want medians, I want P99s, I make better decisions that way. And so we try and drive that sort of thinking into our products and try and be as developer minded as we possibly can be. Yeah. I love that because, you know, for me it's, it's run by people who get me, um, and you're not under pressure from like a VC to raise your prices or, you know, go hyper grow and then, Oh crap, now we're behind the eight ball with our money and now we've got to figure it out. You know, you're just going to keep growing steadily moving. And I just love that. Yeah. I mean, The term these days is often referred to as product lead growth, right? Like get people use the product and say, hey, that's great. I want to give you money. Um, I don't think it's that complicated. Sounds good. Well, folks, if you want to go check it out, you can go find them at raygun.com. You can actually sign up for a free trial right there on the website.
CHRLES: Yeah, one other thing that, or a couple of thoughts that I have on this. So one is, one thing I've seen with my experience in Ruby and other languages that have standard libraries is once they have the standard library and they start shipping it, then what happens is the core teams actually tend to start to optimize them. And so then you start getting speed ups and size reductions and stuff like that on those libraries because now they're getting attention from people who look at it from the other end. And so I see that as a huge benefit. The flip side is, and this is the only downside I've ever seen to standard libraries, and the workarounds are really not that big a deal, is that they tend to lock in, right? So if you are using this version of the language or this version of the VM, right? So you do node 14 or node 16 or whatever, right? It'll lock in the version of the standard library package that you're getting, right? And so it may lock in the CSV library. Let's say they put that in there. Add a particular version. And so if you want the new features, you actually have to go pull it in yourself, right?
DAN_SHAPPIR: Oh yeah, for sure. Like the problem with standards is like once they enforce it's much harder to change them and you're kind of stuck with whatever that decision was that was made, which emphasizes the need to be really careful about what goes in or not into a standard library. By the way, another benefit of a standard library is one that is related to stuff that we've talked about in recent episodes, our supply chain security. Because again, if it's part of a standard library, you can pretty much assume that it's been vetted and is safe compared to some of the libraries that people are now downloading from NPM. We've had people on the show talking about some scary story about things that you could accidentally import into your project.
THOMAS_RANDOLPH: Right. And to both of your points, I mean, about not only optimization, but, you know, supply chain improvements, if it's part of the standard library vendors, whether it's a browser vendor or some VM, like, like Dino or node, they are, they're going to be implementing that's part of that standard library, most likely in a system level language, like C++.
CHARLES MAX_WOOD: Yeah.
THOMAS_RANDOLPH: if your browser is doing it. So not only will it be faster, but it's also like, this is running outside of your browser environment. And that comes with its own inherent risks, obviously, it can be insecure. But a browser vendor is way more likely to make sure that the code that they write that is running on devices is probably going to be safe and a lot faster. So I think there's huge upsides to moving these common things into standard library.
CHARLES MAX_WOOD: Yeah, the other thing is the ECMAScript, like you said, the ECMAScript process is slow. I mean, there's a reason for that, right? It's, yeah. But the flip side is, is that, yeah, if it makes sense to put it into the standard, the vetting process can go a lot faster.
CHARLES MAX_WOOD: Yep.
DAN_SHAPPIR: I would also like to mention that some of the items that we will mention later that I saw in your list, you might say that they're kind of dependent on the built-in modules. I mean, you could make them globals, like, you know, when BigInt was introduced, they made the BigInt constructor effectively global. And I guess it does make sense to make certain really common things global like that. But a lot of the other things that we talk about are like...something that you might decide to opt in or not. And once something is optional, why have it kind of add noise to your global namespace if you don't even intend to use it? And you're always, like you said previously, you're always running risk of collisions with stuff like that. So having these sort of things as being part of the standard library and importing them into the modules that actually need them and use them makes things that are make things a whole lot cleaner and more tidy, less messy.
THOMAS_RANDOLPH: Yeah. And actually, exactly to your point of running into collisions, the proposal for this built-in module system actually explicitly says anything that you import from the built-in module system would have a frozen prototype. So we can't get things like smooshgate or how we have includes instead of contains for arrays, because various other tools have already extended the array prototype to have those kind of things commonly used words, which makes sense, of course. Like people wanted to use them back before they existed, but now we can't make changes to the language because it conflicts with those libraries. So the standard built-in library would kind of protect against that future collision possibly, not only by namespacing it, but also by sort of locking down the modules so that they can't be artificially extended.
DAN_SHAPPIR: Cool. So what's the next one?
CHARLES MAX_WOOD: Can I address that for a second?
DAN_SHAPPIR: No, go for it. And also, Thomas, I just tend to get carried away with...
CHARLES MAX_WOOD: No, it's all good. So I have the benefit of talking to people in a lot of different communities. And RxJS is actually core to Angular and how it does change detection, among other things. And so having it part of the standard library, having some of the benefits that come with that. Or having it built into the language would really help people in that arena. And I do see people use it in other places, but yeah, they're usually more explicitly pulling it in or pulling something in that it pretty directly lets you know that it's working off of observables instead of the other way around. And so yeah, it's popular, but I think there's a wider swath of people that are using it than you think.
THOMAS_RANDOLPH: I actually didn't know that Angular was relying on observables or Rx. That's pretty interesting. My use case for observables, and Dan, I want to get your opinion on something you said, but my use case for observables is sort of in that same scope, in the same scope of the framework level. I'm architecting my entire applications, at least the ones that I have architectural control over them, as sort of message streaming architectures where individual components are responding to events that occur and not explicitly bound to other pieces of the application. And that's probably roughly how Angular does it at a very high level.
CHARLES MAX_WOOD: Yeah, more or less.
THOMAS_RANDOLPH: But Dan, you know, Dan, you said, you said that there's, you know, there's a reason that it's not super widely used and I want to get your opinion on, on what you think that reason is or reasons.
DAN_SHAPPIR: Yeah. So interestingly, also at Next Insurance, where I currently work, some of our main applications are Angular applications and also rely heavily on RxJS, which shows both the benefits and also some of the limitations of this approach. From my perspective, the main issue that I see with it is that it requires a significant level of expertise to be able to properly leverage it. If you're not quite an RxJS expert, it can get really Harry and Dicey to work with RXJS code. It becomes almost like magic. It's very difficult to follow the logic. And even people familiar with the applications sometimes have a hard time grasping the total image of where the data flows. Because it's so easy to subscribe to something and then effectively you've created another stream or routes that the data can flow down. And it's really difficult. So something happens, it's observed, and it impacts all over the application. And it's almost like magic. It becomes really difficult to be cognizant of all the things that might be impacted by that change. And related to that is the fact that it's really difficult to debug. You effectively cannot single step through that data flow you will usually, if you look at the call stack, it's totally legible. So you need to know where the data flows to, and then maybe put a break point there. But again, it can be really difficult to, if you're not sufficiently familiar with the architecture of the application, or all the implementation details to know where all the places are, so you can get really unexpected kind of side effects from the fact that that data changes. Think about it like a really complicated Excel spreadsheet where a lot of the cells are kind of dependent, interdependent, and you put just, change just one value and all of a sudden, like half the spreadsheet changes and it's really difficult to understand exactly why that happened. But again, I'm not opposed to this method of operation. Like you personally, I actually like it, but I'm simply not sure that it needs to be a core part of the language. I understand that proponents of RxJS, for example, actually hope that by making it core, more people will start using it. But if you're just looking at it in the context of Angular, like you said, Chuck, then if I'm importing Angular, then I might as well also import RxJS. It doesn't make that much of a difference.
THOMAS_RANDOLPH: I think one of the benefits of making it a primitive in the language is from my read. So first I want to say, I would never claim to be an observable expert. It is, I like it just like you, Dan, but it is so hard that it's difficult to understand. But even my read of the proposal has simplified my understanding of the high level concept just from reading the proposal because it is so much simpler on its surface when it becomes a primitive. It has a subscriber and the subscriber returns an unsubscriber and that's kind of the...the basic behavior there. And then an observer has a next, every time you receive a value, you get the next thing, and then an error and a complete handler. And that's it, that's the whole thing. And obviously, obviously, there's so much complexity buried under that. It's hidden under the hood. But from just reading the proposal, to me, it seems like it could simplify the concept substantially. And maybe there are, maybe RxJS continues to be a library that builds on top of that primitive with much more complex ideas. But...If you want just, I just want one way to stream data. Maybe you can just use the base observable implementation and it's much simpler. And maybe that could be the entry point for people to say, ah, this is actually a great way to receive events, react to things happening rather than, you know, expect things to happen explicitly. And they could do it with that much simpler primitive. Now, I could be wrong that it's simpler. It seems simpler to me, but...
DAN_SHAPPIR: But the best one doesn't can't really win because like you said before, once it's in the standard, it can never actually be removed. So essentially your, you keep on adding more and more layers. And while I'm kind of in the same camp camp as you are, I do appreciate what, you know, the minimalist stance that AJ has, for example that you shouldn't add something into the language unless A, it's very much in line with what the language already is, and B, there's a high probability that it's really going, that it's useful and will be used properly. And I'm on the fence with observables. Let's put it this way.
Hi, this is Charles Max Wood from Top End Devs, and lately I've been coaching some people on starting some podcasts and in some cases, just taking their career to the next level. You know, whether you're beginner going to intermediate and immediate going to advanced, whether you're trying to get noticed in the community or go freelance. I've been helping these folks figure out how to get in front of people, how to build relationships and how to build their careers and max out and just go to the next level. So if you're interested in talking to me and having me help you go to the next level go to topendevs.com slash coaching. I will give you a one hour free session where we can figure out what you're trying to do, where you're trying to go, and figure out what the next steps are. And then from there we can figure out how to get you to the place you wanna go. So once again, that's topendevs.com slash coaching.
DAN_SHAPPIR: Chuck, wanna do picks?
CHARLES MAX_WOOD: All right, well, I was gonna say, I think we're overdue for picks, so.
THOMAS_RANDOLPH: I think so.
CHARLES MAX_WOOD: Anyway, this has been really terrific. We are definitely going to be splitting it into two episodes.
THOMAS_RANDOLPH: But, oh, it's been terrific. I love talking with y'all.
CHARLES MAX_WOOD: All right. Well, let's, let's make Steve go first. He's been quiet for a little bit.
STEVE_EDWARDS: So we'll start, actually we'll start at an end with the high point of any of these podcast episodes, which are the dad jokes. So the other day I went to see my doctor and he told me that I was really growing as a person, but what he really said was you've gained a bunch of excess weight.
DAN_SHAPPIR: Yeah, highly expected.
STEVE_EDWARDS: Yeah. Yeah. Speaking of doctors, I know a surgeon that actually puts organs in. He puts organs back in upside down. I said, that's not funny, but he's just said it was an inside joke. And then, um, I saw a new story recently where a store clerk had fought off an armed robber with a pricing gun. So the police are now looking for a man with a price on his head.
THOMAS_RANDOLPH: I like that one.
STEVE_EDWARDS: That was sort of a takeoff if anybody knows Stephen right. He has a classic joke about a crazy lady that lived in his apartment building who tried to hold up a department store with a pricing gun. And she said, give me all your money on Mark down everything in the store.
DAN_SHAPPIR: That's a good one. Actually,
CHARLES MAX_WOOD: you know, Steve, I have a friend who tried to put together a dating app for chickens, but it was really hard for him to get hence meat.
STEVE_EDWARDS: All right. Thank you. Thank you. Thank you very much.
CHARLES MAX_WOOD: Do you have any actual picks or should we move on?
STEVE_EDWARDS: I guess if those aren't actual picks and no, I don't have any actual picks.
CHARLES MAX_WOOD: Well, just things that anyway,
STEVE_EDWARDS: um, I will, I will say one, and this is probably going to be a little contentious, but as of today, yesterday was the day that the federal judge rescinded the Biden mask mandate on airlines and for travel. So hallelujah. Amen. And everything else
CHARLES MAX_WOOD: that makes flying more pleasant. All right, Dan, what are your picks?
DAN_SHAPPIR: Okay, I have a few. So my first pick is I'm watching Star Trek Picard and I'm enjoying it. It's a nice little show. It's not amazing. You know, that's the interesting thing about Star Trek for me. The premise is always much greater than the actual execution. I always expect to enjoy the various series much more than I actually do. But there's one particular thing that I especially do like about Star Trek Picard and I think that's a pretty obvious thing and that thing is Sir Patrick Stewart. He is such an amazing actor. It's astounding to see how much of a better actor he is than everybody else on the cast. It's such a pleasure to watch him act. I would literally just watch him read stuff. I don't even need the, the, the, the, the, all, all the things with the spaceships and stuff, you know, just watching him on screen, especially reprising that role. He's just amazing. And I, and I love, and I love it for just for that. So that's. Yeah.
STEVE_EDWARDS: He could read the dictionary.
DAN_SHAPPIR: Exactly. He's such an amazing actor.
STEVE_EDWARDS: So my wife's a real big fan of that too. She really looks forward to all the card episodes and she's trying to get me into watching it, but I haven't broken down.
CHARLES MAX_WOOD: All right. I'm gonna throw out some picks as well. So you mentioned Sir Patrick Stewart and one of my favorite things that he's read is, and I got this on Audible, it was the Chronicles of Narnia and they had different actors and actresses reading the different books. And Sir Patrick Stewart reads the last battle, which is the final book. And he did a tremendous job. A lot of the other narrators are great too, but I'm just going to pile on cause I've enjoyed that. For me, the best part of Star Trek Picard now I've only seen the first season. I haven't seen the second season yet. The best part of that was just seeing all the other old characters and actors and actresses come back, right? Cause that, that was just fun. They kept all the callbacks to the old series. For my board game pick this week, I'm actually gonna do something a little bit different. This is something I do with my kids. It has board games on it, like Battleship or Reverse or some of these others. It works through the text message function on your phone. It only works on my iPhone. I don't know if it runs on Android or not, but it's called Game Pigeon, and you can actually text somebody a game, and then when you take turns, it texts you back and forth. And so anyway, it's a lot of fun. And it's a fun way to play some board games with my kids. And so, yeah, I tend to play it with my 13-year-old and 15-year-old are the ones that are really into it. So anyway, so that's gonna be my board game pick. It's a little bit different, but anyway. So I'm gonna shout out about that. And then I'm just trying to think here. There's just so much going on right now. Yeah, I don't know if I have anything else right off the top of my head. So we'll go ahead and let Thomas go. Thomas, what picks do you have?
THOMAS_RANDOLPH: I've got a bunch, but I will, I'll limit to my top three, uh, with one bonus, which is plus one to kind of remembering what's going on in Ukraine. As of today, I know this will come out much later, but as of today, I think the fighting has picked up pretty badly in the Eastern Donbass region again, which is, which is troubling. So yeah, keeping that in our minds. Um, I'll also pick my notes for this, for this episode or these episodes. I...have tons of links to all the proposals. I have links to prior art. I have links to code examples. And so those are all published live. And that can be sort of a resource here in addition to the picks that I don't say out loud. I have this book that has kind of been stuck in my brain for a really long time. It's actually a really old book with a few updates for more modern times. It's called The Design of Everyday Things by Don Norman. I think it's not really about programming, although I think it can be really important to read for developers because it kind of helps you understand the phrase. You might hear phrases like affordances or signifiers or those kinds of things. Those come from essentially this book. It's how we design things that people can use. I think it's a really kind of seminal book on how design works. And I think it's really important thing. So I'll pick that book. And then...My last one is I found an article that gave a really great overview of what reactive programming is. It's sort of my passion's architecture of programming. So I'll link to this article called What is Reactive Programming by Kevin Weber. It's on a blog from a company. I think it's a really great overview of reactive programming and why it's such an important paradigm in modern development. Yeah, there's lots more links in this and I'll shout out Dan's...pipeline stuff that he wrote. I've linked those as well. So that's it for me.
CHARLES MAX_WOOD: All right. If people want to connect with you online, I think you mentioned that you're on Twitter.
THOMAS_RANDOLPH: That's right. Yeah. Do you want to let people know where to...
DAN_SHAPPIR: I think, and by the way, I have to say that definitely worth the follow. So if...
THOMAS_RANDOLPH: Well, thanks, Dan. That actually means a ton. Thank you. Thank you for saying that.
DAN_SHAPPIR: Oh, for sure. I call it as I see it. Yeah.
THOMAS_RANDOLPH: Okay. Great. Yeah. My Twitter account is rockrist. R-O-C-K-E-R-E-S-T. And I will say that's kind of Twitter's, I think this might be a paraphrase of AJ, Twitter's where you go to like have hot takes and be divisive. So I have a stance on Twitter and it's for certain things. So give me a follow and see what you think and I won't be offended if you unfollow me. But that's probably the best place to see my sort of daily thoughts. My sort of the canonical place to find me is my main website, which is just rdl.ph, which is my last name without most of the letters. RDL.ph is sort of my landing page. But yeah, find me on Twitter at rockrest, R-O-C-K-E-R-E-S-T. And I look forward to interacting with you all about how wrong I was that these are the best proposals for TC39.
CHARLES MAX_WOOD: Sounds good. All right. Thank you so much, everybody. Wrap it up here and until next time folks, Max out.
Bandwidth for this segment is provided by Cashfly, the world's fastest CDN. Deliver your content fast with Cashfly. Visit. c-a-c-h-e-f-l-y dot com to learn more.