Fe and the Mythical Compiler

Transcript

[music] >> Wow, thank you. Um, it's very exciting to be here. Um, so let's see here. Okay. I want to talk to you about um the mythical dimensions of programming languages, computer languages, compilers. And uh I'll share a little bit of my stories working on a programming language called Phie uh to kind of drive this. Um, so the stakes are high right now. Um, I don't have to tell you uh

a lot is changing. Um, and I just want to acknowledge that uh that this is a there's a lot of kind of potentially heavy aspects of this conversation. Um, if you've been around listening to talks about crops, um about changes in the economy, um about jobs, uh automation. Um, yeah, just stay grounded. Um, I want to share a lyric from a song that I love.

Accumulated knowledge now encompassing the globe, zeros and ones no one can touch. You must behold to understand the burden of evolving man. But may you not become stranger to God the tangible in you, God the animal in you. No service page or pin the program you came in with. Uh this is by Esperanza Spalding, a wonderful, amazing jazz musician in her song Dancing the Animal. And she reminds us to get in touch with all the deep deep layers of our experience um even though we're you know things are changing so fast.

Um, and I want to I want to frame this computer science question in in those kinds of terms myth, uh which is the stories that we tell ourselves, right? Myths myths are stories that frame our deepest sense of what's possible. Um and and they're stories that we inherit and pass pass on, pass down through generations. They evolve in a way that often drifts from factual models of the world. Um and these stories are they survive through our choosing to pass them on and tell them.

Um Lynn Margulis is like the Albert Einstein of biology, okay? And she had a kid with Carl Sagan. Um and I love this quote. If and when a technology evolves long enough, it's no longer perceived as technology. It becomes integrated into the society of living organisms of which it is now a part. And I want to make the case that maybe some of our understanding of computer science is starting to get that quality to it. We sort of take it for granted and don't necessarily understand the factual origins, but we have all these kind of stories um that are sort of melding into into uh you know our conception.

We have an urgent opportunity right now to to shape the evolution of human-computer interaction. I loved hearing about Linux right before this. Um we can't take Linux for granted, okay? Linux wasn't always so popular. It wasn't always so easy to use. Um and and open humanistic inclusive access to technologies came through a lot of struggles um that that we shouldn't forget. And now we have an urgent opportunity to participate in this story. I'll remind you that it wasn't always free to just print whatever you want. Like uh when the printing press came out, it was a dangerous technology and needed a license.

Um similarly like uh technologies in the Industrial Revolution kind of uh you know transformed economies in ways that left a lot of people behind. Um here's Ada Lovelace talking about uh comparing um uh the analytical to to the the loom. Um this is like a pre-compiler story. And then here's Grace Hopper um like early on recognizing the importance of paying attention to the to the people side of what was happening. And I'll remind you that Grace Hopper was working on compilers um and her colleagues didn't even believe that that that that

should be you know possible or that that uh that people should should even consider such a thing. Um so I invite you to reflect critically on the stories that uh that you tell yourself and um uh no matter where you're coming from um in this room, whether you're like an engineer, a designer, just a participant, a stakeholder um maybe you're working on ecosystem stuff, whatever like I truly believe we all have a role to play and um so I'm going to openly reflect on my own stories um and how they've evolved since I started

working on this compiler. But first the big picture um I like the big picture as you can probably tell. Uh we are part of the current instance in a several billion years old lineage of propagating information that has structured matter on Earth since life first emerged on it. There's an argument to be made that these conversations that we're having about uh change in our industry and and also just reckoning with AI and and computer uh just even the existence of computers that that's definitely a part of this big picture story. But that's kind of uh that's a little bit broadly scoped, so let's zoom in and talk about compilers. Back in like 2023

I was really needing a job and my friend Sean was like hey come work on this language server um for our smart contract language fee. And I was a web developer, you know? But I was like, yeah, I mean, sounds interesting and I needed a job, so let's do it. Um, I want to share some of the stories I told myself at the time, like compilers are for very smart people and I might not be that person. Um, I'm just a normal full stack web developer and compilers are beyond me.

Um, and then I had this conception of a compiler as something that just took source code and turned it into bytecode, which I don't think that's inaccurate, but that was like the extent of my understanding. Um, I also had this idea that compilers were like a well encapsulated thing, you know? Like there's the inside of the compiler and the outside of the compiler and I didn't really know much of what was going on inside. Like I had an idea of like package management, that's outside the compiler, but name resolution, I didn't know what that was and I didn't really concern myself with it if I didn't have to. And admittedly I I I [sighs and gasps] I kind of thought compilers were boring, which okay.

Now I don't think that, but anyways. Um, yeah. So here was my my game plan. I was going to take the compiler, which is this thing I didn't understand, and I was going to kind of bolt on the language server, you know? And that was going to do it. All right, great. Um, at the time the fee language was in the middle of a really deep refactor. Um, uh, my colleague Yoshi was like pouring himself into upgrading Salsa, which I'll tell you about in a second, and the high level intermediate representation and the trait analysis.

Um, by the way, Salsa is really cool. It's like a uh, a database crossed with a incremental computation engine that lets you reuse information that you that you compute inside the compiler. Um, anyways, here's a quote from 1979 that I think also kind of gives a a a sense of how we were approaching things. In those days, writing a compiler for a new language was believed to take many man years. So we were like, yeah, okay, this should be taking many man years and let's take our time and do it right.

Um, but the economics shifted on us and the our expansive timelines had to get crunched and we agreed to a six month time box to try and like finish our refactor and relaunch the language. Um, and we did it. Um, but yeah, obviously we couldn't have done it without LLMs, okay? Um, and this was around the time when LLMs were just starting to get, you know, kind of pretty good, but still they they were clunky and they had a lot of issues, but we got some benefit out of them clearly.

Um, but as we were doing this, um, these questions were whispering like, okay, if we can speed this fast, then anybody can do this, right? And if people just start using these tools like what good are programming languages and compilers going to be in a few years? And like what is our what value does our language actually even have? Like and like are people even going to be writing code, you know? Um, what what's the use of a new language, right?

And other people were also telling these stories. Um, we had some nice dramatic competition on the social media um, around like fee language and Solidity and Viper and it was like really thrilling and lots of drama and good free PR. Um, that was interesting. Um, and yeah, okay, so but things are shifting now in terms of of um, how we're looking at the the landscape. Like it's not so much about which language is better. Um, this Colonel Elliot is one of my favorite influential um, computer scientists.

And he has this talk um called a Galilean Revolution for computing. And here's a quote that I like from it. Um as with the scientific revolution begun by Galileo and others in the 17th century, the correct computing revolution elevates us from guessing to knowing. Um he also says conventional programming is is precise about only about how, not what. So if you think about like the ancient models of of uh the ancient European models of the solar system, they had all these really weird, wacky uh retrogrades and everyone was getting super complicated and then they flipped to heliocentric uh model and everything just snapped into place and became super

simple. And Conrad Elliot is saying that's happening right now in the world of programming languages. And this is without AI, okay? Um so whereas in the past you you sort of like make a big list of how you want the computer to do something, now it's possible to actually specify exactly what you want it to do and then derive the instructions for how it should do it across platforms. Um and so our new competitor for our language um is Lean 4, you know, and all these other formal verification languages.

Of course, like the story that that um that we should be competing like for language domination is a story that I am questioning. Um yeah, I think I think we can we can come around and and and get together on this. Like things are changing and um it's important to understand like where do we fit in? Um what should we do? Um I do want to say I I our team still believes that that our language has value. Um and I want to share a little bit about about the Lean language.

Um for one thing, Lean has this effect system that lets you organize that separation of like how the programmer uh does what it does versus what you want the program to do. And even though it doesn't let you currently prove semantic equivalence between those, it at least lets you kind of like get uh a good organizational grasp on the on those two aspects of the program. Um here's a story which is that there's formal verification languages and then there's like old school languages like Rust. But I think the Curry-Howard correspondence um which if you don't know what it is, check it out. I think it actually kind

of reveals a spectrum. Like um there's the conventional typed languages on one hand and then there's like these newfangled formal verification languages on the other. Um but it's not just like one or the other. Um the Curry-Howard isomorphism kind of suggests that like there's something special about about type checking like at all, you know? And if you can express useful semantics in a type system, then do it. And we're kind of hoping that the fee language sort of will move into the in between space further and further towards the the formal verification side.

Um uh yeah, and we have some some ideas for how to do that like some uh compile time metaprogramming stuff and um you can ask me about that later. Um and then also we are acknowledging that the EVM has never been the only component of Ethereum applications. Like there's always been at least like the clients and the validators and they're not running on the EVM itself. Nor is the EVM like the center of like the broader open tech ecosystems um that are you know crops aligned, right?

So um I really like the CAP theorem. It says that um you know when your when your application uh when the nodes in your application split up like do you prioritize consistency or availability? Um here's a little handy chart of the full spectrum of the kinds of decentralized applications you might see. Blockchain is over on the left, like the World Wide Web in the middle, and then there's all these other applications, decentralized applications that don't assume consensus, right? They don't impose a consensus mechanism. And we would like our language to be actually useful for targeting all of these because real applications actually have components in along the full spectrum.

So we'd love it if if it would be easy to reuse critical code across these components of the of the language. So practically that means like you might have some hash function and you have a nice implementation and you want it to be used in you know on chain, you know in a ZK validator as well as like on a client maybe. So we're working on multi backend support. And yeah, I just want to check in with some of these stories like the one about compilers being like this well encapsulated little pipeline.

I want to propose to you that that actually compilers have always been like these interconnected things that share tooling and representations and that we have a lot of work to do now to further integrate all the amazing ideas that have been developed over the last decades. And LLMs can help us do that very quickly. One of the languages I think is really cool is the Unison language, which kind of takes sort of contemporary ideas in package management, like content addressing and you know imports and all this and like brings them into the compiler into the name resolution. So you can actually like import directly from a content

address of some normalized code. So I think that further building out this web of of computer language tooling is like the future. And I'm imagining that that maybe we can find like all these awesome ideas from over the decades and just start incorporating them into our new um uh compiler and language tooling. Um let's see here.

How are these stories evolving for me? Um I think everybody has an opportunity to engage in shaping how human intent gets expressed into the digital systems, right? So compilers are like kind of the legacy of that, but all these higher levels of abstraction that are more familiar are should also be part of the conversation. Um higher level programming like web programming is just a fresh iteration of the same evolution that produced compilers in the first place. And you can see a lot of resemblances and echoes.

Um and then uh tooling has always been a part of compilers, like a primary object of compilers. It just gets kind of like fermented and and and integrated till you can't recognize it as external anymore. Um yeah, I actually did have to get into the actual compiler to implement my language server, believe it or not. Um and then compilers are not boring, okay? They're like part of this ancient story. Um and then how do LLMs relate to compilers? Let's get straight to the question. The story I'm telling myself now is that um a compiler is and I want to refine this, it's an amalgamation of of tools that sort of is coalescing that generate,

interpret, and constrain the dynamics of digital systems. So these are the kind of functions that I'm working with at the at the moment. And on the top here you can see like the generative, constructive um kind of functions of compilers like um analysis and and transformation of representations, um generation of instructions. And then on the bottom you can see things that constrain like diagnostics. Um and I would say LLMs, they belong right up there with the rest of the the generative things, right? They can generate new representations and analyses of our programs.

And um yeah, classical programming languages um we don't have to ditch them. Like if just cuz you get a new synthesizer, you know, it doesn't mean you throw out your tuba, right? They can both be in the band, all right? Um so I had a great conversation with my colleagues from Argo the other night and Masa who works on on HEVM sort of laid it out like this. Um from here on out like old school languages are just are just uh IRs to express how the the the the program does something and we can just generate um like operational semantics uh from from these these new tools. So I

want to just say Argo Collective is uh is the the the little microcosm that that our project fee lives in and there's all these other projects and at the Collective we're learning how to connect them together. I hope in a way that sort of um resonates with what's emerging. Um I also want to say if you want to actually look at fee language um we have this fee builders challenge um with some little prize money and we really want to see what people do also with agents. So if you want to um test out our language we just added uh native backend and we're trying to get the the wasm backend in too.

Um but yeah. Uh and then one more song lyric at the end. You know the stakes is high when we're talking about the vibe. Okay, vibrations. Um that goes for how we treat each other and also for vibe coding too. Um [laughter] so yeah, thank you. >> All right. Let's give our speaker a big round of applause. You know the stakes are high when we've got the vibe. I like that ending on a song, beginning with a song. Ladies and gentlemen, let's go right to our Q&A. We've got a few minutes. We've got some great questions in, by the way. Let's go to the first one right on top.

What if in the future we can directly write codes in assembly? Why do we need compilers? >> Great question. >> Great question, yeah. >> I mean, we can kind of do that now. There's people doing this, and that's the generative part of the compiler, right? Generating potential implementations. But um our compiler tooling also brings us all kinds of analysis tools so that we can interpret what the program does and constrain it to make sure it's doing things correctly in the way that we want. So we can we can still use all that that classic tooling from the compiler.

>> Mm, great answer. Let me go to a question. I think there are some beginners in the audience. They asked this one, and I think it'll help me as well. If you had to explain it like I'm five, [snorts] Micah, what is a compiler? >> Yeah, it's just like a way to talk to computers. >> A way to talk to computers? >> Maybe through computers? I don't know. I'll think about that. >> All right, we'll come back to that. A way to talk to computers. That's an easy way to look at it. Just like a web browser is a way to talk to the internet. Okay, let's go to another question. This one's getting quite a few votes. Um if you draw inspiration from McCarthy and Conner, I I believe that's Conner Elliot, why imperative and not functional PL?

>> I'm not sure if I understand um well, fee is very much a functional language. >> Ah, I see. >> Um but yeah. >> Yeah, maybe you can clarify. So fee is a functional >> I I want to understand what what you're saying uh after this. Let's talk. >> No worries. He'll be around after this as well, especially during lunch, too. You can always chit-chat with our speakers. Next question. Should we start designing languages that LLMs can understand and generate more reliably? >> Um yeah, sounds great. I mean, that's the idea, right? And also, I think it makes sense for programming language and just computer language people to start getting into what's happening in the LLM community,

right? Like open LLMs are arguably a a just more open source stuff, you know? And diffusion LLMs are getting really good, so check those out. >> Yeah, yep. Fantastic. Good answer. Few more. Let's see if we can wrap it up. AI codes directly in bytecode and properties U1 are formally proven. Seems to already work very well for EVM contracts. What is an example where it still fails? >> Yeah, I mean I think where it fails is mostly just in the cumbersome, you know, quirky emergent nature of it. Like like we we um we're still figuring it out and there's a lot of like collective learning to do about how to model our programs well and

and how to understand the the the bridges between the semantic levels. >> Right, got you. Okay, little bit more. Let's see. How much of fee source code is is generated using English AI LLM as the new programming language? Wink. >> Oh, yeah. I mean a lot of it. Yeah, like we're doing Yeah, we're doing we're doing uh agentic engineering for sure. >> Yeah, there's nothing wrong with that, right? >> Well, I mean we got to be careful. So I'll quickly share that like one process I've been appreciating is like just making draft implementations, but like don't merge that in and and pitch it until you've had a chance to talk with people about it.

>> Right. >> You know, and really understand it. >> I like uh How much of the code is the question from you? If you had to give a rough percentage. >> Like the new the new code is like we're using all agents, but we're building on a foundation that was handwritten very carefully. >> Mm. Fantastic. Of course, you're welcome to talk to Micah after this and ask him in more depth and detail. We've got just a little bit more for the Q&A. Let me see what else have we got here. Mm. What about fee on parallel parallel, sorry, SIMD/ MIMD Flynn's taxonomy M-Q-sheets. Okay, this is beyond my level of knowledge, but I I believe you understand. Yep.

>> So like I don't know about the specifics of Flynn's taxonomy machines, but I do know that um that some of the experiments we're doing with the new um metaprogramming stuff will allow um carrying like abstractions about parallelism like down into the the back end. Um so for example like I've done some experiments generating WebGPU and and hooking up the high-level um like expressions of of parallelization um like functional expressions that I that

Conor Elliott uh came up with into the the back end and it's really awesome and fun. But that's that's coming soon. >> All right. All right. Wow, he managed to finish all his pieces. >> [music]