 So yeah, so this talk is called It's All Functioned Variables, and it's my perspective on what makes programming programming. So I'm Zypher, it's pretty much what everyone who knows me knows me as, because all my friends are on the internet. But since we're all friends here, you can call me Michael because Zypher is really hard to say. And so I love community stuff as part of this. I'm one of the co-organizers, I'm the CSSConf AU, and I run one of the, with a friend of mine, I run one of the bigger frontend meetups, or CSS specific meetups in Melbourne called Melbourne CSS. And I'm a big fan of open-source stuff. I've been doing it for probably six or seven years now, and the most relevant to this, I guess, is I work on Libsass, which is the C++ implementation of RubySass. They try and give SAS a bit of a speed boost. And I am now the project lead of NodeSass. So this is not a talk about SAS. I'm not gonna stand up here and tell you how SAS is awesome and why it commits you to try and use SAS, because it's not that kind of talk. This talk is actually a story. And it's a story about how my life got flip turned upside down. So I'd like to take a minute, just sit right there and tell you how I became a real programmer. So I wanna start with a quick question. Can I, everyone, just raise the hands to start? And how many of you would consider yourselves programmers? And how many of you have written a function or a mixing or if statement in SAS or less or JavaScript? So if you don't need those things, put your hand down. So who is not a programmer who has never written a loop or a function? Awesome, so you're all experts. You're practically done here, but you can see this is a story and we're gonna go back to the dream scene where you go back to when the protagonist was like a little child. And this is kind of a little story about my background in programming. In Australia, we have a thing called the pen license. So in your final year of primary school, so grade six of about age of 12, every week you sit kind of a test. And that test is to test your handwriting skills and your cursive, because at this point you're only written in pencil in school. So you have to earn the privilege to use a pen. And so I was the last to get this and I'm pretty sure I got it purely out of obligation not because I earned it. And the funny thing about this is before I was allowed to write my homework in pen, I was fluent in two programming languages. So it's kind of this thing where I've gone through this journey where I've been writing code for about 15 years and people being full should be paying me to do it for about 12 years. So I started, I was really lucky to start at like stupidly young programming. And I was writing in variations of basic and then I kind of discovered this HTML thing and I've used a notepad and I was pretty excited. And then we hit like the first years of high school and we started working on things like visual basic and Python and looking into C. And that were interesting to me. So that later on I got obsessive interactive thing. I wanted to build things that moved and animated and you could do really cool things with. And this were like things like Macro Media Flash which before Adobe was Flash, was really exciting. It's like animate things and see them come to life. Then comes the university and come to university and graph to learn Java. But in all of this time I started doing PHP and like that was my gateway to the web. Like PHP was so approachable, so easy. And then I got a job and that job required me to learn jQuery. Not JavaScript, jQuery. I'll be honest about it, like my first foray into like front end was doing a lot of jQuery with PHP. And this same job meant I did some C sharp and how these things too related, I didn't know. People were paying me to do these things. So, I have code up there that's C sharp but I don't recommend anybody using. Later in that job I started hacking on some Ruby code. And then like this transition happened over the space of like two or three years. I just really got back into the web. I wanted to move towards the front end. That's where I saw the harder problems and where the fun came into it. And then it's like a really short burst of time. You know, I was learning CSS3 and HTML5 and JavaScript and then when you start doing these things you start using node because you don't even use your grunt and your gulp. And then if you're doing a lot of front end performance front end stuff, you know, you want to do performance so you start looking at like your engines of like how a partial engine X work. And then later on in the story you see Cess gets so unwieldy, you're like, ah, how do you do some sass? It'll be awesome, be fast. You know, you just skip to today and we're using, ah, react, it'll fix all my problems. It's great. And like, this looks like a crazy amount of stuff to be doing, how many languages? And it's not to say anyone is fluent in all these things. Like, it takes them like 10,000 hours to be like fluent in a language, understand how language works. But a lot of these languages are a thing called C-style languages. Like languages evolve over time and a lot of these evolve from like the C roots which is from like 1989 is like the first major, major C I think, 86. So this is C++ code but it's just because strings and C are hard and my slides won't begin off. So it's kind of like a simple image URL function. We see them in Compass. We see them in like a bunch of sass libraries. And you take a base image and it's like, ah, you know, I want to find an image to foo but in my environment my base string might change between different production. So we just kind of, you know, we got a function and image URL, we're passing a string, a canning two strings or a coding that string. And like all is well. But if you look to like JavaScript, like the difference here is so tiny. Like we've removed type so you no longer saying this is a string but just you put the word var to say this is a variable. You know, your function is almost exactly the same. You're only calling with the same syntax. You know, you then move to like PHP and it's almost exactly the same. You've dropped the var, put dollar sign. And this is how people are able to like pick up new languages. Like it's always your first one that's hard. You know, we look at things like sass now and sass is exactly the same. Like we kept the PHP dollar signs and in front of function we put app symbols. But all in all, these things are kind of the same thing. Like there's a lot of learning curve. Like every language has its own ism which is like this is how you should program in this language. You know, in JavaScript use prototypes. You know, try not to use classes, use decorators. You know, PHP is now, you try and use lots of classes but procedural if you can. And then we come to like the next level. These are all C based languages. This is like Ruby and they've just dropped all superfluous stuff. You know, you don't like a var as a dollar sign. You don't like to have the function key where it's replaced with def because it's shorter. You know, your return statements are optional. But you're calling the function in the exact same way. You're looking at all these languages. You can kind of figure out what's going on pretty quickly. So it's kind of gets you thinking. It's like, how hard can all this stuff really be? There are a lot of the ideas of programming from this kind of branch of languages which is like most modern languages now are all kind of C, you know, children of the C, descendants of C languages. So it gets pretty easy. Like the difference is really syntax and is in this but you can get there pretty quickly. So over time, a lot of my, I gave a lot of talks for a lot of years and did a lot of open source work and the tone of those projects change from like backend stuff to like front end stuff. And I start going to meetups and talking about this stuff and how exciting it was. And the tone of my conversation started to change. I started getting questions like, are you a designer? Why don't you do some real programming? And this was super weird to me because like I'd written production code for about 10 years at this point in a lot of these languages. And in the front end, we have a lot of the same problems. Yeah, we have the same maintainability, scalability balance, you know. This code works, but can I maintain it in two years time? Can someone ask to read this code? No, so the same kind of operations issues and performance issues, like is this using push memory? We have paints and layouts, but on the server, you have memory consumption and CPU cycles and am I blocking requests? But the thing we do have in the browser you don't see on the server side is that we have non-standard environments. Like we're writing code as one of the most hostile environments. You know, on the server, we're predictable. We have probably a bunch of machine running a version of Ruby or PHP that we know and like we know code is gonna run there because that's our environment. And here we're looking at browsers all over the world, very networking conditions. Like the problem set seemed a lot harder than the back end. So it was kind of weird to me that people thought this is like an easy child's play kind of thing. And it's hard to change people's minds without understanding their point of view. So you talk to them for a while and it kind of came to clear to me after a while that this was all a side effect of something called the Dunning Kruger effect or Dunning Kruger. And it's kind of two parts. And the two, and it's kind of like people who don't really know a thing or kind of know the basics of things can extrapolate from that. And look, I know the basics. Obviously the harder parts aren't that hard. It's like not knowing enough to know how hard something is. And a lot of us may have experienced this earlier today with our Lea's talk. And you see, ah, it's a pie chart. We have a circle. We use another circle. Like, how hard can it really be? And you start digging into details and realize it's actually really insanely complicated. But you have to give it that time and effort to get there. And the other flip side of this is people who really know something, yeah, conversely, people who really know something kind of overestimate everybody else's skill and say, well, this is easy. How come you don't know how to do this? Like, this has come second nature to you now over time. It's like, ah, well, we should be doing these things. It's really easy. These are the standard people don't see front-end as a really hard thing. If we look at the DAO, the DAO's web design article came out 15 years ago, since then we've had like, every couple of years we get something new like CSS3 and HTML5, then responsive development, then preprocessors, when that came, build chains like grunt and gulp. Then the big focus is on a web path. And then the extensible web manifestos and now we have like fluent comps and CSS comps. And then the 60 frames per second thing and now it's like HTTP2. These are a lot of things to keep up to date with if you have not touched front-end since IE6 or just kind of toyed around with some, seen some demos, toyed around with torels in your time being. So it's a really good article from Alex Sexton a while ago called front-end ops. And it talks about what it is to be like a front-end developer. And I hate quoting things, but I couldn't think of a better way of saying this. It comes out like a front-end ops engineer, if someone who cares about external performance, they're critical of like every new request and they're constantly measuring performance and page load time. They own everything past the functionality. They're the bridge between applications intent and applications reality. And their responsibilities like handle things like migrations of new versions and external internal dependencies up to date, security and stability or the gatekeeper's application. And this is like a wide berth like front-end. It's not just CSS and JavaScript. It's responsible for every byte from your server side code to the user and all the ramifications of that including the rendering performance after the browser, which we'll hear talks about later on. So we skip ahead now to modern era. And in 2011, I started coming to good 99 designs. And at this time we had no front-end team. The UI is called ad hoc. It's kind of evolved over like four or five years with a bunch of backend devs hacking on UI when they needed it. And we've gone through multiple rebrands. So the further you went through like certain pages, you can see older and older versions of the site. Just weird archeological digs, pretty interesting. So in 2012, we had to tackle responsive rebrand. So as this we decided, all right, let's fix all these issues. Let's really get serious about this. And we forked foundation. I started our own internal framework. And this all we kind of bet big on SAS. Pretty early on we ran the problems with foundation and we started building our own UI framework. And with this kind of stuff, when you start bringing in SAS, you start bringing in asset pipelines. And if you start doing a lot of Ruby stuff on asset pipelines, this is like early days of grunt. You realize things get really slow. The developer experience is slow. The UX is slow. Library loads don't really work. And we can no longer do like in request compilations. So 2014 comes around and now we're like multiple teams. And with multiple teams, we have multiple asset pipelines because each dev has the wrong way of doing things kind of forked in previous generation. And we just had more CSS, which means slower and slower compilations. Like at one point we're down to like eight minute compilation times on a fresh compilation. That's just our SAS and that was kind of crazy. It was, I'd had enough. I'd heard of Libsass and I made this card. It was kind of like a pipe dream. I labeled it, I have a dream that one day we'll have Libsass compatibility. And it really started with one to do item, it was just maps. And I figured if we have that, we're so close. It felt like that was missing. As you can see from this card, like it wasn't even the beginning what was missing. And this goes on for like another page of like all the little bugs we came into trying to get Libsass working and out thing. So it was kind of like this excitement and then this like disappointment. And we thought we were close, and then we weren't. You know, it was missing so many basic features that like polyfills weren't even possible. The development of the project was really slow. It was one person working on it in there on like company 10% time. It wasn't really going anywhere anyway quickly. And it was in C and this is kind of a problem that I thought could be worked around like surely if somebody rewrites this thing as a node developer, rewrite everything in node because node developers are rewriting everything in node that frontend devs no node. They don't know C, they'll start writing more node if we make it generic enough of a tool people start adding features in and like where would be one person's job would be a community job and we'll get that really fast. And so this is kind of my idea. I kind of, I got really serious about this. I did a lot of studying on compilers and interpreters and how it all works internally. But I kind of put it aside. It's something I kind of really thought about but didn't really have the motivation to start working on yet. So in 2014, we ran the first CSS Comp for AU in Australia and we had to hang out with Chris Epstein who is one of the core contributors to Ruby SAS which was the SAS at the time. And I used this opportunity as one of the organizers to practically stop this person. I was following him around asking him a question what are everything he knew? Like how could I make loops? How could we get there? Why was loop SAS, why was SAS slow? How could we make it better? So later that year, there was a thing called Camp SAS run by Hampton Katelyn who was the original inventor of SAS and the inventor behind Lib SAS. And at Camp SAS, Aaron Leung took and he was the person who actually writes Lib SAS. And I talked to these people and I asked them why is this thing in C? Like can we do this better as a community? Like what is the end goal here? And there are a lot of reasons for writing this in C now that I know and it was the right decision at the time. But I talked to Hampton Katelyn about my idea of like how could I write this in Node? Like would it be better if the project moved faster? And his answer was you can do this in Node but just know this is like a use of your life. Like there are edge cases we don't even know about. I think we don't know about. And so I asked him why is this slow? Could we get faster? Will it ever be ready for us? And he came back with this which someone else mentioned earlier today. The intersection of people who write C++ and care about CSS at this point was exactly one person and that was Aaron and he had a job. So I went back to Australia. Really kind of thought about my Node SAS idea and eventually figured I just bought the bullet. Like I've done a bunch of languages of toilet C, like how hard can C++ be? But I didn't know C++ and I was afraid of it. Like to me, this was a realm of real programmers. People who write C++ write games and operating systems, like Windows and DOOM and this is like really intense stuff that I'd never even, I'd shied away from, like legitimately scared. So this was kind of a big off-putting thing for me. Like how can I contribute to this project? How can I get it where I wanted to get and not run Screaming for the Hills? So we figured we should jump into it, see how it goes. And so it's getting started. There's a lot of things in C that I vaguely remembered from like my time at university and playing around with it. And it's things like linters and linkers and the fact that it's compiled language. And this is different from every language I showed earlier was like interpreted. So you just kind of like run a command and it ran. You have to compile anything. There was no binary distributing about operating systems. If you had Ruby at work, they had PHP at work. But the cool thing about this is I realized, it's something that didn't have to know. You don't have to know these things to get started on these projects. They don't really matter. You can generally run like your make file and it would just work. So the challenge was make files. Like these are really foreign syntaxes. If you ever saw something on C, you do like slash configure and then make and then you have a library. And no one really know. Like a few people know how this worked. It's definitely not front end. It's now becoming a bit of a thing. But you know, you kind of link these things back to things you know. And make was kind of like grunt. In fact grunt was heavily inspired by make. It was the make for the front end. And it kind of made it easier. Once you knew like the idea of like how this thing worked, how that your knowledge, I think you have preprocessed directives. There's another scary thing. And if you look at code, you kind of, it seems simple enough. It's like a hash and include. Then you have like angle brackets. Sometimes you have quotes. And the approach interchangeable and that's kind of confusing. And they're not just simply includes. Like they not, you can think of them like as imports because in this case, include isn't at the import. It's the most common preprocessed directive. So it's generally why you have to worry about and screaming through the lip sass list code. It was the only thing that really kind of mattered. And the difference between like, sorry quotes and angle brackets is you think of like a bow or a node, a browser fly, load paths. You know, having quotes means load this directly right in this directory relative to where I am. And the angle brackets mean, all right, well, if you can't find it here, go through my load path through the whole like require just thing or the node require and eventually find this thing in my path somewhere. So once you knew that was kind of pretty straightforward. And the other kicker is that this was strictly typed. None of the languages I'd used earlier outside of the C was strictly typed. And by saying I did see, I did see if like, I read a book on it and probably hacked on it for three months before I got bored with on the Python. So this is kind of a similar example we saw before. And you see, you're declaring what this thing is. You're saying base URL is a string and that matters because you're passing strings around and you're getting strings back, adding strings together. And this is essentially the same code here. So there's a lot of really great advantages in type safety that I'll go into later. It's kind of not the greatest thing for everyday work, but it's great for what I have to do here. And I made getting it this project really easy. They may have things like header files. And these are also kind of, never really understood them. They're kind of scary. And in Libsass, they mixed like, code that shouldn't be in header files. It's a header file, so maybe even more confusing. But if you think this is like your bar.json file, it's like, this is essentially kind of like dependencies, the thing that I'm gonna use later. This is, assume it'll be there and if it's not like really nothing's gonna happen. So you can kind of overhead it and nothing's gonna be bad about it. So I wanted to jump in and get this map. So I forget if I get maps, we're there. We're not in the way there. It's gonna be beautiful and everything's just gonna work. So if you don't know what maps are in SAS, we're gonna quickly into it. So CSS has a thing called the shorthand properties, which in SAS are called lists. You know, you're at one pixel solid red to list of three items that we commit later and rule throughout CSS. So we can get an item out of a list like this by calling the nth, getting the first item out of it. I like most programming languages, SAS is one index space or zero index space. So you have maps. And maps are like lists, but you kind of think of the long hand syntax of CSS where it's like a hash map or an array in PHP. You can kind of just get a key and get the value out. And you have a similar API where it's like, ah, get me this to the key. Like I can have the same flexibility as lists but I can name the thing I'm getting, which is much easier. So I wanted to get started. And the use way to get started is to write the thing we called SAS spec. SAS spec is a lib SAS test suite. Essentially it's like you write SAS and the CSS you expect. If it works, everything kind of magically works. So even if I can't get this sorted, I can write this PR and get somewhere. This got merged and it was PR44, which gives us to show how slow dev on lib SAS was at the time and how quickly contributors are in this project. And when this got merged, I think it was really important to celebrate the small wins. Like even if I couldn't do this code, I gave someone a leg up to be able to get there at some point. But then I really wanted to get to the C++ side of things. I figured I had some time I could solve this problem. So I followed an idea of like CPDD, similar to like TDD, and see if you can follow what this actually means. So this is real code from my original PR and it's worth noting that if you have a look at these things, you'll see a pattern. As anyone can spot the pattern on like how my map code works. How about now? Or this one. If you'll notice, everywhere you see the word map, you see the word list above it. Because maps are essentially lists, but rather than having like an integer-based index, you have the most part strings, but in sass or any object. So I did what was called copy, paste, driven development. I grep the lib sass, I grep the lib sass source code for the word list, duplicated it, changed it to map, and in some cases, the logic was a bit different. Instead of getting integer side strings, they're kind of like copy and pasted code where I saw what strings looked like and I just did it and it compiled. It was amazing. And of course maps didn't work because I haven't read the pos yet, but I got to compile and that was really exciting because that is hard. So then I went to the next step of my development which was cedd. And so when you get an error in a good error in sass or this is now lib sass, you get like a really descriptive idea of like oh, this thing is out of bounds, like I know where to look for this code. It gives me an idea. When you get errors in c++, it generally gets me like this. Which is like, this is broken. Figure it out. And there's a lot of that, especially when I know what you're doing. And eventually I figured out I could use gdb and get a lot of cryptic output with a lot of really scary looking things like syscalls and symbols and OS archive. But this looks scary with two or three commands. I now have this stack trace, the thing we had in original code. I thought the most easy thing to read but like it tells me that somewhere in this stack trace at eval, I had an error. I want you to discover that things got a lot easier. But it took a long time to get there. It was a lot of like what is happening? Why is this happening? Just screaming at the compiler. And this is what I call compiler error driven development. And this is the advantage of lib sass being statically typed is if it went to compiled, it generally worked. So I have like segfolds where you reach into memory that wasn't yours. If you could get it to compile, because it was strictly typed, things eventually just kind of worked. And that's kind of my philosophy today. I keep bashing it until the compiler stops yelling and then the test pass and magically it works. So ship it. I wrote a PR with the code I'd written over the last month of work. And foolishly it got accepted. People were happy and this got announced at saskon and everyone was excited. We all kind of piled it together. It was great. There was one kind of big problem. It was that I write my C like I write my sass because that's what's mapping it to. So a map get function is native. And if you ever get that a hash, you should know that if you get a key, you can just kind of pull that key out in constant time. But because I copied all the list code and list codes were lists or vectors and not hash maps, my presentation is kind of iterated. I did this where it's like, ah, here's the map and here's the key. Look through all the things in this list. When you find the key that matches, just pull that value up. So it's maintained like two vectors, one of keys and one of values. And this runs in like any complexity. This is super slow. And the bigger your map gets, the slower this gets. And I knew this was slow. On the PR I said it was slow. I was saying we probably should have merged this, but this will get someone who knows what they're doing closer. I think I'm pretty sure in the PR I said I don't write C++. Like you can do better, but you took it, you started. But they shipped it anyway, and I'm happy to do it. And this is because of the LibSas philosophy at the moment. And it's like performance is a feature. We wanted to, our main goal is to get LibSas to where SAS is. And performance comes mostly because like C++. And it's awesome. This is magically fast with no work. Once we're there, we'll start doing work. But it took very little time for this to happen. And this is actually me opening the bug, but I realized when I ran this over my code, at my where I worked, it was actually slower than Ruby SAS. It's significantly slower. Because if you do bad architecture and bad engineering, it's slow. Like C++ isn't going to save you. And I came out and said, I was very honest about this and said, like this is going to be a problem when I wrote it. And Aaron, the main developer at the time said, this is fine. C++ problem will deal with it later. Let's just get this shipped. And given our goal, that was like a great mentality. I'm just kind of where I go into like, yeah, this is linear time. Longer this is, the slower it is. And there should be a constant lookup. If I get a hash and I get a value out, just be the same about how big the thing is. And I go into this and say that performance shouldn't be an issue. It's an issue because I'm a terrible programmer at C. And like, this is my first poor question. Hopefully it'll get better. So I spent about another month or so on this, hashing my head with some help from some friends. And I'm sure we've all seen like this thing, generally referenced to CSS. But more generically, it's like things I don't understand are hard and why they're doing this thing to me. And I've had this in every language I've learned. I've had this seriously in C++ and in SaaS. But we kept iterating over weeks and months and eventually we had a new PR. And this shows like the before and afters. And you can see that we were running in 11 seconds where Ruby SAS was running on 1.2 seconds. So it was slow to really heavy map stuff. This PR got it down to like under a second which was faster than Ruby SAS was still insanely slow but we're happy that it was faster. That was half our job right there. So we got this shipped. And this is like the second or third version. Now this number is like 200 milliseconds. So it's crazy fast. That took me more months of work of finding things I still didn't understand. A lot of I still copy and pasted it in development but I tell you all. And there was partying. We had maps. Everyone was really excited. Almost there. And I thought, yeah, my code will run now. We're so close. And 30 or 40 bugs later, we finally got there. Skipped it today. We're now in the present day. Coming towards the end of the story. And through a series of poor decisions on other people's behalf, I am now a core member of Libsass. Don't know a lick of C. So this is, well, it's not true anymore. C is less scary. I'm also the node SAS project lead now, which is one of the main gateways to Libsass. The great thing about Libsass being in C is it's embeddable. So we have bindings in almost every language. I mean, it's nice to rewrite all the SAS logic because that is the use of your life. If I can test it out. And I'm up here on stage. Like people thought it'd be great if I'm across the world to talk about how I turned SAS into C++. We're just great. I think we should all do it. Don't be afraid of the big boy languages. You're a programmer if you can write SAS. So obviously this is happily ever after. What does this mean for Libsass and for programmers everywhere? Libsass is almost a parody. We keep saying this so we'll get close. I will get there and we will. But as for my designs, I've been on holiday for four weeks and during my holiday I got an email the last project got a photo of the Libsass. So now 100% Libsass. A year and a half, a year on after I started on Libsass development. And C++ is slightly less scary. There are parts of the code I don't touch when I do a copy and paste and everything kind of works. And I get there and I gotta thank these people. This is Hampton and Chris last week or two weeks ago in San Francisco at the Mixin. Or these are the people who made this possible. The philosophy of like, ship the code, then do better. If you care enough, you become a contributor and you'll start to care more. The more you use it, the more you'll care. And luckily I'm actually running under time. So demo time. Gonna try this live coding thing, wish me luck. And we're gonna live code C++. Yeah. And I'm gonna show you the true copy and paste driven development. So we have a, in Libsass, we removed the function called compact. It was never part of the spec, but it was encompassed originally. And the company who first wrote Libsass needed compact, so this chap didn't need it. And we eventually decided to remove it because we wanna be a SAS engine which means you can't do things SAS doesn't do. So I figured, all right, let's create a compact equivalent. And we can see the code here in SAS. We take a list. I knew it was a display, but I do. Oh, all right, that is not 1080p. I guess if it's gonna get with VGA, we'll go with it. So we have the compact function. We create a new list. If the list is empty, then we just return the blank list, so good. So a compact does remove falsely values, things that look like false, which in SAS is empty strings and null and false. So we kind of loop through this list. We sign the value and we check if that value is false. If it's not false, we add it to our array, add it to our list, then return the list. Pretty simple. We have a test here, like a bunch of items in a list. And the results, what we'd expect here is that false and null are removed from this list. So we just run. Cool, we can see false and null are removed from the list. Actually, actually I'm not a liar. A recompiling lib.sas, exciting stuff. Cool, so this is running the SAS code. But if we want to, you know, writing these languages in the interpreter is kind of slow. So we want to write it in, if you're doing lots of compacts, you want to write it into the native language. So, you know, if you were so inclined, you could remove this function, try and run this code, and you see we spit out the compact string because in SAS, CSS has functions as well, so the function is not defined. We assume it to call the native function like calc or background URL, sorry, URL. So, all is well. So, the obvious place to start is the file called functions.cpp, and this is how I was developing in the start of lib.sas, that's a completely legitimate way to do things. So, there is a function similar to compact which is index, and it'll kind of find the first thing in the list. So, if we just kind of search for index. Yes, we have the index function. This looks close to what we're trying to do. You know, it takes a list, loops over that list, returns something at the end. It's pretty close to what we're trying to do. So, it's a copy-pacers, this is how it's done people. So, we're going to close compacts, that's the spring and not the compact. We don't need a value, we're taking a list so we just get rid of this and delete some code here. I have no idea what this does, but sure, it's safe. Go with it. What we do need is a new list. So, let's kind of have a look, how do we create new lists? Yep, this looks good, let's copy that. Let's create a new list here, we'll call it results. That's not compact, I do that every time. So, cool, so, the length is going to be different so we can just assume that it'll be zero. I'm going to keep the same separator. Right, so what do we want to do here? We want to, if we look at our SAS code here, we want to assign the value, in our loop, we want to assign the value to a value. So, let's go, how do we create things in this? Let's look at expression, expression v. Let's look at expression, value. I wish I needed the star there. Equals, cool, yeah, the value with L, looks legit. Cool, so now you want to, since you want to test if this is true, right? So, if this does have a value, we'll take our results and just add this value, I guess, got that. And then we'll return the results. So, if we have a look at this, if we don't have a list, we're creating a new list, I suppose, we're creating a new list, we're going to return, we loop through all the items in the list, we assign the item occur on the app to a value, if that value is truthy, we add that value to our new list and return that list. Looks pretty similar to this code, here's our loop, here's assignment, here's the if, here's the append, push it into the list, and here we return. Looks legit to me. Odds are, this won't compile, let's give it a shot. Oh, I think it'll compile. It didn't work, so we know we forked a thing called index, so it's kind of search for index in our code, and so it happens. These don't look relevant. Index, I'll see, that looks familiar. So let's duplicate that and change index to compact. Look in, it's a little too complicated. After far we're just in, I'm pretty sure we save the, oh, here we go, more indexes. Duplicate, oh, there's one more here. I think we're looking good. Yeah, I think I'm good about that, let's go. Recompile this, so it happens. Ah, so we still have false, but we don't have null, so we've got progress. Yeah, that should have worked, so. So, live coding for you, or partway there. But I'm not gonna try and fix that on stage. So, we laugh and we giggle, but that's how a majority of Libsass development happens. Don't tell your managers if you wanna keep using Libsass, they may have beef with that. Cool, so, I'm Zyfa, you can find me on that on anything, and stay sassy.