(Un)breaking JavaScript with Yulia Startsev

[EPISODE]

[00:00:10] AC: Hey, everybody. welcome to Enjoy to Vue. I'm Ari. Today on our panel, we have Tessa.

[00:00:16] T: Hello.

[00:00:17] AC: And Alex.

[00:00:18] AR: Hello.

[00:00:19] T: And?

[00:00:20] YS: Yulia Startsev. I am an engineer at Mozilla, on the Spider Monkey compiler for JavaScript.

[00:00:27] AC: Okay. She knows things and we're going to ask her a lot about that. Just to get started, let's do a roundtable. What are everyone's thoughts on semicolons? Let's start with Tessa.

[00:00:42] T: I was about to say reformed, yes. But then, I didn't realize if that meant used to be yes, now no, or the opposite. No.

[00:00:49] AC: Wait. What?

[00:00:51] T: Used to be pro, now anti.

[00:00:54] AC: Okay. Any particular reason?

[00:00:58] T: The Vue CLI used to set up projects without semicolons and I had spent a lot of time learning when they were required. Then I spent a lot of time unlearning the habit to add them everywhere they were. That's it.

[00:01:11] AC: Fair enough. All right, Alex.

[00:01:12] AR: It depends on what other language I'm using at the time.

[00:01:17] AC: That’s fair.

[00:01:18] AR: If I'm working a lot in PHP and I need to also write JavaScript at the same time, semicolons are in, because that way, I will consistently write code across my two code bases. If I'm writing Python, semicolons are out, because I will consistently write code across my two code bases. It really depends on context of what project I am working on currently.

[00:01:40] T: If I'm sending a winky face, semicolons are in.

[00:01:44] AR: Yeah. Yeah.

[00:01:46] T: I fought with Alex about this back in front and matching before, because I've worked out a lot of Java, JavaScript project. Sometimes you get people that are like, the JavaScript should look like Java. I'm like, “No. No.”

[00:01:58] AR: It's more of like, if I'm writing Python, I need to not have semicolons in JavaScript, simply because in Python, it's…

[00:02:07] T: JaviScript from now on.

[00:02:10] AR: In JaviScript. That is what it is called now.

[00:02:12] T: Thank goodness. We have someone from 2039 here.

[00:02:15] AR: If I'm doing that in Python and I'm putting semicolons at the end of every line, people just give me really dirty looks, and so does the Python interpreter sometimes. It's easier for me that JavaScript is a little bit more forgiving and doesn't give me dirty looks quite the same way that Python does.

[00:02:33] YS: It's giving them to you behind your back.

[00:02:36] AR: Yeah. No, I'm fine with that. As long as I don't know that it's giving me dirty looks, I'm fine with it.

[00:02:40] AC: I personally don't like to use semicolons. My reasoning is simply that my pinkie doesn't like to hit that button easily, so I just don't make it. Especially, because there are options that could just put them in for me if I'm on a project, where other people feel strongly that they should be included. I just prefer not to waste my effort.

[00:03:08] T: We need to get Ari a stream deck and then add a semicolon button on there.

[00:03:12] AC: No. No, no. No. That's an inside joke, by the way. It has to do with em dashes.

[00:03:21] AR: I have an em dash button on my stream deck just for Tessa.

[00:03:25] YS: I totally understand. Em dashes are really amazing. This is a fantastic…

[00:03:29] AC: It's my favorite punctuation by far.

[00:03:31] YS: Fantastic punctuation.

[00:03:32] T: So good.

[00:03:33] YS: There's also the em dash.

[00:03:35] T: They're also very good, especially when it comes to numbers.

[00:03:39] AC: Yulia.

[00:03:39] YS: Yeah. You're going to get me into a lot of trouble with this question, because I'm both working on the compiler, specifically the frontend of the compiler, more often than the backend. I'll explain what that means when we talk about compilers. I'm also Mozilla's representative to the TC39. TC39 has definitely gotten in trouble for mentioning semicolons in the past. I will acknowledge that that has been the case. There's two reasons why this is a contentious topic. I don't have that much of an opinion for how people write their code.

JavaScript has the ability for you to omit the semicolon. That is something that's consistent in the language up until now. We haven't changed that. You can write your code as you wish, and that's important. From the perspective of someone who writes the parser, that has to deal with this code, it is very painful, actually, also for specifying new features when we're trying to come up with a new way to express something in JavaScript and we have to deal with the fact that new lines are not meaningful in JavaScript.

Let's talk about, for example, Python. In Python, new lines are meaningful. In JavaScript, we don't have new lines. The only meaningful way for separating an expression, really, is with a semicolon. We have something called automatic semicolon insertion, which is when we — so imagine you're a happy little parser passing a happy little tree, or passing a string into a happy little tree and you come across the parser. You have to ask yourself “Is this truly a parser, or should I try inserting a semicolon here, reparsing the whole thing and see if it still drops?” Which is literally how parsers work with automatic semicolon insertion.

We end up doing two parses whenever we run into an ambiguous expression that does not have a semicolon. This is an interesting fact to know as a JavaScript developer, who may choose to omit, or add the semicolon. Because it does have very minor performance characteristics that may come along, but they're very minor.

Parsers are really, really fast. It also has an impact on how we specify the language. Let's say, you want to use a new keyword or something, where let's say, you want to take the new keyword and put it at the end of the sentence and have that mean something. Or maybe let's say, you want to put async at the weight of something. Something like this. Because of how the parser works, it will actually treat the next line as being part of that same expression. If there's a statement that comes on the next line that can be awaited, or can be instantiated as a new constructor, that will actually parse for the parsers.

When we're specifying things in the language, we actually have to — or there's other problems with new lines and everything, we have ways of specifying in the language, like this cannot have a new line in order for this expression to be valid, or this needs to do something. I mixed it up a little bit. It's the new line terminator that I was trying to explain, and I got it backwards.

Basically, you can’t split expressions with a new line, because of how we do — of how we need to do semicolon insertion, which is a very interesting problem, and one that we're not likely to change anytime soon, because that would be a huge web compatibility risk.

[00:07:00] AC: Yeah, that sounds like a hot mess.

[00:07:04] YS: Yeah. It's like staring into the abyss.

[00:07:07] AC: Yeah, we've heard that the whole point is don't break the Internet.

[00:07:11] YS: Yeah. I can tell you a funny story about my first day on TC39.

[00:07:16] AC: Oh, yes. Please.

[00:07:17] YS: I joined, oh, I forget the year, but does everybody remember SmooshGate?

[00:07:24] AC: Yes.

[00:07:24] AR: Yes.

[00:07:25] YS: SmooshGate was my first meeting, like just after SmooshGate had happened. Everyone was talking about SmooshGate, and I was like, “What is going on here?” It was really interesting. For anyone who's not familiar with what SmooshGate is, we had a proposal. Again, we're talking about web compatibility. We had a proposal for introducing a ray.flatten and a ray.flatten app. Flatten app, I think, was the original name. Because JavaScript is so extensible that you can extend it in ways that will make it not web compatible for engines to add new things. This was the case with new tools. I can get into the details of it, but it's really nitty-gritty.

Anyway, there was a case with one library that extended the language in a certain way, that made it impossible for the designers of the language to use that name. We had to change the name. The first name that the champion, who is exhausted, because we actually run into this problem a lot, was exhausted by seeing this problem all the time. He made a joke saying that we should rename it to Smoosh. The Internet got very angry about this. He even put a really nice GIF of three bunnies smooshing their heads together.

I thought it was really cute, but people were really mad. It actually makes sense that people are really mad, because JavaScript is the of the trade. I imagine most of the people listening to this and listening to this will be JavaScript developers, working professionally. Smoosh, when we pick a name for something that's a new language feature, we have to consider like, is this something that people from many different cultures can understand? Is this something that developers will recognize as they're coming from other environments? All these questions. Our sense of humor doesn't necessarily translate to a global population. Making a joke can land really, really poorly, which is what happened here.

[00:09:20] AR: I think, Evan may have even tweeted like, “I didn't know that the word smoosh existed until today, when that all was happening.” Yeah. 

[00:09:30] T: Your story reminds me of a friend at Square told me the story of, I feel like, their name is Cube or something now. He was explaining to me how they came up with the name Square, which was Jack wanted to name the company something to do with squirrels, or something like that. The Squirrel version of Twitter, and nobody was having it. He got really depressed and irritated. He was like, “Fine. Then let's just call it Square.” Because he was trying to think of the most boring name he could come up with, and everybody was like, “Oh, I really like that.”

[00:09:59] YS: I do like the word smoosh. I really like the word smoosh. I think it's a fantastic word. People might not be aware, but in Spider Monkey, all of the components of Spider Monkey are named. We have Ion Monkey, which is our optimizing git. We have we had Yaeger Monkey, which is now retired, and a bunch of other monkeys. We have no name for the frontend to the parser.

I managed to convince my team, we were rewriting the parser. I managed to convince my team to name it smoosh monkey. The official name for the rewrite of the parser is smoosh monkey. There's a bit of a joke in there as well. There's a thing that can happen when you design programing languages, which is called a reduce-reduce conflict, where when you're parsing a string and you're trying to say, this is what that string means. You've got the string and you want to tell somebody what it means, you're reducing that expression to its meaning. Basically, you can think about it that way.

The problem is when you can reduce in two different ways. That's a reduce-reduce conflict. We changed all of the naming around the stuff about parsers into calling it a smoosh-smoosh conflict. It was smoosh monkey and it was great and we never finished it. So sad about it. It was a very fun project.

[00:11:17] AC: As has been mentioned, you are on TC39. We want to talk about maybe some of the new things that maybe are coming to JavaScript, or have just been introduced. Let's talk about immutability. What is immutability?

[00:11:38] YS: Immutability is, imagine that you have a piece of data that you want to operate on. Let's say that it's just a string of numbers and you want to multiply them by two. A lot of programmers, if you're coming from immutable language, like JavaScript, so the JavaScript array function is immutable. Not function, but on array data structure is mutable. You could, for example, iterate over all of the elements and multiply them and return that as a modified array. Or in fact, a lot of the array methods are immutable methods.

For example, I believe, array sort. Yeah, array sort is a mutable function. This is great for performance in lots of other things, but it also makes other types of things difficult. For example, tracking history of how an object changed over time. Immutability is really great for that. Also, being certain that the thing that you're holding on to is what you think it is. For example, if somebody else goes and changes that data structure later, but you actually wanted that original data, then you can still use your copy and then everybody else is just iterating on their stuff. It's useful for that.

[00:12:55] AC: I can't tell you how many times I've done that to myself.

[00:12:58] YS: Yeah. It's a common problem.

[00:13:03] T: They're basically forking off your array.

[00:13:05] YS: Yeah. Immutability, forking off your array is actually a really great way to think about it, because immutability is very expensive. If you implement it in a naive way, what happens is you end up duplicating the same data over and over again. You can imagine how quickly that would end up being very large. If you're only changing one element in that array, then why not just keep everything the same, except for that one element? This is something called structural sharing.

In order to implement immutability efficiently, you need some form of structural sharing. That is precisely what a new proposal in TC39 is doing. It's called records and tuples. It introduces two new data structures. One of them is called records, the other one is called tuples. Records are map-like, or object-like, dictionary-like, whatever your background is, type objects. Tuples more closely resemble arrays. Those are the two new data structures. It's a very exciting proposal. We have it already implemented in Firefox.

[00:14:10] AC: Nobody listening could see that Alex’s face got so excited at the mention of record of tuples. I was a little worried there was going to be a heart attack involved.

[00:14:23] AR: Okay. All right. Here's my question. With the tuple, I know currently with maps and sets in JavaScript, you can make a object be the key, but it's the reference that it's tracking, so you can't just recreate the object and then use it as the key. With the tuple, or with the record, would you be able to say “Okay, cool. Given this tuple literal”, where you're defining it there as the lookup, rather than using a reference to something, would it then be able to look up that tuple?

[00:14:57] YS: I'm so glad you asked. This is a great question. Also, I should say, the work we have in Firefox is on a branch. It's not exposed to the public yet. That's only some time. Nobody get too excited about using it yet. Records in tuples are unlike objects and arrays. They are primitives. They are not a quality by reference, but they are a quality by value. Precisely what you just asked, that is the case. We are already designing new features around this fact. One that actually just got to stage three yesterday at TC39.

[00:15:36] T: In other words, the equality comparison is more like what I would get from comparing two strings or something that?

[00:15:42] YS: Exactly.

[00:15:43] T: Got you. The thing that always bothered me about tuples is it sounds like it should be two. I feel like, it should just be a thing of two. Then if it's three, then you have to call it a thruple. Yeah.

[00:16:00] YS: I mean, to be completely honest, that was when I first learned about the concept of tuples, I was like, “That sounds like it should be two things. Why are there 10 things in here?”

[00:16:11] AC: I also just think of Tupperware. I'm going to be real honest. That's where my mind goes. I mean, I guess, you could — it's a container. Anyway, I'm going to stop talking right now.

[00:16:27] AR: For practical purposes, for people who are listening, a great place to use something like this is if you are tracking a grid of things and you want to be able to look up what things, what grid spaces have things in them, instead of storing a two-dimensional array, where you have an array with arrays in it. You can instead store a one-dimensional map, where you have your key be the coordinates of the position in a grid. Now, rather than having to go and make a nested for loop to iterate over everything, to find the thing that you want, or check each spot, you have as your list of keys, the set of things that are there and available to you.

Previously, I have done this trick by just making a string that is comma separated. There you go. Problem solved. It would be fantastic if I didn't have to pass that string to get the coordinates out of it.

[00:17:34] T: I feel like, I need you to add a visual to the show notes, because I got lost completely.

[00:17:38] AR: I will add a visual to the show notes. It makes tracking an infinite, or an infinite grid super easy if you do it this way.

[00:17:45] AC: Because that's a thing that normal people track all the time, Alex.

[00:17:49] T: Yeah, really typical example.

[00:17:51] AR: I'm just saying, if you are implementing Conway's game of — if you are implementing Conway's game of life, it is technically on an infinite grid and this is the way to do it.

[00:18:00] AC: Of course, they’ve done that.

[00:18:01] T: Oh, by infinite, you mean it wraps around?

[00:18:03] AR: No. But I mean, it extends from infinity to infinity. 00 goes out to infinity positive and then out to infinity negative. It never wraps around.

[00:18:13] T: I feel like, every Conway's game of life I’ve seen, has been on a 100 by 100 grid.

[00:18:18] AR: Right. Because, I mean, you can do it on a 100 by a 100 grid. There are massive wins. That's how we know that Conway's game of life is Turing incomplete, is because you can implement Conway's game of life in Conway's game of life.

[00:18:30] AC: You're breaking my brain.

[00:18:31] T: Nerd.

[00:18:32] AR: Yeah. There are some bigger nerds than I am right out there.

[00:18:38] T: Are you sure? This makes you wonder what implications, if any, this will have for the future of Vue. Because the problem with Vue 2 was tracking all of the mutable methods, right? Wrapping array.push and array.pot, so that the activity system could detect when you made a change to the array, versus if you just reassign an array, or tried to use immutable methods, basically, it didn't know what was going on. Then with Vue 3, they got around that with proxies. I wonder if the next version of Vue, if we have records and tuples, if that will change the way that it works behind the scenes.

[00:19:17] YS: There might also be more good stuff that's coming up in the upcoming version of JavaScript, because this is a problem that the records and tuples champions, we call them champions, the people who move a proposal through the process that we have at TC39. They realized that it would be nice if array had immutable versions of pushing and popping. We have a proposal called array change by copy. It allows you to do pushed and popped, rather than push and pop. ED, past tense. It gives you a new array with those items.

[00:19:54] T: Oh, that's nice.

[00:19:56] YS: Rather than changing the underlying array. You would be able to more easily write your array stuff as though it was immutable, even though it isn't immutable.

[00:20:06] AC: Instead of returning whatever the element that was pushed or popped, it returns the remaining array as a new reference? Oh, that's awesome.

[00:20:19] T: We can finally get rid of the spread offering.

[00:20:21] AC: I cannot tell you the number of times where that messed me up, because I'm thinking, “Oh, it returns the array.” No, it returns what you took out of the array.

[00:20:28] YS: There is one problem. I think that pushed and popped got dropped actually, because I complained about it. I can tell you why I complained about it. The ones that have been added are reversed, sorted and spliced.

[00:20:40] AC: Oh, splice would be super useful.

[00:20:45] YS: I actually complained about pushed and popped.

[00:20:49] AC: Was there a reason?

[00:20:50] YS: Yes. The reason was, so when I go to TC39, I represent the implementer’s perspective. When we have to add a lot of methods to the array object, they can become really costly. In addition, the problem we had with SmooshGate exists continuously on the array prototype. It's very difficult to actually add anything to array prototype and know that it can land and it won't be weapon compatible. We tried to reduce the scope only to the most critical methods. Pushed and popped can be done with slice, I believe

[00:21:29] AC: That makes sense.

[00:21:30] T: I feel like, slice and splice was always a tricky one. If we also have sliced, I feel like, maybe it would be hard to remember which is which is which. I don't know.

[00:21:40] AC: I can tell you how I remember. A slice, like you're slicing off a slice of meat or something like that. Essentially, they look the same, or like a slice of cheese. They all look the same. It's from the same block of cheese. Splice, it's like gene splicing. That's how I remember it.

[00:21:59] T: Because you're putting something in the middle of the gene?

[00:22:02] AC: Or you can take out stuff too with that.

[00:22:06] T: Yeah. All I remember is I was taking a practice JavaScript test. I was trying to do something with string manipulation and I didn't know there was splice and slice, and neither did the person that was helping me out, because I had just started learning JavaScript.

[00:22:20] AC: Oh no.

[00:22:21] T: I went to the bathroom and I came back, but there were glass doors. I walked into the glass door. I got a concussion and still don't know the difference between the two.

[00:22:33] AC: Oh, no.

[00:22:34] T: Yeah. This makes me curious, like how do you come up with the names for the new methods and how do you test out that they're sticky enough, or that they work well semantically?

[00:22:46] YS: Yeah. It's a good question. We're trying to introduce a formal process, which is something that I've been trying for a couple of years. Oftentimes, first of all, we research what other languages do to see if we can align with other languages. Because transferability of skills across programing languages is really nice. That's one place where we look at names. In other places, we look at names as — well, actually, even before that, what do we have in the JavaScript programing language that is similar? Are we following a particular rule here? We try to make sure that we're careful about we don't do this perfectly.

There are cases where we haven't followed a specific rule to apply things normally, but this is something that we ought to do, and we try to do. Also, within the web platform, we try to be consistent with naming there. If there is a convention that’s already been set by the web platform, we'll follow it. Failing all of those, which does happen, then the champion usually, or the author. There are two different roles, champion and author, they will try to find a way to determine the best name. I can give you a couple of examples of tricky names that we've had to do.

Usually, we try to be precise, but sometimes you just have to go and reach out for something. The most spectacular case at the moment of something being added to the language with just a great name that would work in a fantasy novel is Shadow Realms.

[00:24:18] AC: I saw that and I was like, “What even is that?”

[00:24:22] YS: Also, just like realms in general. It’s such a great name for something. That's an example of like, we just don't know what name. It's really hard to name this.

[00:24:32] T: That’s definitely what I thought of when I first learned about Shadow Dom. I was like, “Those sounds like some dark magic.”

[00:24:38] YS: Oh, yeah, yeah. It is. It is. Also, you may recall, global this was a really tricky naming case. How do we name something that is global this? Because this is not exactly everybody's favorite feature of JavaScript. It's difficult to learn. It's difficult to work with. We ended up naming something global this. How do you explain that to learners? That's also a question we have. We actually have sub-committees that report back into the committee that focus on different questions. One of them is talking specifically to educators to understand how do we teach JavaScript features to JavaScript developers? Are they beginners, or mid-level, or senior level developers? How do they learn?

We have another group that also reports back into the committee, which is a research group. We look at how do we apply research techniques from, for example, HCI into looking at how we design the language, so that it is understandable and intuitive for developers?

[00:25:36] T: HCI, meaning Human-Computer Interaction, right?

[00:25:39] YS: Exactly.

[00:25:40] T: I remember personally not finding this, that complex to understand, but feeling really frustrated, because teachers kept on insisting that it was really hard to understand. I was like, I feel like, if you just went on with the content, instead of keep on telling me how hard it is, my life would be a lot easier.

[00:25:59] AC: It was jQuery, I will say, it could bite you a lot in a lot more nuanced ways. I remember, I spent an entire day trying to debug an AJAX request. When, as it turns out, the context of this was not what I was expecting it to be, and you could specify the exact context of this. Fortunately, my instructor finally remembered listening to a podcast some time where they talked about that and she’s like, “Maybe let's try that.” Sure enough.

[00:26:32] T: Nice. Yeah, I think I was told like, “Oh, don't worry about jQuery. You'll never use it.” Then my first job was a jQuery job.

[00:26:37] YS: Yeah, it’s really amazing. A lot of the web runs on jQuery. It is a really important library.

[00:26:44] T: Someone I was talking to recently said, they were talking to someone who — See, I completely can't remember where this was. Was it on the show? Someone was trying to implement jQuery mobile CSS into a Vue app, and was like, why is it not working? This year, in the summer. I was like, I didn't even know there was such a thing as jQuery mobile CSS. Alex is nodding. He's a big fan of jQuery mobile CSS. He's nodding harder.

[00:27:16] AC: Just in the other direction. Next. Do we want to talk about pattern matching?

[00:27:22] YS: Oh, yeah. Pattern matching is a proposal I am quite excited about, switch in case statements are very interesting in JavaScript. By interesting, I mean, broken. For example, the fact that you can bind a variable in one case statement, and it will actually be valid in another case statement, which is a little weird. The fall through is not entirely understandable to developers, I think. It's not explicit. I think that's a place where people might end up making mistakes if you missed a break statement or something like this. Various other issues with switching case.

People might not be familiar with this, but we actually deprecate, or discourage the use of certain features in JavaScript. One of the most famous examples is the width statement, which has been deprecated for many, many years. Width allows you to take an object that you've defined and treat it as though it was part of your global scope, which can be really, really weird. It can result in some behavior that you weren't expecting, if you can't — When you're designing a programing language, you have to think about how much do people have to keep in their mind? What's the cognitive load that they need to take on in order to solve a problem? There are ways that you can measure what the cognitive load is when a person is completing a certain task.

Width is not great for that, because you need to memorize what's in your scope as it’s running. We've deprecated that. We're planning for similar reasons to try and do the same thing to the switch statement, because it is difficult for developers to use. The solution to that is the pattern matching proposal.

This is a very popular proposal. I am one of the champions on that. There are six other champions. I don't think we've ever had a proposal with so many champions. I should probably talk about the process a little bit at TC39. You folks, or anybody listening to this podcast can actually interact with the TC39 process. We have a dedicated type of proposal, which you can submit. It's called a stage zero proposal. It's an early concept, a way to show a problem. The purpose of stage zero is to basically demonstrate, here's the motivation for changing this thing. Here's how I propose we change it.

Then, that goes through a series of steps. Stage one is the committee has heard it and has decided, we haven't tried to solve this problem in this way before, and it's not entirely a bad idea. Go ahead and work on it some more. If you come to the committee and you say something that would break the web platform, we'll send you back and be like, “You should probably rethink that, or reconsider it.”

Or if you're trying to solve a problem that isn't very well motivated, like there's no use for it by developers, then we will also say, “Think about that again. Is that really necessary? Can you show us a clear motivation for why this should be implemented in every single browser and add that extra weight to every developer working on the JavaScript platform, on the web platform?” That's what stage one means.

Stage two means, okay, we're happy with the motivation and we're happy with the basic shape of the problem, basic shape of the solution. We are going to go ahead with that and try to bring it to maturity during stage two. That's when we write the specification text. We try to do any checking for problems that we might expect with naming, with logic of the future, etc., etc. Once a feature reaches stage three, which is meaning that it's mature enough for implementers to go ahead and put it into their code bases, then it's very difficult to change fundamental aspects of the feature within stage three. That's why you'll see things, like you might have a favorite proposal and it's been stuck in stage two for two or three years.

The reason for that is once we cross the barrier into stage three, it's not only — it is the most expensive point that we reach, because that is implementation time. That's shipping, that's testing on the wide-open web, all that stuff. If we need to roll back those changes, it has to be for a really, really good reason. We don't want to prematurely move into stage three.

Stage four is complete. That means it is in the specification and will be released the following year as part of the specification for that year. We release a yearly cadence. That's what it's all about. Then we've got this really great proposal called pattern matching. In my dream world, pattern matching will be as universal tool in JavaScript as it is in the Rust world.

Many of its design features are inspired by what Rust does with pattern matching. Your traditional case statement will take a type — usually, a primitive type like a string, or maybe it's, I don't know, maybe it's a GUI, and I don't know if anybody would do that, or numbers or whatever. It would check if that value matches a certain case statement and then it would do some logic.

The pattern matching proposal will allow you to destructure objects and look inside of the objects and see if they are matching the pattern that you're looking for. Then if it doesn't match that, then you can go to the next statement and see if that matches. Inside of those you can do the logic that you want to.

We are also thinking forward into the future around other proposals that are coming down the pipeline. For example, due expressions are being considered how they would work with this new pattern matching syntax, and the structuring patterns and everything. I think, it’s very exciting. It's very, very powerful, which makes it a little scary, because using an overpowered tool for something that doesn't need that level of power can lead you to making mistakes that you wouldn't make with a less powerful tool. There's other problems with using an overpowered tool for something. I do think that this is well motivated and I'm really looking forward to it.

[00:33:44] T: Admittedly, as a fan of switch statements, but I would never force anyone else to use them. I'm curious, why deprecate instead of just having two different options?

[00:33:56] YS: You can, of course, continue to use switch. The issues with switch are that it's — all of its functionality will be possible with pattern matching. Switch is error prone. That's the other issue. The reason why we're looking at switch with a bit of a side eye is because it's so error prone. We might have done things better there. This is something that we do very rarely. We will very rarely do something like this. With the switch statement, we're like, maybe we should have done that differently.

It also adds really new, what's the word? New value to the language of things that we couldn't do before. Genuinely, new stuff, new expressiveness that you didn't have before. You can certainly continue to use the switch statement. I would be really interested in your experience with pattern matching to see if it's missing something that you enjoyed from the switch statement. I hope it would encompass everything that you enjoyed about the switch statement in this new proposal.

[00:34:57] T: Yeah, I'm definitely excited to try it. I mean, I generally use switch when I want fall through. I'm imagining, that’s something you can do with pattern matching.

[00:35:07] AC: Interesting.

[00:35:08] T: I like thinking about the cascade. It's fun.

[00:35:09] YS: Well, it's not quite fall through as you have in the switch statement, where you can have first something happen, and then it collide as — like an accordion, collapses down into the other switch statements as it falls through. I think that this isn't something that we're going to implement. You would have to make it an explicit match. For example, you won't have the problem with the binding of variables in the different case statements, leaking into the other case. That would be fixed.

[00:35:45] T: Why is this like its own feature, instead of just leaving us all to implement it via a bunch of if statements or something?

[00:35:53] YS: Yeah, that's a good question. It would be very difficult to read if you implemented something like this through if statements. That is a great question.

[00:36:02] AC: That's why I like switch statements. It’s because they're prettier than using a bunch of MLs.

[00:36:09] YS: That is definitely part of the motivation. Though, pattern matching can get very full of knots. You can write very ugly pattern matching. That's possible. I've seen it. I have looked at it and been like, “Why are we doing this?” For the most part, it does look — it does resemble a switch statement quite a lot, so you can still use it. It takes away the potential of making mistakes, which is what we're hoping for. Yes, you can in fact, do everything that you can do. The logic that you can implement with a pattern matching statement, you can do right now in JavaScript. It is not new fundamental functionality. That's a different class of proposal.

[00:36:46] T: It's interesting that JavaScript is taking inspiration from Rust, because my understanding is Rust also takes a lot of inspiration from JavaScript. It's a fun cycle there.

[00:36:55] YS: One thing I'd be really interested in at some point doing is a look at — I don't know if you're familiar with anything from linguistics, but there's this concept of linguistic drift from different natural languages. Certain things move across to another language. I'm curious to take a look at how that happens in programing languages, because it's almost like, we have certain errors in programing language design, where things just come into all of the major languages. Then, maybe they phase out, maybe they stay. I think it's actually quite interesting.

[00:37:30] T: Yeah, I would still love to personally try a programing language that's not in English, because I feel frustrated that every single one depends on English, and I want to know what the experience is like to have to learn one language that maybe I don't know, or maybe don't know well.

[00:37:44] YS: I mean, I can tell you, it takes a bit there. This is an interesting question among academics. There is a academic conference that held its first edition this year, called Pilates, which is programing in languages other than English. The keynote speaker was talking about why it's difficult to design a programing language in something other than English. He showed how our models for specifying languages. We have these things called grammars. They make it very difficult, and all the tooling around it. Also, the primitives that we use, like numbers and how we parse strings makes it difficult to write a language that's not left to right.

If you're writing a right to left language, you suddenly need to reconsider how all of those tools work. You can't use very many of the base tools that are used by programing language designers right now. It's really a challenge.

[00:38:54] T: Speaking of tools programmers find useful and things that are deprecated, I was always curious why caller and colleague got deprecated, because I really liked those.

[00:39:02] YS: Can you remind me about caller and colleague?

[00:39:07] T: It's like, when you have a function and it's causing some problem, where you don't know where it's getting called from. Why did this run now? Then you could do function.caller and see who called it.

[00:39:17] YS: Did we deprecate this, or — Maybe we did.

[00:39:23] T: Every time I had a warning, or I have to turn off strip mode.

[00:39:27] YS: Ah. Yes, we did.

[00:39:29] T: I assumed, maybe it was something to do with difficulty parsing. 

[00:39:33] YS: We did it. We did remove this. That is before my time. I don't know the answer to that.

[00:39:38] AC: Well, speaking of timelines on the very recent timeline, a particular proposal just made it to stage three. Let's talk about array group by.

[00:39:51] YS: Yeah. Array group by is a nice little proposal. I can talk a lot, so I want to make sure I answer any specific questions you have, if you have any. Otherwise, I can just talk about array group by.

[00:40:07] AC: I guess. Yeah. First, what is it?

[00:40:09] YS: Array group by. Imagine you have a basket that has eggs and cheese in it, and you want to categorize your eggs and cheese, you would use array group by and give it a — for every egg, you would say, okay, this is in category A, egg. For every cheese, you would be like, this is in category cheese. It allows you to partition arrays into separate arrays that you can then go and operate on. You get back an object with the tag, or the label egg and the label cheese and two separate arrays for those two things. There are two parts to this proposal. One of them is a group by, which I just described. Then the other one is grouped by map, which instead, returns a map instead of an object.

Now, we spoke at the beginning of this discussion about immutable data structures, and we talked about how we've got these great new primitives that are records and tuples. The reason we designed array group by map was so that you could go ahead and group by a certain tuple just automatically and have it grouped by that. That's not something you can do with an object. That was us thinking forward, like this is a feature that would be nice to have once we have records in tuples. That's pretty much the gist of it.

Yeah, that's the proposal. The champion there is Justin Ridgewell. It's quite interesting how we ended up on this proposal.

[00:41:43] T: Yes, absolutely.

[00:41:44] AC: You want to elaborate on why it's interesting?

[00:41:48] YS: Justin have come to committee with a different proposal. He did not come to committee with group by. He came to committee saying, that we have a usability issue with a array.filter, and that he can never remember if you're filtering in items, or your field filtering them out. Which direction does in Boolean and filter work?

We use the precedent set by other languages, and the way that our filter works is the same as in every other language. Now, I can't remember. I think, we filter — the Boolean is filtering things in, so you get everything that like is as the checking function. He wanted to introduce a new function called filter out, which the committee was like, “Yeah. Okay, so we see that this is something that might be a usability issue. This usability issue, the fact that you have to go and look it up on MDN every time isn't significant enough for us to add this alias that is essentially an inversion of filter. Can we think about something else?” This is an example of the committee being of something bouncing off the committee and being like, “Maybe we should think about this again.”

Justin came back with, “Okay. Well, what if we had something where we could group things, so you could have the stuff that was rejected and the stuff that was accepted into piles?” Everyone was like, “Yeah. Actually, that's not something you can do easily in the programing language right now. Why don't we do that? That sounds really great.” He went and he started on that proposal. In JavaScript, we have two different types of arrays. We've got your classic arrays and you've got typed arrays. He wrote the proposal for both of those.

Once he finished it, he realized, “Oh, in fact, typed arrays don't make any sense of this feature. I can't see anybody using it.” Rather than doing the consistent thing, which is doing it, even though we don't have a clear use case, we remove that. This is just evolution of the proposal. Finally, he realized, well, we've got this records and tuples proposal, and maps can be really, really useful with records and tuples, why don't we do group by to map, which is the other part of this proposal, the partner method? Now, we've got group by to map, which allows you to do the map use case. That's the full evolution.

We, in fact, made a name change yesterday evening to group by to map from group by map, again, because it's naming collision — not naming collisions. In this case, it was a readability issue, which I could get into. Yeah, that's group by map and group by.

[00:44:25] AC: What was the readability issue?

[00:44:26] YS: When you hear a group by map, what do you think? Do you think that you are grouping things into a map, or do you think that you're getting a map and you're grouping things by that map?

[00:44:38] T: I guess, between the two of the latter.

[00:44:40] YS: That's the problem, because what it does is the former. We renamed it from group by map into group by to map. The reason being group by has a precedent in other programing languages, so this is a transferable skill between programing languages. It works the same. We just added to map, because we have a convention within JavaScript of things like, to string and to, yada, yada, yada. That was our thinking. It’s not perfect, but that's where we are right now.

[00:45:12] AC: That totally makes sense. Like, oh, I get it now.

[00:45:17] AR: Sorry. You all sent me on that very deep rabbit hole of Google links.

[00:45:21] T: Surprising and off brand. I was going to say, I remember we were talking earlier about things that we wish we could add to JavaScript, or things that we hate in JavaScript.

[00:45:32] AC: Yeah. I think Alex has some thoughts on a particular thing.

[00:45:40] AR: Yeah. Okay. Yeah. All right. All right.

[00:45:44] AC: You all get ready.

[00:45:45] AR: Dates in JavaScript. That's all I have to say is that, no, no. Specifically, we mentioned this, or we talked about this before, but dates in JavaScript. If you create a new date, it's the current time and you have these lovely methods on it. We have get day, I think, which is it allows us to get the current day and that gives you a number between one and 31. We do get year, and it gives you the year as a number. That's great. Then you do get month, which gives you a zero indexed value of the month. January is zero. February is one, etc., etc. Which if you aren't expecting it, it means that you have new year’s on the first of the zeroth month.

[00:46:41] AC: This also applies though, to constructing new dates, if you're just parsing in number values as the arguments, which I did not realize at first and I was trying to make some fake data, so everything was a month off. I'm like, “Oh, so my fake data shows future dates. That's fun.”

[00:47:00] YS: Oh, man. Yeah. Date parse, am I right? Is a bug that we've had in and the compiler for a really long time, six years. Okay. Date. Date is broken in many more ways than one. We have, again, a new proposal. A very large one is called temporal. There is a polyfill for it that you can go ahead and start playing around with. The proposal’s currently in stage three. Their implementation started on various browsers. It's quite substantial. It covers pretty much anything you can imagine doing with dates and times.

Basically, someone specifically, Maggie Pint and one other person whose name is escaping me right now, came to the committee and said, this is atrociously broken. I think this was more than four years ago that she came and they've been working on it for four years. It's getting there. My suggestion would be, as soon as you can switch to using temporal instead of date objects for everything, because it covers everything that data objects can do. Yeah, things like date parse are not standard. There are various aspects of the date constructor that just do not work consistently across different browser engines, which can lead to a lot of headaches, not only for developers, but also for the browsers, because we try to do our best to be compatible with one another. The complexity of date object is just so great that we just haven't found a common operating model for data parse. Yeah. I'm terribly sorry. That's all I can say.

[00:48:53] T: It sounds like, because the new correction will be under temporal instead of the old method, then we don't have to worry about old JavaScript breaking. Is that right?

[00:49:03] YS: Yes, because we can't fix it. Because if we fix it, it will break the web.

[00:49:10] T: Are there times where you are willing to break the web?

[00:49:15] YS: Yes, that's a great question actually. We have created backwards incompatible changes, if they were safe. An example, oh, man, I forgot the exact details of this. This is ages ago. I'm also trying to do it right now. An example was how eval works, direct eval. We changed it in a backwards incompatible way to make git compilation possible. Git compilation is just in time compilation, which is what was a major advance in the browser wars, when browsers were competing to be the fastest, best thing. We did do a backwards incompatible change there.

I'm currently championing a backwards incompatible change to something called symbol species, which, if you look it up on MDN, is called a well-known symbol, but I suspect no one's ever heard of it. Please don't use it. Please don’t use it. Because it is the source of a lot of security bugs in JavaScript engines, and they tend to be really, really bad ones. What it does is, you know how when you extend an object from another object, you have that new instance of the object. Like, let’s say, you have my foo extending my bar, you'll have my foo. You can use symbol species to override the methods from my foo to return a my bar class. That will stay. That will still be there. You'll still be able to override. Imagine that you have my array and it extends array. Okay, so that's where the problem is.

The problem is that you can also do this for built-in classes. Built-ins are the classes that the JavaScript engine ships with. The number of checks that we need to do in the engine to make this behavior work correctly is extremely error prone. That's why I want to remove it, because well, first of all, it slows things down. In fact, none of the browsers optimize this code. Anything that touches symbol species, if you change the underlying object when you're returning it, we just don't try to optimize it. Because it's very, very messy.

I'm trying to remove that. That's backwards incompatible. It might not work. There have already been complaints that it's probably not possible, but we're going to see. We've broken it down into what degrees we can remove it in. I've run several web compatibility tests to see if it's even possible. That's mixed. We also reach out to developers to see if they can help us with reducing web incompatibility, so have them rewrite their code, so that when we ship the browsers, there isn't this web incompatibility, stuff like that. It is arguably more difficult to — it’s significantly more difficult to remove something than it is to add something.

[00:52:13] T: I feel like, the thing I would want to see would never get implemented even as a plugin, which is, I wish if I was writing a nested ternary or something, there are some visuals. I could see how the conditional flow was tracking. Yeah.

[00:52:25] YS: Well, and you could do something like that.

[00:52:28] AC: Just stop writing nested ternary.

[00:52:31] T: I saw Evan write a nested ternary in a Vitte demo, okay.

[00:52:34] AC: Eew.

[00:52:35] YS: It wouldn't probably fit in the language. This is an interesting part about language design, right? Because we tend to think of language design is just the language. When you talk about language usability, we in fact include not only the programing language, but the text editor and the debugger and the entire environment that you use when you're programing. That's all part of alleviating certain aspects of language as design that might not be ideal. A really great example of a tool that you don't tend to think of as a tool, you tend to think of it as a core part of the programing language is syntax highlighting. Syntax highlighting is not designed by language designers. It is designed by people who make the tooling.

Of course, it has a relationship to the programing language, but this is really a visual tool to help you understand what that's doing. Something like what you just described fits perfectly into that category of visual tools, visual aids to help make sense of programing languages.

[00:53:40] T: That would be super awesome. I hope Anthony listens to this episode and gets nerdsniple. We'll see. I guess, my big question for today, especially given the recent news about log4J is, who funds the changes for this stuff, or who funds the maintenance of JavaScript or ECMAScripts, JaviScript?

[00:54:00] YS: We are part of a standards body called ECMA. The structure of ECMA is in order to be a member, you can be a corporation that pays in to do it, or you can be a non-profit, and then you have a free membership in this organization. Officially, the payment of the development of JavaScript comes from the companies who send their delegates. For example, I'm a delegate. Mozilla pays my salary to go and work on the programing language. Also, to go and implement it in the compiler. Also, of all of my colleagues. Mozilla is covering our salaries and then Google is covering its engineers’ salaries, etc., etc. Each company is covering the salaries of the employees that are involved in the specification and development process.

Also, a lot of us who work on the committee are volunteering our time, a lot of the time. It is something that takes more time than you'd ever expect to sit through and really think through how should this work. It is a lot of volunteer effort as well. We also have many fantastic volunteers who simply give their time doing proposal reviews, testing proposals, writing rationales for why or why not something should happen. A lot of people are just donating a ton of time, and we couldn't do it without all these contributors.

[00:55:28] AC: Is there any feature you wish that you could add to ECMAScript in your fantasy, but you know in reality you would never be able to add it?

[00:55:36] YS: This is a tough question. I have various things that I want to add to the language, and there are various levels of fantasy. I believe that we likely need to introduce some form of type into the language, because that is a need that the community is making pretty clear. Whether or not that happens remains to be seen. My work in the engine centers at the moment on modules. There is really a fantasy solution for a problem that we have, which is I don't know if everybody remembers common.js, but common.js is incompatible with web modules. If you're trying to transfer directly the behavior that exists on common.js programs into the module system, you are liable to have it broken by a timing issue, or to have to deal with certain inconsistencies between those two systems.

A big project that I'm working on next year is going to be fixing the module system, so that you can have a high-performance — The problem is we eagerly load all modules and common.js didn’t force you to eagerly load all modules. This is where one of the timing issues comes from. On Mozilla, we use JavaScript to build the browser and we've got our stuff written in a custom library that implements the module loader. Can’t use it with the web, because it has this timing issue. I have a fantasy that we will actually give developers the tool to write their own module loaders, so that they don't have to only use the one that's in the browser, but they can write their own.

For example, if you want to delay loading something until the very last moment, you can do that. It's not web compatible. I don't think that is going to be possible, unless we do some really incredible spec magic. Oh, and this is not web compatible in the special way. This is, it breaks an invariant of the web platform. That's why we can't do it.

[00:57:58] T: Evan, are you listening? They said it's impossible.

[00:58:04] YS: It's not impossible. It's just if we do it, then we break a lot more than just websites. If this means anything to anybody, but there's a concept called run to completion, which is really important for the web. We made the mistake of breaking in the past. That's why we have this brand-new invariant, where you can't, shouldn't break that. This would break run to completion. That might just be a slew of words, but that's the thing that I'm thinking about. I'm thinking about this a lot right now.

[00:58:40] AC: All right. With that, Yulia, where can people find you on the Internet?

[00:58:45] YS: You can find me on Twitter, Twitch and GitHub, all under the same name, codehag. I stream myself writing the compiler, or I did up until this summer. I've been taking a break, extended. You can also watch the previous videos on Mozilla hacks. Otherwise, I sometimes tweet. I haven't been very active recently.

[00:59:07] AC: Okay. All right. Time to move on to picks. Alex, would you like to go first?

[00:59:15] AR: Sure. This week's pick is a board game that I finally have the opportunity to play. We've had it for a couple of three months, and I finally got the opportunity to play with a couple of friends and sit down and work through and figure out what all the rules were. The first time that you play a game is always the hardest.

It was pretty fun. It was very nice. It's a Tableau game. It's called Santa Monica. You are building out your beachfront property and boardwalk. You get properties, you get pieces of the boardwalk, there's activities. You have visitors showing up. At the end of the game, you need your visitors all doing an activity and all of these sorts of things. You start off the game with the VIP. As the VIP moves, you get points based on how they want to move around the board and all sorts of stuff like that. It's very fun. Very relaxing. It's also, it's nice and strategic in a very low-key way. Yeah, that is my pick this week is Santa Monica the board game.

[01:00:23] T: What is a Tableau game?

[01:00:25] AR: A Tableau game is where you are collecting a set of things in front of you. Wingspan is a Tableau game. Race for the Galaxy is a Tableau game, where basically, it's like, there are typically cards. You have cards in front of you, and you are collecting cards and putting them in front of you for points at the end of the game. Generally speaking, it's like, you need a certain set of cards in front of you to win the game.

[01:00:58] T: Okay.

[01:01:01] AC: I'll pretend I understood that.

[01:01:03] T: It's very low key, Ari.

[01:01:06] AC: Yeah, and relaxing. I should play more board games. I feel like, I would understand more of what you say, Alex, if I did. This is on me. All right, Tessa, you're up next.

[01:01:21] T: All right. My first pick is I got a long body pillow. I feel it's slightly concerning, because I think it's filled with microbeads. It said it came with a removable cover, but I recently learned that the zipper that I thought took off the removable cover was just like, there's a pocket in the side, in case I want to store things in my pillow pocket, I guess. I didn't expect to like it, but it's surprisingly comfortable. I actually feel relaxed sitting down, which would be good if I had to play a really stressful board game with people. That's my first pick.

Second pick is a game called Teacup. I just finished it. It's not for me, but I think it could be for some people. You just basically walk around and talk to people in the surrounding villages and stuff, trying to find ingredients for your tea party. The imagery has a lot of added green texture and stuff, so it looks really crunchy. I don't know how else to describe it. If you like the type of game where you just walk around and talk, maybe this is for you.

The last pick is kind of an anti-pick. I just watched this show called Hellbound or Jiok. Apparently, it was number one on Netflix, but it's a slow burn show. I generally don't like slow burn shows, but at the point where the slow burn is supposed to pay off, they ended the season. If it seems intriguing to you, maybe wait until they come out in season two. That's it.

[01:02:54] AC: This felt like one pick and two anti-picks.

[01:02:58] T: Well, you know, I know that my tastes isn’t universal. If either of those things sound appealing, have at it. I mean, Teacup is an indie game and I think it’s very charming. It’s just, l like action adventure. I wanted to do a little bit more.

[01:03:14] AC: Fair enough. All right, Yulia, what are your picks?

[01:03:18] YS: I guess. I get to do more than one. This is exciting. I'm going to do that. I'm going to pick up on the game topic and recommend a YouTube essayist named Sophie from Mars. Previously, they called themselves Kirill, and they basically are essaying from a perspective that's critical from a gender perspective, critical about the content of games and what they mean. They did a fantastic series about The Witcher, which is Geralt is the ultimate himbo. It's incredibly entertaining to watch. It's also a fantastic analysis that also goes into the books and the original intentions for Geralt as a character, as a male anti-hero in a very different sense to what you're used to, and his relationship with his daughter and all that stuff.

Really fantastic analysis. Very interesting. Very entertaining. They are now doing Resident Evil, which I've also been watching, which has been a lot of fun. From a programing perspective, since we talked a little bit about programing language design and all that, I think oftentimes, programing language design is thought of as difficult. Compilers are hard to implement. That's what people tend to come at it with that expectation. They do get a little tricky, but they're basically designed for loops of case statements.

If you like case statements, you’ll love compilers. That's all they are. It’s a basically big case statement. Well, I would recommend two things. One is a new event that's been going on. There's been two of them. They're called lang jams, where people design a programing language in two days, like a game jam. They're being run by JT, who is just fantastic and is just a really nice person. Totally go and check it out if you've got an interest in language design. You get to find a team. There is a problem that you solve. The most recent one was pattern matching, and you can go ahead and design your first language, which can be a really exciting thing, and you only have to do it for two days.

Also, if you're interested in looking at how different languages solve different problems, I've been watching a really interesting series from Code Report, where he has been doing Advent of Code in APL. He also has a talk, a reject from a strange loop for something conference, called functional versus array programing. It's a really nice representation of the difference between functional programing and array programing. If you've got an interest in different programing language models, I think you might enjoy it.

[01:06:08] T: The himbo pick reminded me, I also wanted to pick Jorts. I think Jorts wins the league. If you're not familiar with him, I'll link to him.

[01:06:18] AC: Okay. My pick for this week is related to a pick I had, I don't know, a few weeks ago, when I picked the Golden Girls API. This time, I'm just going to pick the Golden Girls, because I have recently been rewatching it. I have two episodes left in the series, and even though I've watched them all before, I'm still sad that it’s ending. You can check it out on Hulu. I will say, a lot of it aged fairly well. Some of it did not age well at all, and there are moments that are definitely super cringeworthy in today's world. It is also nice to see how far we've come in 30 years. Yeah. It's a good watch when you don't want to think about anything really. It's a good background show to have on, and I'm definitely a Dorothy. I'm just going to say that.

With that, that is all for this week's episode. If you aren't following us on Twitter, please do. We are @enjoythevuecast. Or, if you want to see our cats, though I have been slacking on adding pictures of my cat recently. You can also find us @enjoythevuecats. If you haven't already subscribed to the show, please do. If you have time and you want to leave us a positive review, it helps other people find the podcast.

Remember to share and tell all of your friends about how much you love our show. If you do love our show, please consider supporting us on, I can…

[01:07:59] T: Ko-fi.

[01:08:00] AC: Ko-fi. You can find us at ko…

[01:08:06] T: Ko-fi.

[01:08:07] AC: Oh, my God.

[01:08:08] T: It’s okay. Oscar did not even say Ko-fi correctly last episode.

[01:08:14] AC: Anyway, it’s KO-FI.com/enjoythevue. Anything that you donate there just goes to production costs, so that we're not having to pay out of pocket. If you want to help us keep going, please consider helping.

Thanks for listening. Until next time, enjoy the Vue.

[END]