TC39: How the JavaScript Sausage Gets Made with Mark Cohen

[EPISODE]

[00:00:10] T: Hey everybody, and welcome to Enjoy the Vue. I'm Tessa, and today, on our panel we have Ari.

[00:00:16] Ar: Hello.

[00:00:19] T: Alex.

[00:00:20] Al: Hello.

[00:00:23] T: Special guest panelist, Oscar Spencer.

[00:00:27] OS: Hello.

[00:00:29] T: And last but not the least, our special guest for this episode is Mark Cohen.

[00:00:34] MC: Hello.

[00:00:35] T: Hi, who are you? Do you want to tell us a bit about yourself?

[00:00:38] MC: Sure. So, my name is Mark Cohen. I'm a software engineer. I guess I'd kind of class myself as a generalist. But I've spent a lot of time working on web development and related things. I have a special affinity for programming languages, specifically, designing them and implementing them. And so early in my career, I kind of stumbled backwards into TC39, working on designing and implementing JavaScript, which is I guess why I'm here today.

[00:01:11] T: So, TC39 is the shadowy group that makes JavaScript.

[00:01:16] MC: Shadowy, indeed.

[00:01:18] T: Yeah. I mean, is that where you all imagined the language came from? Like, where do you think JavaScript came from? How does it keep on getting new thing?

[00:01:27] Ar: Lots of cocaine? Sorry.

[00:01:34] MC: I think in the olden days, you're probably not wrong.

[00:01:39] T: I think it's pronounced Lacroix cane.

[00:01:42] MC: Oh, my gosh. Yeah, little known fact JavaScript is actually a legume that grows in the ground.

[00:01:49] Ar: Today, I learned.

[00:01:51] Al: Harvesting the fresh crop of JavaScript every year.

[00:01:57] MC: Yeah, exactly.

[00:02:00] Ar: Mental images are amazing.

[00:02:02] T: I mean, that explains why it's coffee scripts, and also from Java – I see it.

[00:02:11] MC: The committee is actually older than me, which was weird. On my first plenary, there was like we did intros going around the table. And one of the delegates said he had been on the committee since the year I was born. I won't divulge on this podcast, but that was a strange experience.

[00:02:30] T: So, I guess JavaScript isn't the only legume in the room. We also have this young whippersnapper over here. Okay, yeah, I guess, what is TC39? Well, what does TC even stand for and the 39? I mean, it's not 39 years old, right? Because the number doesn't get bigger.

[00:02:50] MC: Okay, so it stands for Technical Committee 39. So, TC39, well, I guess the 39 is just arbitrary. It was the 39th technical committee created under Ecma International. So, TC39 lives within Ecma International, which is a standards body that works on a lot of different things, actually. So, for example, a lot of the Ecma member companies are printer manufacturers from like the ‘70s and ‘80s. They were working on like interoperable printer standards. Related fun fact, Ecma stands for, well, used to stand for European Computer Manufacturers Association. 

Now, it's just kind of an acronym like they uncapitalized the whole thing. So, it's just the word Ecma, because sounds cool. I don't know. But yeah, so the purpose of Ecma and sort of, I guess, half the purpose of TC39 is to facilitate like international IP law issues. There are a lot of companies on the committee that like care a lot about that stuff. It's important to have those problems solved for us so that they don't intrude on committee time, like you don't have people, asking to call their lawyers before they approve a proposal or something like that, which those issues very rarely crop up during committee time. I mean, it's usually around like meta stuff. But that's sort of the purpose of Ecma and where TC39 lives in the world.

[00:04:25] T: So, why is it called ECMAScript and not TC39 script? This Ecma is like the larger group and then TC39 actually does the like JavaScript?

[00:04:34] MC: Yeah, I don't know why they chose ECMAScript specifically. But I do know that the reason it's ECMAScript and not JavaScript is that is actually that Oracle won't let us use the Java trademark.

[00:04:47] T: I mean, there's some irony about a group of like people protecting the IP law and not being able to use something. 

[00:04:58] MC: Yeah, yeah, exactly. Extra ironic, because Oracle is actually on TC39. They have a delegation.

[00:05:06] T: That's great.

[00:05:07] MC: Yeah. And funnily enough, nobody on the committee actually calls it ECMAScript. I guess, besides the places where it's labeled that on the website, like, we're not sitting in plenary discussing ECMAScript with one another. Everyone just says JavaScript.

[00:05:25] T: Not even like yes, next, or whatever?

[00:05:27] MC: Oh, yeah. I mean, I guess people do say, like, ES 2021, or whatever. But we're not like, sitting around talking about, “Oh, what's next for ECMAScript? Do we really want to see this feature included in ECMAScript?” It’s kind of funny that it's only the public facing references have to be sanitized.

[00:05:52] T: Basic question. What is plenary? I thought it was like that thing that you use on like a Ouija board, the little pointer.

[00:06:02] MC: Yeah, plenary is the meeting that is held regularly, the interval is currently under some change. But like roughly every two months, where the committee gathers to discuss the various proposals that are being worked on. And I guess, debate them, and decide whether they're ready to advance to the next stage. That's the primary purpose of plenary is to decide on stage advancement. And the reason that this happens this way, is because as a bylaw of the committee, everything has to happen by consensus. So, there's no like majority voting going on. There a lot of different schemes to decide these sorts of things in different standards bodies, like you might have read about in the IETF, Internet Engineering Task Force. They have, I think, it's like a tiebreaker method, where the decision is made by which side can hum the loudest.

[00:07:04] Ar: Is that real?

[00:07:05] MC: Yeah, it's real.

[00:07:07] T: Do they have the same number of people, humber of people to make it fair?

[00:07:12] Ar: Oh, my God, Tessa. No.

[00:07:16] Al: That explains a few things. 

[00:07:22] MC: Yeah, that's rough. A lot of other – then there's, of course, there's majority vote, which is, I guess, the first logical choice. The problem with that is, then you end up with like a few companies packing the room.

[00:07:35] T: With humming, where they could pack the room with hummers?

[00:07:42] MC: Yeah. Humming Is the truly fair standards body decision method.

[00:07:48] Ar: My mind is blown by that.

[00:07:51] T: I really hope the secondary purpose is like an acapella group or something.

[00:07:57] MC: IETF acapella, that'd be fantastic. So, there's a whole body of like research there honestly, into how to most fairly conduct standards body decisions. I'm not an expert at all on that. So, I'm going to refrain from further comment. But the way that TC39 went with was consensus, and that's a big driver behind like, a lot of decisions that come out of the committee where you might wonder, why did that happen? It's because you have to reach like, full consensus. And so, in order to reach consensus, the solution is basically we all get together synchronously, every two months or so, to discuss everything and basically give opportunity to object. We don't like go around the whole room and like actively solicit a yes vote from everyone. It's just this proposal is going to advance the stage four. Are there any objections? And then if there are none, then we say it has consensus.

[00:09:00] OS: That explains a ton of why these proposals take so long, proposals have been like, I've been waiting for this for literally forever. It feels like it just keeps getting pushed to the next Ecma year or whatever.

[00:09:16] T: Remember when they were like we're taking the pipe out of Vue because of Ecma, and it's only like now that we're seeing the famous pipe?

[00:09:26] MC: It's coming. It's happening

[00:09:29] Ar: [Inaudible 00:09:28].

[00:09:35] MC: The good news about that is the pipe operator just advanced to stage two, which means that it is eventually going to be included in the spec. So, stage two is a pretty high bar to clear, which is that the committee intends for this to be included in the specification eventually. Stage one is basically this is an interesting problem that's worth solving. But then by stage two, it's like this will get included in some capacity.

[00:10:00] Al: So, has the debate between whether we're going with the F sharp or the other one been resolved? Or is that still up for debate?

[00:10:10] MC: So, the champions have resolved it in favor of hack pipes. And that's the current form of the proposal. That's the form I would expect it to be advanced in. There was substantial –

[00:10:24] Ar: Can we quickly recap what it is? What are the options?

[00:10:29] T: It sounds like we're talking about like Hercules and like the Colosseum, and they're like duking it out. 

[00:10:38] MC: So, there are two different ideas for how the semantics of the pipe operator should be. I am actually – so, I'm trying to look up an example here, because it is very confusing.

[00:10:53] T: That'll give us an opportunity to say, belatedly, nerd at Alex.

[00:11:02] MC: Gosh, the issues on this repo are such a minefield. So, the pipes proposal, the thing I was about to launch into, was that this has turned into like a huge mess, because there's a small chunk of the community, very invested in F sharp pipes, that particular style, or that particular syntax. And we actually had to like ban some people, which is the first time that's happened in my tenure on the committee. We had to like ban people from GitHub and Matrix and whatnot for literally starting flame wars on these repos, or on this proposals issue tracker.

[00:11:35] Al: Didn't realize this episode was going to be spicy.

[00:11:40] MC: Seriously, yeah, it's wild.

[00:11:42] Ar: Can we very quickly establish what exactly is a pipe operator? What would it do? 

[00:11:50] MC: Yeah, so generally, a pipe operator, or the pipe operator, regardless of which syntax, we end up going with, the pipe operator will allow for sort of more composable, more flexible function chaining, or nested functions. So, it sort of whenever you would have like a long function chain, dot then something, dot then something else, dot to string, I don't know what. You could turn that into using the pipeline operator, or whenever you would have a large nested function call, like passing something to a function, and then calling another function with that as the argument and then calling another function with that as the argument, you can turn that into a use of the pipeline operator.

It's a little more flexible than either of those approaches, because it allows you to sort of – it allows you to indicate where data is going with syntax. So, you don't have to declare intermediate variables in the middle. So, for example, let's say you had, let's say you were making a request, and then you want to pass that to JSON, right? But you don't care about the actual, the value of the request that like comes back from fetch, you just care about the JSON. So, you could say, const JSON equals, and then you do your fetch, and then you pipe it to two JSON. And then inside of two JSON, you just put a little syntactic identifier, the current form is the caret symbol. But the symbol is sort of up for debate that's not set in stone.

So, you would just put the caret symbol in there, and that symbol is sort of part of the pipeline operator, and it says to the engine, “Hey, whatever result was before the pipe, stick it here where the caret is.” So, it lets you control where data is going without having to declare intermediate variables, sort of a middle ground between like, having a big list of variables for every step in whatever you're composing, and chaining or nested function calls where you can't control where things are going in that nature.

[00:13:57] Al: Yeah, with that caret symbol, I feel like there could be some leeway in there too of like, ultimately being like, okay, cool. If you want to use the caret symbol to define where it goes, great. If you don't provide a caret symbol, we're just going to assume that you're calling a function and providing it as the first argument. And I think that could be sort of the late if you wanted consensus, there you go.

[00:14:22] MC: Yeah.

[00:14:23] T: Well, it seems like Alex has definitely picked a side.

[00:14:26] Al: I'll be honest, I did like the F sharp syntax.

[00:14:31] T: Fun fact, he was the guy that got banned from TC39.

[00:14:36] Al: I'm having a hard time looking this up now. I can't see it anywhere. I don't understand why.

[00:14:40] MC: I think it might have actually gotten like scrubbed from GitHub. There was somebody accusing Tab Atkins of like abusing power or abuse of power and like change their Twitter bio to TC39 is corrupt, and wrote up this whole screen. It was wild. Yeah, I think it probably got scrubbed from GitHub.

[00:15:02] T: Poor Tab.

[00:15:03] MC: Yeah, seriously poor Tab. It was really rough. I read the whole thread. I'm assuming it got taken down.

[00:15:11] Al: Yeah, that's one of those things where like, I mean, that's what cause Guido van Rossum to step down from being a benevolent dictator for life in Python was that there was the walrus operator and it was such a heated argument over how it should be implemented and whether or not even the language needed it. And after it got approved, he like, the next day said, “Cool, I'm retiring. Don't talk to me anymore.”

[00:15:41] OS: The consensus podcast.

[00:15:45] Ar: No, ASMR I will kill you. Misophonia.

[00:15:49] MC: Misophonia.

[00:15:50] T: But you can have both misophonia and ASMR.

[00:15:51] MC: What is misophonia?

[00:15:53] T: It is the hate of noise. Chewing?

[00:15:56] Ar: Yes, chewing. A lot of bodily function sounds like coughing, clearing your throat.

[00:16:02] T: Oh, I just heard someone swallow. When you finished that, I heard it.

[00:16:08] MC: I’m going to stay far away from the mic and I'm not talking now.

[00:16:12] T: ASMR among us.

[00:16:13] MC: Oh, man. That'd be so funny. We have to do that. We really have to do that.

[00:16:18] T: We’ll do it some time.

[00:16:24] Ar: I'm so glad you're muted Alex, because I have a feeling that you're being rude.

[00:16:29] Al: If we have you involved from TC39 then would that be considered Ecma ASMR?

[00:16:42] MC: Nice. We do have a hobby of like cutesy tool names like that. There's actually a really big tool chain for producing the like pretty HTML that the spec is rendered in and the tool is called ECMarkup.

[00:16:55] T: Nice.

[00:16:57] Ar: So, did you say pretty?

[00:16:59] MC: Yeah, well, relatively speaking.

[00:17:02] T: It has market, that's a pretty name.

[00:17:05] MC: I think it's pretty.

[00:17:10] Ar: Subjective.

[00:17:13] Al: Does it default to Comic Sans? Because if not –

[00:17:16] Ar: You're never going to win that war, Alex.

[00:17:18] MC: Wait, are you a Comic Sans appreciator?

[00:17:21] T: A Comic fans?

[00:17:26] Ar: Oh, Tessa.

[00:17:26] MC: That's so good. Alex, I should introduce you to somebody on the committee who does everything, like every – they’re pretty big force on the committee. They're always around and always involved. And every presentation is in Comic Sans and they also use Comic code for their editor font.

[00:17:43] Al: Yes. Someone who understands me.

[00:17:47] Ar: No, I thought it was bad enough like my lease agreements come in like that obnoxious font that kind of looks like Comic Sans. But it's like, even more childish.

[00:17:57] T: Oh, Dank Mono?

[00:18:05] Ar: I don’t like you, Tessa. Just kidding.

[00:18:10] T: The one that comes with Apple like chancery or something the handwriting one, Oh, Segoe script, Segoe UI. 

[00:18:17] Ar:, like, yeah, it looks like adolescent handwriting, but a font.

[00:18:20] T: Okay, not all of us have great handwriting, Ari. I’m sorry. I'll write it neatly next time.

[00:18:27] Ar: But no, like literally, the heights are like, slightly varied, literally.

[00:18:31] T: Like Dank Mono? It sounds really frustrating to read a lease agreement. It's supposed to be an official document.

[00:18:41] Ar: Yeah, I know. But every year, it comes in like why?

[00:18:45] Al: You should sign that lease agreement in red pen or something. Be like, “Fix your fonts.”

[00:18:54] T: Sign it in crayon with your nondominant hand.

[00:18:58] Al: Two can play this game.

[00:19:04] T: Going back to silly names. I need to know what this walrus thing is because it doesn't sound real.

[00:19:09] Al: Oh, so in Python, you have a walrus operator, which allows you to do in line assignments. So, imagine –

[00:19:20] T: Is it colon equals? No?

[00:19:21] Al: Yeah, it's colon equals. So, it's a set of eyes with an equal sign, so you have two big teeth, and it looks like a walrus.

[00:19:28] MC: Wait. Tessa, was that a wild guess?

[00:19:31] T: It was because I was – we were doing that and like Rust or something. And I was like, “This should be a ligature. It's just like a slightly longer equal sign.” I was like, “That's ridiculous. Who would actually do this?” Python.

[00:19:42] Al: And it was very contentious. But essentially, what it allows you to do is that rather than having to go like x equals zero and then start a four loop and be like four, or whatever, because in Python, you can't do inline assignments in a four. Anyway, you would be able to just like in one line, both assign the value and then like, have the – like the use case for it is very, very niche. And like when you need it, you're really needed. And when you don't need it, it's useless basically.

[00:20:15] T: So, like flux architecture?

[00:20:17] Al: Basically, yes. It is sort of like that only smaller.

[00:20:26] MC: My favorite operator name in all of programming language design is Rust’s like generics operator for function calls where – so, you can have polymorphic functions that work on like a variety of data types in Rust. And when you want to use like a specific instance of a function for a specific type, and there's not enough information available to infer which one you want, you do colon, colon, and then angle brackets, and you put like the name of the type inside the angle brackets, but the colon, colon angle brackets is called turbo fish.

[00:21:02] OS: It's a fantastic name.

[00:21:03] Al: That is a fantastic name.

[00:21:06] T: It sounds like an internet product from the ‘90s.

[00:21:08] MC: Yes, yes, it does. Turbo Fish Inc. That's a .com bubble name, for sure.

[00:21:17] T: Nice.

[00:21:18] OS: I mean, yeah, I definitely loved the name of it. But it hurts my soul every time Russ tells me type annotation needed at all. 

[00:21:27] T: So, I mean, speaking of language design, I feel like there is the phrase designed by committee. And that is usually implied to be like a bad thing. So, why does it work? Or how well does it work for designing JavaScript?

[00:21:43] MC: Yeah. Well, so that's a really interesting question. Because in some sense, it's almost not the goal of the committee. I honestly don't know how well it works in terms of producing the cleanest, most ergonomic, most intuitive language. Obviously, there's a ton of historical cruft with JavaScript. But in some sense, that's maybe counter intuitively, not the sort of primary charter of the committee. The primary charter of the committee is to make sure that things work across browsers, basically. The need for this sort of work grew out of the browser wars, right? And the awful experience of you load up your favorite website, and it tells you need to go use Netscape or Internet Explorer, or whatever. 

[00:22:33] Al: So glad that no website now requires you to use Chrome or anything like that. I'm so glad we're past that. 

[00:22:41] T: Well, with the conference yesterday, I was on Chrome. But it didn't work on Windows and only worked on my Mac and it didn't even tell me.

[00:22:48] Ar: I wish I knew.

[00:22:50] MC: Yeah, there's still plenty of work to be done. And, you know, the scope of the committee is certainly limited, because it's only JavaScript, right? There's plenty of – most of the stuff I run into these days, that's not Cross Browser Compatible is like video conferencing stuff, which is using native API's, and oftentimes, it's just down to like, who did a better, more efficient implementation of it.

But in terms of JavaScript code, like, it used to be that if you wanted to use basic methods, like random stuff off of array dot prototype, that you would like have to use a specific environment, or you'd have to check what environment you were in. And that's still sort of working reality for a lot of programmers. If your company needs to support like Internet Explorer 8, then you have to use Babel to translate everything you're writing down into an IE 8 compatible fashion, where you don't even have async await. That's been around long enough that a lot of us take it for granted. 

[00:23:55] T: I learned last week that async await is very, very unpopular in this group.

[00:24:00] MC: Interesting.

[00:24:01] OS: Who here doesn't like async await?

[00:24:05] T: I thought you two were saying it’s confusing.

[00:24:09] OS: I was ready to get into a battle.

[00:24:12] MC: Yeah, basically, it's great.

[00:24:14] T: So, by browser wars, do you mean like how all the browsers had their own style of JavaScript or J script? Or do you mean something later in time?

[00:24:25] MC: Yeah. So, it was mostly a business phenomenon, where there were like, different companies were basically vying for control of the web.

[00:24:35] T: Oh, not like now.

[00:24:39] MC: So, it was distinctly different, right? Because the companies would – like Microsoft would develop new features, and get programmers to target those features, and deliberately not spread them around the industry. So, that like IE 6 was the only browser that supported those features, right? And then you'd get your, like your programmers, or the programmers that they targeted, would be like, “Oh, this is so awesome, this makes my work so much easier. So, I'm going to develop using this feature.” And then lo and behold, their site would only work on IE 6, and they'd have to tell all their users to use it. And that was sort of how the browser wars were conducted.

There's certainly like, capitalism still exists. Companies still want control of the web and control of the users of the web, right? But there's a lot more protection now. One of the big invisible ways that this happens is a tool that the committee maintains called test 262, which is – so it's a reference to Ecma 262, which is the spec, the JavaScript spec. That's just, I guess, that's the 262nd document that Ecma produced. So, test 262 is a conformance suite. So, it's basically this huge battery of tests in the form of JavaScript programs with expected output. And you can run it against a JavaScript engine to measure how well it conforms to the spec.

So, now as part of the standards process, when you're advancing your proposal, at some point, you have to develop tests for it, in test 262, to measure whether browsers or other environments are conforming to the spec and correctly implementing the feature that you're proposing. And then that sort of measurable, whether like, you can get a percentage score for conformance. It's also a handy bug tracker, basically, for all the different implementations out there. They can just look at the output and say, “Oh, we're not handling yields inside of anonymous functions, inside of four loop initializers correctly, or something ridiculous like that.”

[00:27:02] T: That sounds really fun. And yet, like, it seems like every project that Ecma makes sounds like an Umbrella Corp like thing, something like vaguely evil and anonymous.

[00:27:14] MC: Yeah, totally. It's a good project, though. It's really necessary for the health of the web, I guess.

[00:27:23] OS: I'd really love to know more about what you in particular work on at TC39. Is there anything that you're championing right now?

[00:27:30] MC: Yeah, so I'm championing the pattern matching proposal.

[00:27:33] OS: Oh, baby, let's go.

[00:27:35] MC: Yes. Super exciting. I assume that was a recognition from another language. They've used pattern matching in?

[00:27:42] OS: Oh, yeah, absolutely. I'm a big fan of many functional programming languages. I like Oh Camel, Reason. I imagine actually, pattern matching in JavaScript is probably just a bunch of people using like reason ml or using rescript. And saying, “You know what, this would be dope if I had this at JavaScript.”

[00:28:00] T: Wait, we have regex. I don't understand.

[00:28:05] MC: Oh, my gosh. So well, that is actually good analogy. If you're somebody who's familiar with regular expressions, you can think of pattern matching as regular expressions for like objects, sort of generic data. But yeah, and Oscar, to your point, it's definitely an ecosystem driven thing. There's this survey called State of JS, I think it's stateofjs.com, we'll leave it in the show notes. And one of the questions they ask every year is what do you think is most missing from JavaScript? And I think pattern matching was the number three answer.

[00:28:41] OS: What were one and two?

[00:28:42] MC: I can't remember what two was. Number one, ironically, was type checking, which is a little funny. I mean, I don't know, I suppose I kind of agree in a way. I always prefer, strong statically typed languages. But it is definitely impossible. Exactly. Definitely impossible in actual JavaScript, would totally break backwards compatibility.

[00:29:12] T: And also, all the fun of JavaScript, in my opinion.

[00:29:15] MC: We have TypeScript for that, God.

[00:29:17] Ar: Yeah, you got to live on the edge. Is it a Boolean or is it a string true? I don't know.

[00:29:23] T: I thought we were past the browser wars.

[00:29:29] OS: But I mean, I would love to hear since you're a champion, I would love to hear just like a little bit more detail on like pattern matching in JavaScript and what that can really look like. I haven't looked into it much, so I just kind of want to guess, is it just mostly reusing switch statements? Because I think the syntax or switch statements right now, like for particular cases, you got identifiers, you've got strings. I think that's kind of it. It seems pretty easy to extend the language to just add object support to cases.

[00:29:58] MC: Sure. So, certainly a goal of pattern matching is to subsume every use case for switch. However, we're making it a priority in this proposal to not reuse any syntax. Because switch can be pretty confusing for newcomers. It's got quite a lot of foot guns. Oh, that's a little committee term that I often forget is jargon. A foot gun is like something present in the language that would readily make a programmer shoot themselves in the foot. So, we try to avoid foot guns.

[00:30:30] T: So, if you knowingly introduce more switch statement like syntax into JavaScript, would that be like Chekhov's foot gun?

[00:30:40] MC: Oh my gosh, I'm going to use that in the plenary. I'm going to make a point to work in Chekhov's foot gun. Oh, my God. I'll credit you in the plenary notes.

[00:30:51] T: Thank you.

[00:30:51] MC: Oh, that's so funny. 

[00:30:53] OS: I know the major thing that trips people up with switch statements is scoping of case statements. So, is there anything else? Or is that like, the major thing?

[00:31:03] MC: Yeah, there's that. And then there's also fall through? If you don't put a break –

[00:31:08] OS: Oh, right. That little thing.

[00:31:10] MC: Yeah, you don't put a brake you start executing arbitrary code that you don't expect.

[00:31:14] Al: Yeah, I've definitely had people run into the fall through thing. It's very useful in that one weird case where you need it, but then otherwise, it should not be a default.

[00:31:23] MC: Yeah, exactly. And so semantically, it's just an or, right? This condition or this condition. You can totally handle it inside of – you can handle it in a way that is opt in, not opt out and that's a goal of pattern matching, is to make fall through like that opt in, so that you don't accidentally do it and cause a production outage.

[00:31:50] Ar: That sounds like it was informed by personal experience.

[00:31:54] MC: Not mine, per se, but certainly believable.

[00:31:59] T: Yeah, as a beginner, I will say I did really love switch statements. But I also feel like, sometimes when I think about programming, I think about it like Katamari, I'm just like, “Okay, I'm going to start with this thing. I'm just going to keep on tacking things on, so fall through words very well with.” I mean, we already know I love nested ternary.

[00:32:20] OS: Tessa, no.

[00:32:24] T: Oh, good.

[00:32:26] MC: So, there's some other really interesting properties of pattern matching that we're working on. So, I should also say, currently, this is a stage one proposal. We're like very much still ironing out the syntax and semantics, everything is up for debate, pretty much. We've got like a pretty good vision of it, but it's very much subject to change. So, don't hold me to any of this. But some of the priorities, we have, one that would actually be really relevant in like front end development if you're using Vue or other front end frameworks.

[00:32:57] T: Or libraries.

[00:32:59] MC: Yeah. So, we're making the whole thing be an expression. And so, what that means is inside of a match statement, I guess, I should say we're calling it a match statement, and there’s going to be a match keyword.

[00:33:13] OS: Yeah, as I was going to ask, like, if you're not reusing switch, is there going to be a switch and a match in JavaScript?

[00:33:21] MC: Yeah, that's the idea.

[00:33:23] OS: That is spicy.

[00:33:24] MC: Yeah, I mean, obviously, so we can't remove switch, but the idea is, once pattern matching lands, there shouldn't really be a reason to reach for it anymore.

[00:33:33] OS: That makes sense.

[00:33:35] MC: Everything you could do with switch, you can do better with match.

[00:33:39] OS: I mean, I'm a much bigger fan of the match keyword in the language that I work on. We didn't cop out and call it switch, we called it match, just being real.

[00:33:51] Ar: Spicy.

[00:33:53] OS: Programming language takes any day of the week.

[00:33:59] MC: So, the whole match statement is going to be an expression which means, inside of the match statement, you're going to have multiple branches representing each condition. Right now, we have it as a, like, it's going to be prefixed by the keyword when. So, it's like match some object when some pattern, when some other pattern, et cetera. And on the right-hand side of each of those when statements, is going to be an expression. Now, you can either just have that be like a bear expression, like a literal number, or a literal object or something. Or what we're going to do is piggyback off of do expressions, which is another proposal in the works, it's stage two.

[00:34:41] T: Or do in other languages?

[00:34:43] MC: It basically – yeah. Wait, sorry, I missed the first half of that. 

[00:34:50] T: Stage two, like two, do. 

[00:34:55] Al: Because we’re on a Vue podcast.

[00:35:00] MC: Nice, very nice. So, do expressions, if you're familiar with Ruby, it's pretty much exactly the same as do blocks in Ruby. They basically let you stick the do keyword in front of a block, which is just represented by curly braces. And then you can have a bunch of statements inside the block. And then the last expression is the result of the do expression. So, you can say, like const, foo equals do, and then a bunch of statements. And then the last statement in the do block, is what gets assigned to a foo.

[00:35:38] T: So, is that going to be like a different use case to the existing do? Or is it like, are they overlapping use cases? Because we have, like, do if you're going to put it in front of a while, right?

[00:35:51] MC: Oh, yeah, so that's actually a fixed keyword, like do while I think that's the only place that can currently appear in JavaScript. But yeah, definitely distinct. So, for pattern matching, we're going to reuse do in some capacity, the exact syntax of it is still under debate. But what it means is that the whole, every branch have a match expression is going to have a valid expression result. So, you can say like const foo equals match. And then whatever the result of the match statement is gets assigned to foo. Or you can importantly, for like front end development, you could like match on some data returned from an API, and then have each branch of the match be a component. And then whatever, whichever arm gets selected, that component, gets rendered. You can return match from your render function.

[00:36:47] Al: You could also in theory, use it to like, potentially enhance TypeScript compiling, where you could have like an overloaded function call and TypeScript would automatically make like a matching syntax for it to say cool instead, here are the different signature functions. And then like, if it looks like this, do this, if it looks like this, do this, if it looks like this, do this. Otherwise, do this other one, right?

[00:37:19] MC: Yeah.

[00:37:19] T: And for clarity, what do you mean by overloaded function calls? Is that like, when you have variable number of arguments?

[00:37:28] Al: In other languages, not JavaScript, we have the concept of overloading a function definition. You would have different signatures for your function when you write a function. So, if you do like function, add, and then x comma y, right? And you could be like, okay, x is an integer, and y is an integer as part of your type definition. And then you would be able to go okay, cool. In that case, it's going to add like this. And then you can redefine add with two strings. And you can say, okay, when we say add with two strings, it should actually function in a slightly different way, because we want to put a space in the middle of them or something, but it's the same function name. And in JavaScript, you don't really have a way to do that you would just like, either, I think it probably just goes like says no.

[00:38:30] T: Although I feel like the addition operand kind of behaves like that, right? Because if there's two strings, it's going to concatenate them. And if in this two numbers, it's going to add them.

[00:38:38] MC: Yeah, there's some amount of overloading baked into the language, but it's generally not very user extensible. You can sort of hack your way around it by doing runtime type checks, if this first argument, like if type of this first argument, is string, do something else, if it's number, do something else. But that's pretty limiting. You can’t. There's a lot that you could do with overloading in other languages that you can't do with that.

[00:39:07] T: Yeah, when I worked at a company that used a functional language on the back end, they like to try and make their own implementations of JavaScript that would allow for overloading and things like that. But yeah, I mean, match sounds really fun. But it also sounds terrifying. Like, you think that it was hard programming with mix ins and potentially messy with composition API. Now, we also have this like match thing that can pick your components for you. I feel like it could be hard to keep track of.

[00:39:42] OS: That's sort of interesting to think about. So, like for me, like I have a very functional programming background. For me, pattern matching is like my bread and butter. No matter what it is I'm doing, like every single thing is a pattern match. In fact, in a lot of like you functional programming languages, we don't even use if statements. It's just straight up, like everything is a pattern match. Sometimes you rather write a pattern match on a Boolean value and even write, a regular if statement, where it's like, I'm typically trying to reach for pattern match for literally everything. From my perspective, I'm hype. I'm hype, because I'm like, “Oh, man, being able to return a match from my render function.” Because a lot of the times, actually, you know what, Tessa, pattern matching is actually built just for you. So that way, you don't have to do your nested ternary operators.

[00:40:40] Ar: Called out.

[00:40:41] T: You know I don't do that.

[00:40:43] OS: You can spread it out into this very nice match statement, where you have your different cases, which I guess we're going to call them wins. I have another question for you, Mark, by the way, because I imagine one day, we might want to have guarded cases in our match statements inside Oh camel, you know, uses like the when keyword for that. So, you say like this case, when some additional condition instead of just like, you know, the regular pattern match, which I think would be really weird if I had, like, match foo, when this if – that could be a little bit weird.

[00:41:19] MC: The current incarnation actually does use if, like when something, if something else.

[00:41:24] OS: That is wild.

[00:41:27] MC: Yeah, it's definitely new. I'll say that, it's new, as far as I know, haven't seen anybody use that particular combination of syntax. But that's what we get with infinite backwards compatibility. But aside, remind me later, or somebody asked me later to talk about don't break the web. That’s a good topic. So then, I'll just say, for pattern matching, we're also allowing bear if, like without a when.

[00:42:02] T: Okay, I think you like grizzly bears.

[00:42:08] MC: So, one other cool feature of pattern matching that we're working on is a matcher protocol. So, there's going to be – currently, we're using this symbol dot matcher name. But there's got to be some specially named method that you can hang off of objects that you create, that allows those objects to interact with the match statement. Basically, it lets you specify custom behavior for when, let's say a class that you're controlling matches a particular case. So, in that way, you can sort of interact with the baked in features of the language, which is really cool. You can imagine even a library author writing like a symbol dot matcher method off of the component class that like all components extend or something like that. And then you could match on a component inside, maybe some styling code or something like that. You could pass a component in as the operand. It's pretty sweet.

[00:43:08] OS: Now, that sounds scary.

[00:43:12] T: I was thinking I hope this episode nerds Knife Seven into making something.

[00:43:19] MC: Totally. Yeah, that'd be awesome.

[00:43:21] OS: Yeah, like that definitely sounds like opens up a ton of opportunities for like a lot of stuff. Because, we in JavaScript land love to make things as magical as possible and that is certainly a way you're going to make stuff truly magical.

[00:43:36] Ar: Magical or messy?

[00:43:38] T: I like to make things as gross as possible. That's truly the appeal of [inaudible 00:43:42] for me, perhaps as a comic code is for Alex. When you were talking about functional programming earlier, I just was reminded of that video that was using all the programming memes in the summer with the like, the square hole and the triangle hole and everything was going in like the rectangle hole.

[00:43:59] OS: Yeah. I mean, I think the idea of using a was symbol dot matcher was like the –the neat thing about that is it would allow you to design your own little DSL, or your own little domain specific languages, for doing cute little stuff inside of JavaScript, which is kind of nice, right? Because if you're looking towards the future, and you don't want to use a tool, like Babel, or something like that, or you don't want to have some sort of nasty tag template literals or something like that, you can actually just say like, “Oh, hey, actually, I'm just going to implement this class. I'm going to define how it matches on things.” I'm imagining, like even writing something like a state machine, you could do something super-duper cool of the class and having custom matches on it. So, I think it's going to open up a lot of cool opportunities. I'm excited to see more about that.

[00:44:50] MC: Yeah, I'm excited for it as well. I think it's going to be really powerful.

[00:44:55] T: So, to wrap up, can you give us like a quick overview of how these proposals get made or push through and how you avoid breaking everything when you add something new to the language?

[00:45:09] MC: Sure. So, proposals, I alluded to this earlier, but proposals move through stages. So, there's stage 0, 1, 2, 3, 4. Stage zero is just, you have thought of an idea. Stage one is you've presented the idea to the committee, and the committee agrees that it's like an interesting problem area worth solving, then stage two is that the committee expects, or the committee agrees that this proposal will be included in the spec, eventually, in the JavaScript standard. And then stage three is the syntax and semantics have been pretty much nailed down. There's a formal draft of the specification. We've got tests for it, and it's sort of ready to go. And then stage four is this proposal has been implemented in I think the requirement is at least two environments. So, usually two browsers, and it's sort of locked down, we've gotten positive feedback from beta testers out in the world who have enabled that browser feature flag or whatever the case may be, and then it's ready. From stage four, the next time we cut like, yes, 2022, or whatever, all stage four proposals get moved into the main spec.

Now, and then the second half of that, how do we avoid breaking the web? So that phrase, don't break the web is like, sort of a common refrain among the committee. It basically reflects our infinite backwards compatibility mandate where, all websites to the best of our ability, which is just JavaScript, right? We can't control anything like HTML does or something like that. But to the best of our ability, all websites should work forever, right? It's something somebody wrote in the ‘90s that's no longer maintained, should still load up in Firefox 93. And that's pretty restrictive, right?

So, one quick anecdote for how that manifests, is you might have heard of the smooshed gate controversy. So –

[00:47:18] OS: I was hoping it was this.

[00:47:20] MC: Yeah. Smooshed gate is great. So basically, there was a proposal to add array dot prototype dot flatten, which takes like a nested array and just produces a one-dimensional array from it. But through user research, we found that there were some websites relying on a specific version of MooTools. From the early 2000s. I think it was the early 2000s that had their own array dot prototype dot flatten, like MooTools monkey patched to that on to the global array prototype. And it had different behavior from the one in the proposal. So, by adding this one in the proposal, the websites that relied on that would break.

Long story short, we couldn't add array dot prototype dot flatten. It ended up becoming array dot prototype dot flat, which we all know and love and presumably have used a few times. But in the middle there, there was a long thread, where one of the champions semi sarcastically proposed that instead of calling it flatten, we call it smoosh, array dot prototype dot smoosh. And that ignited some discourse, we’ll say, that ignited some discourse within the community. There's a great write up of this whole thing by Mathias Bidens who we can link the article in the show notes, I guess. Do you want to read the whole story? But yeah, we definitely full backwards compatibility can't break anything.

[00:48:44] OS: Can’t break nothing at all.

[00:48:47] T: Yeah. I wonder if you know, TC39 has been sometimes jealous of this, like additions approach of Rust. I mean, I think it's definitely possible in the future, but who knows.

[00:48:59] MC: New horizons.

[00:49:02] T: Oh, animal crossing. And with that, Mark, where can people find you on the internet?

[00:49:10] MC: So, you can find me my sort of digital home is mpc.sh. I have a very inactive blog and you can read my CV there if you want to hire me. My Twitter is @mpcsh_ which I'm very salty about, forever salty about that.

[00:49:28] T: You never don't have an opportunity to bring that up, I feel like.

[00:49:33] MC: Yeah, and I am MPCSH on GitHub. You can find my TC39 work there, which is mostly just commenting on the pattern matching repo for the moment.

[00:49:44] T: Nice. With that, it's time to move on to this week's picks. Alex, would you like to go first?

[00:49:54] Al: Yes, this week's pick is me being extremely self-promotional. I just finished talking at Jamstack Conf and they've just posted the video on it. So, my pick this week is my totally awesome talk about JAMstack stuff and how to use it efficiently to build really bad ideas. So, link is in the show notes.

[00:50:20] T: I like how we're all just going to pretend this –

[00:50:20] MC: Congratulations. 

[00:50:22] T: Yeah, congrats. You're not always extremely self-promotional. I’m kidding. How about you, Air? What are your picks for this week?

[00:50:33] Ar: My pick/picks, so it's actually some cookbooks but specifically, I'll just pick one out of this collection. So, I don't actually cook, fun fact. But I enjoy eating what other people cook and I also happened to be vegetarian. When I was a kid, my mom had these cookbooks that she would make stuff out of that I really liked. So, I forced my husband to get some of these cookbooks and start making new stuff out of it. They're based on food served that restaurant called Moosewood, which I believe is located in New York, but specifically when I've really been enjoying the food from his Moosewood Restaurant Cooks at Home. They're all quick recipes. That also has a really nice section on what to stock your pantry with on a regular basis so that you can just throw some of the meals together. So, it's been really helpful because my husband wasn't so much of a cook when we first met but he is getting quite proficient. 

[00:51:32] T: Nice. Speaking of stocking, I was like, “Oh, Ari is vegetarian.” That was like a big thing when you're buying food. I was like, “I don't know what her dietary restrictions are.” And Oscar, what are your picks for this week?

[00:51:44] OS: Yes, yes, my pick this week is a fantastic video game called Slay the Spire. It is a deck building roguelike game where you progress, through a spire, building a deck of cards presented to you as you try to defeat all the enemies. It is absolutely fantastic. If you love strobe light games that you can just play a game, take like 20 minutes and then chill. It's awesome. It's super cheap. That's available on PC and they put it on phones too. So, it's available on iOS, Android. It's available on the Nintendo Switch. So literally, any device you want to play it on, it's available and it is fantastic, and the music's so good.

[00:52:24] Ar: One of my coworkers I think is like world ranked in that.

[00:52:30] OS: That is wild.

[00:52:31] T: Is it multiplayer?

[00:52:33] OS: No, it is a single player game for those of us who don't have friends.

[00:52:40] T: Because we could have also done like a slight ASMR The Spire game.

[00:52:46] OS: Oh, my Lord.

[00:52:46] T: All right. How about you, Mark? What are your picks for this week?

[00:52:49] MC: Well, I see first of all that I think Alex has left a little note to talk about my headphones.

[00:52:56] T: Yeah, we want to know what your headphones are, how comfortable or not comfortable they are. 

[00:53:01] MC: They’re extremely comfortable.

[00:53:03] T: Yeah, morning work is an audio file.

[00:53:05] MC: I'm not that bad. I actually used to be worse.

[00:53:10] Ar: I'm very interested, because you are sporting the style of headband that I find most comfortable. But I have a feeling because you're an audio file, that means they're insanely expensive. So, I should just stop listening now.

[00:53:20] MC: Well, I mean, it just depends on your definition of insane, honestly. I wouldn't say they are. I will say actually, well, I'll say the name first, they’re the Dan Clark Audio Aeon 2. Specifically, these are the closed back ones, but the open back ones are just as good. I will say they punch way above their price point. I have owned significantly more expensive headphones, and I've listened to really significantly more expensive headphones, and these are way up there. If this was a blind – if I did like some sort of blind listening test, I would guess these are priced way higher than they actually are. They're really good, highly recommend, and they'll run out of anything. I'm not using an amplifier or anything. They're just coming out of my audio interface. So, sweet stuff.

[00:54:05] T: Okay. But what we really want to know is how do they feel around your ear lobes and how do they feel on the top of your head?

[00:54:13] MC: They're really nice. So, they're extremely lightweight. That was like a design goal for Dan Clark Audio. They weigh like next to nothing. There's some clamp force but not enough to make you uncomfortable. And the headband is like it perfectly distributes weight. Your pads are super plush. They're so, so, so comfortable. I mean, I've worn them for eight plus hours straight and not gotten uncomfortable. Highly recommend.

[00:54:39] T: Wow. This might be the first contender to all the Air Pods Max wears on the show. That last sounded like these are like 500 times as expensive.

[00:54:51] MC: Air Pods Max are actually really expensive for what they are, tbh.

[00:54:58] Ar: Okay. So, are these more are less expensive?

[00:55:02] MC: Definitely more, but they sound way better.

[00:55:07] T: They're not lossy, I'm assuming.

[00:55:09] Ar: Yeah, I just looked him up. Those are insanely expensive.

[00:55:13] Al: Okay, so what's the difference between the Aeon 2 and the Aeon RTs?

[00:55:18] MC: Oh, a lot, actually. The 2s are way better than the RTs. I've heard them both side by side.

[00:55:23] Al: There we go.

[00:55:25] MC: Yeah, definitely the 2s. And actually, if you're going to get one of them, get the Aeon 2 Noir. They did like a little retune and made them black instead of this weird red, and they sound a little better.

[00:55:36] T: Nice. Yeah. I mean, the RT is never as good as the original, right? Because you're just repeating what somebody else said.

[00:55:45] OS: Let them know.

[00:55:47] T: Yeah. Let's go into those picks, Mark.

[00:55:50] MC: Sure. First up is a book that I'm working through with a dear friend of mine called Crafting Interpreters, by Bob Nystrom. It takes you through implementing like a full complexity interpreter. And actually, implementing it twice, once as a like simplistic interpreter. And once it's like pretty optimized compiler. It's a really cool book. It's really well written. Highly recommend, and highly recommend working through it with a friend. That's been a lot of fun. 

Then the video game that Oscar, I think you're going to like this. It's called Baba Is You. It's a really, really fascinating games. So, it's kind of a 2D, like, top down thing where you're on a grid, and you're just controlling a character called Baba. It's a little sheep. And the rules of the game are presented as blocks on the game board that you can interact with. So, in an early level, you'll be surrounded by a wall and you can't get through the wall and the flag that you need to touch to complete the level is on the outside. But then, with you on the inside, like in the room is the phrase “Wall is stop”. And if you break up the text, then you can just move through the wall.

[00:57:07] OS: Oh, my lord.

[00:57:08] MC: Yeah, it's as if a programming language theorist like designed a video game to specifically tickle our brains. It’s really incredible.

[00:57:17] T: See, I was going to say it felt more like being in a whiteboarding interview. And they're like, here's this puzzle. And I'm like, “Oh my god, I just wanted to have a fun chill time.”

[00:57:25] MC: It's unbelievably good.

[00:57:28] OS: It sounds like one of those games where like, you're going to enjoy it the same way you enjoy like Factorio.

[00:57:34] MC: Yeah, totally.

[00:57:36] T: Not at all, I think.

[00:57:42] MC: I played it for five minutes, and it's was instantly my favorite game of all time.

[00:57:47] OS: I'm definitely going to check it out.

[00:57:50] MC: Last pick, totally off topic 90 or 180 degrees, I guess, is the latest episode of The Fifty Project, Mount Stimson, which is it's a project by Cody Townsend, who's a professional skier, turned ski mountaineer, who is working on climbing and skiing all 50 of the mountains in the 50 classic ski descents of North America, this like coffee table book. So, this is the Mount Stimpson episode is the first of this season and it's really exciting. It's one of the worst approaches that he's ever had. And near and dear to my heart as I'm also a ski mountaineer. Check it out on YouTube.

[00:58:28] T: Nice.

[00:58:28] MC: It's awesome.

[00:58:30] OS: Yeah, those are rad pics.

[00:58:31] MC: Thanks.

[00:58:32] T: I guess that makes it time for my picks. And my first pick is actually a toy, Air. So, my first pick is the Dumpster Fire, this is fine addition. So, this company, 100% soft, makes all of these like little toy dumpsters that have like, I don't know how to describe, it's like a kind of wide set smiley face kind of like – now I can't think of the company. But there's another company that does like smiling Boba tea cups and things like that. And also, like Adventure Time has those kinds of faces. So, they make dumpster fires with that face on it. But this year, they came out with a this is fine themed edition and I thought that was funny. So that's pick number one.

Pick number two, I've been trying to figure out how to write code on Windows recently, which has been a journey. And Mark, and my friend, [inaudible 00:59:22] showed me how to set up WSL 2 n my computer so I can write code in Linux instead, and none of these things are like words or phrases that I thought I would be able to do or understand but, it's happening.

[00:59:36] OS: That’s so funny.

[00:59:38] MC: I love WSL 2.

[00:59:39] T: But it was really hard to get my prompts customized because what we didn't realize is when you open the terminal into Linux, for some reason it starts you in your Windows file system. So, it wasn't remembering or detecting my batch RC because that was stored in Windows instead of Linux.

[00:59:57] MC: I have No idea why it does that.

[01:00:01] T: And the final pic is On Your Side, which is like a miniseries within a series by Nathan Fielder, who I just think is like, the funniest person on the planet. It's like a distilled version of Nathan for you that came before Nathan for you, where he'll have like a single question that he wants to investigate and then he'll go interview an expert about that question. So, if you enjoy Needed For You, maybe check out On Your Side.

So, with that, that's all for this week's episode. If you aren't following us on Twitter, head on over and find us @enjoythevuecast, and also for our feline companions, that sounded weird for our cats, join us @enjoythevuecats. Be sure to subscribe to this show if you haven't already, and leave a very stellar review of our show. And finally, remember to tell at least one friend what you enjoyed about today's episode. Thank you all for listening. And until next time, Enjoy the Vue.

[01:01:09] OS: And with our podcast, talking about TC39.

[01:01:14] T: This is definitely going to be one of those paid extras.

[END]