Key Points From This Episode:
- A discussion around semicolons and who’s pro and who’s against (and who’s neither!).
- Why it’s important not to break the internet: a funny anecdote about SmooshGate.
- The considerations to take into account when naming a function.
- Why Tuples are such an exciting prospect and their role in wrap-around vs incomplete infinite grids.
- How the team understands the difference between splicing and slicing.
- The idea behind pattern matching, and how it will reduce the cognitive load on developers.
- Why most programming languages are written in English.
- Why the caller and colleague functions were deprecated.
- Array by group: what it is, why it’s interesting, and the readability issues it is facing.
- When Yulia is willing to break the web.
- Where you can find out more about Yulia!
- Today's picks: from board games to body pillows to YouTube essayists.
“[Pattern matching is] 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.” — @codehag [0:33:19]
“It’s significantly more difficult to remove something than it is to add something.” — @codehag [0:52:10]
Links Mentioned in Today’s Episode:
- tc39: How We Work (GitHub)
- Reduce/Reduce Conflict, gnu.org
- Record & Tuple Tutorial, tc39
- Kolates? (non-English programming language conference)
- Function.caller (deprecated), MDN
- Why was arguments.callee removed from ES5 strict mode?, MDN
- Temporal Proposal, tc39
- Symbol.species (please don’t use), MDN
- Companies scramble to defend against newly discovered 'Log4j' digital flaw, Jenna McLaughlin (NPR)
- CommonJS, Wikipedia
- Run to completion scheduling, Wikipedia
- English Linguistic Imperialism in Programming, Hannah Chung (PagerDuty)
- Coding Is for Everyone—as Long as You Speak English, Gretchen McCullough (WIRED)
How to find Yulia on the internet:
- Twitter: @codehag
- Github: codehag
- Twitch.tv: codehag
- Compiler Compiler, Yulia Startsev (YouTube)
- Mozilla Hacks: Yulia Startsev
This week's picks:
- Yulia Startsev
- Sophie from Mars, YouTube
- The Ballad of Himbo Geralt: A look at Netflix' The Witcher | Witchermania, Sophie from Mars
- Lang Jam, JT (GitHub)
- Advent of Code 2021 in APL #1!, code_report (YouTube)
- Functional vs Array Programming, code_report (YouTube)
[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: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:40] T: If I'm sending a winky face, semicolons are in.
[00:01:44] AR: Yeah. Yeah.
[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: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.
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.
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.
[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.
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: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: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: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?
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.”
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?
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.”
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.
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: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.”
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: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: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: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: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 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.
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.
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.