#120 Aver AI-Native Programming Language with Szymon Teżewski

Hinzugefügt: 2026-06-03

[00:00:01]Welcome to Happy Path Programming. I'm Bruce Eckle.

[00:00:04]>> I'm James Ward.

[00:00:07]>> All right, welcome Happy Path Programming. It's been a little while. I was traveling a lot >> and some traveling.

[00:00:13]>> Spent some time on the river.

[00:00:15]>> Yes.

[00:00:16]>> And so it's been good, but it's beautiful spring in Crusted. But >> do we have We don't have any conferences or retreats or anything coming up to announce. So >> not really.

[00:00:27]>> Yeah. to just normal to normal life.

[00:00:30]Here we go.

[00:00:31]>> Yes.

[00:00:32]>> Well, today we've got a good one. So, we've got Simon who created an AI native programming language and we've been diving into this whole new area of of new languages emerging uh that are really centered around making the AI more efficient, work better. Um the thing that that uh is really interesting for me about Aver is that it couples some uh a lot of things that we're interested in like effect systems but then also adds into it uh this like validation side which which I'm really interested in in because I think the as Aver says right on the website it's uh you know easy for the AI to write the code but then how do you validate the code? How do you how do you validate that what it wrote was what you intended, >> which is ultimately all we ever care about in a piece of software?

[00:01:21]>> Does it >> does it do what we want it to do?

[00:01:24]>> Yeah.

[00:01:24]>> Yeah. And how how it gets there is Yeah.

[00:01:27]But I'm I'm also fascinated with this um the fact that you have trimmed out all of the um I would call them the human affordances in a language which I didn't even I wasn't even really conscious of but my understanding is that aver says all right if we are doing any sort of looping we'll use recursion if we're doing any sort of decision- making we use pattern matching And I'm not sure about this, but um is everything is is all are all values immutable or is that?

[00:02:05]>> Yes. Yes. It doesn't seem so on the surface, but yeah, it's fully.

[00:02:10]>> So you're [clears throat] making all the values. So basically all of those extra features we realize, oh those are just for people and the and and my I mean this was just an experience that I had because I had a set of examples that I was trying in different languages and I was having the AI generate the code for these examples and it seemed to me like it did the Aver version faster and I'm thinking well maybe because it doesn't have as many choices to make. It's not looking at oh should I use a four or whatever. It just goes oh I'm using there's one way to do these things. So is that >> yeah maybe give us the the just high level what is what is a and what are your what were your design >> what's your philosophy [laughter] for it? Yeah. So like ever is language meant for AI to write code. But that's not the only that's not the only thing because my assumption was that like writing code becomes cheap and becomes even cheaper now. AI is doing that. You don't need a lot of sugar like syntactic sugar because AI can manage yeah on its own. I we don't need all this syntactic sugar for the humans and and >> the syntactic sugar was meant for humans but there is like the twist to that which uh which I think is very important in a is that this sugar it's not really meant even for AI to to have only one choice limiting choices because that's also a valid like design design thing yeah but it's more like it's limiting the surface you have to review what what was written in a later. So there is like minimum >> so enabling the human to also review quickly and have not have to understand you know complex type system things and and you know other use a for loop here versus recursion and >> exactly why do I have ifs here and there or maybe like tenorary operators and stuff like I can I can write this all with match I can match on values I can match like of some types or whatever and it's just one thing there is one one keyword but like I don't I didn't want to minimize keyword that was not my goal really uh I wanted to make it really easy to review and I don't know if you have uh if you have managed to seen but I I've added a lot of these intent uh layers to it so you have like every function which is not trivial and that's like uh not more than one line Maybe let's say it has to have like this glorified command let's say which says what it what it does really uh and all the functions which are not pure have this kind of effects attached to it uh and also we have like I have uh decision blocks which are built into language so something like ADRs uh I have chosen this and not that and those can also point >> you architectural design records.

[00:05:31]>> Yes. Okay.

[00:05:32]>> Yes.

[00:05:33]>> So those are decisions blocks in in in a you can basically say yeah I this dates and this person has chosen or this AI has chosen this and not that and point to specific symbols in the program. So it's like checked later that the function you're referring to it's still there. It hasn't disappeared or something. So things that in the past would have just gone into comments maybe to explain why a particular design >> or maybe they're rotting somewhere on consu because that's what I've usually seen. Yeah. As a software engineer.

[00:06:06]>> Yeah. Yeah. And so being able to have a record of those decisions that's in the code and actually is code is >> actually is is codeish. Yeah. is not maybe like fully you can't have a function in there like function doing something but you can point to stuff.

[00:06:23]Yeah.

[00:06:24]>> So that you can cross reference things so that those decisions don't go out of date and stale because it was just in a in a comment or something somewhere.

[00:06:33]It's it actually gets validated against the the type system.

[00:06:37]>> So can you have can you build more sophisticated types?

[00:06:42]>> Not really. types are really uh simple in aver you you have generics but in a sense that uh you can have a list of whatever and you can have a map of lists of whatever etc. uh but you don't have like generic functions with your types that's impossible. So here you have write two or three functions for for something because that's not yet supported. I'm not fully against that but there is argument not to have it.

[00:07:14]The language is really simple on many many levels and adding generics is doesn't feel like the uh something I will do soon. But you do have some some more advanced type system things like you have value dependent types. Is that >> accurate >> with with like like constructor assertions or something?

[00:07:33]>> Uh I I I tend to I tend I've chosen this old ML path in there. So you have a module and module is its own world and it's uh can expose uh can opaque expose the type. Yeah. So it can be used uh in the system in other modules >> but uh it can only uh export a constructor for it.

[00:08:01]>> So it's not it's not revolutional. You don't I don't have really dependent types as as the uh as they are now used.

[00:08:09]Uh but yeah you have old ML trick built in.

[00:08:14]>> Yeah. So it's just like a a constructor constraint is like your >> constructor constraint. Yes. But because language is so straightforward uh I can use them later if we talk about verification and stuff as dependent types.

[00:08:33]>> Basically you are not writing them as you do in lean or or or Daphne but they can be lifted to once.

[00:08:42]Um so in the native effect languages that I have looked at it seems like most of them use handlers for their in other words when you call an effect it jumps into a handler which has a continuation. So rather than a regular function call so what are you doing for that?

[00:09:06]>> I don't have handles. It's it's much simpler in a to be honest. Uh when I was preparing, I was thinking if I should even call them effects in a because uh they're not algebraic effects. That for sure. Yeah. You cannot handle you cannot uh >> there's not like a composition of of >> Yeah. You don't have composition.

[00:09:30]Exactly. I was looking for that word.

[00:09:32]You can you don't have compositions of effects. they are more like uh transitive capabilities kind of things. So function has >> more like a way to demarcate pure functions from from impure functions.

[00:09:45]>> Yes. Yes. But it's also transitive. So what I mean by by that is that uh every function calling effectful function >> inherit >> has to declare that effect or more you know like closure of of of sub effects of all the functions. So >> so there is a little bit of an algebra on on that composition where if you if you touch a function that that writes to standard out and talks to the network then both of those get compos like in like additively >> and I have also this granular effects uh which are much more granular than uh IO in Huskell or whatever because I have like HTTP uh terminal console and so on but they also have like sub effects so you can only declare I don't know HTTP get or post for that function.

[00:10:34]>> Yeah.

[00:10:35]>> And you cannot like you can shortand to HTTP but compiler will nag you that okay uh that's too broad. You shouldn't be using that you are just using get >> but then there's then there's some almost like security model around that that you have as well which is like I only want to allow a get to this host or something.

[00:10:56]>> Yes. But uh I wouldn't call it security because someone will jump on me. I think it's more more of a safety feature.

[00:11:04]Yeah. Uh and I'm not saying security because you have to trust the host here.

[00:11:10]Yeah. And the host language. Uh >> so it's more like a safety barrier for for your AI writing the code. So it doesn't like it's not declaring that you can call HTTP. So if you do it's impossible like it will it will be the type error. Yeah.

[00:11:28]>> Yeah. So I'm not um I mean when I start thinking about AI languages and realizing oh because of what the AI can do, we may not need this or we may not need that that we have in traditional languages. So, so [clears throat] I'm I'm I'm looking at this and and you said, "All right, we're tracking the effects, but we're not using handlers."

[00:11:55]So, which may be okay because the AI is able to do more things than I know about, but what do you do with the effects that you're tracking?

[00:12:08]Uh yeah we have couple of things like so so first of all they have to they are transitive so they have to go to the very upperest level so that's the first thing so they're >> it's like function coloring but beyond as you're tracking >> yes >> so async was the original function color and now you've got a range >> which I dislike yeah which I I don't like async because it's >> it makes the coloring but like both ways you have async await and I don't like something like that. Here it's much more simple. Yeah. Uh it does one additional things that's maybe not on topic, but it forces your code to not have many like transitive levels with the effects because it gets out of hunt. Yeah. So it tends for it feels dirty. So it makes you have this uh pure core. Yeah. And effectful shell.

[00:13:04]And it's like I didn't know when I was starting either that that's the outcome.

[00:13:09]But AI on its own is like okay I don't like that I have five levels of of effects transitioning. So I will just I will just architecturally get rid of that.

[00:13:23]>> Yeah.

[00:13:24]>> Yeah. Yeah. And there is one more thing about effects enable that all of the effects they are like predeclared by comp compiler. you cannot define your own at the moment. Uh but you can record and replay. So when you when you run the program, you can record every effect that has happened and it's stored in a JSON file and you can replay that later.

[00:13:48]>> So that's a convenience feature.

[00:13:50]>> So you can so you can verify that you get the same results.

[00:13:54]>> Yes. Yes. You can verify that the effects were fired in the same order and consumed in the because Yeah. Some of them are presumably the same values.

[00:14:05]>> Yes, all values are also stored and is there like different levels also that for example you haven't consumed all the events like there is more in the there is more in the file than you your program has has >> you can like diff the diff two runs and validate.

[00:14:22]>> Yeah. And that's an interesting approach because like if you have an effect that is a random number generator, the programmer needs to swap in a random number generator their own that generates non-random numbers so that they can do the testing. But you're saying, well, actually all you have to do is record it and then if you replay it >> replay Yeah.

[00:14:47]>> then then then the programmer doesn't need to go to all that trouble. So it it simplifies that process.

[00:14:55]>> Yes. And at the beginning that was the only mechanism to test uh effectful functions. But then I I've added uh like verify blocks for it. And verify blocks are something in a probably needs its own explaining and uh everything. So >> before we get into the verify, there's maybe another uh thing that's nice about having the explicit effects in the world of WOM, which maybe you've done, maybe you haven't yet, but in the world of Wazi, you can expose like, okay, this particular block of functionality has these side effects and you can express that through Wazi and Wom components and so that then the other side that's the consumer of that thing can decide how it wants to actually implement um those pieces. So you because you've already defined the sideffecting pieces, you could probably create the the accurate wazy u view of those those sideffecting functions.

[00:15:55]>> Yeah. And I was I was playing with that to be honest. Uh, I did uh was preview one first, but I didn't like what came out and I'm on wasi preview two already, but uh I'm not doing this granular thing as I should be doing yet. But that's on on the on the wish list, let's say. So, >> yeah, but technically it would be possible because you've >> technically that would be Yeah, because right now I'm I'm not yet exposing it as library in in wasi preview. Yeah.

[00:16:27]>> Uh only as uh as application. So I'm like importing effects not uh not yet exporting let's say.

[00:16:35]>> Gotcha. Yep.

[00:16:36]>> And the different targets. We were we agreed that we liked the approach of having the >> VM and the the native and the WOM outputs. Um I think that's one of the things that that you probably you would be more familiar than us about the challenges of Rust and you know the long compilation times and by having the VM it does create that short iteration loop with for the AI to iterate quickly um and you know be able to do some some validation before you actually go to producing and linking a binary. Um >> yes that would be but that would be really problematic for AI and because waiting times as you said uh but I really started with interpreter as every every every small language is starting uh and then I've added VM which will at the time like 100 times faster or something and it became like the main uh main runtime uh and as you said I'm having this code cold gen for different uh for different things. So there is rust code gen. So you can basically compile to rust uh to to wasn't and it's like garbage collected was I started with my own memory and everything but it's then it occurred to me it's >> like that's that's not needed runtime deal with all that.

[00:18:00][clears throat] >> Let's let that be as native in this in all of these targets as it possibly could be.

[00:18:06]>> That was my assumption. And like this garbage collection is already on pretty much everything. So it's not so new.

[00:18:13]>> That's >> So you had to implement your own garbage collector for the VM and for the native output >> and yeah. Was that a given design constraints of the language? Was that an easy task or a hard task to like like like figure out how to implement the garbage collector?

[00:18:32]for for for rust colon I don't have to have uh garbage collection because it handled by rust all those all those all those things in rust rc and so on so it's like at compile time it's checked for for correctness yeah in rust and >> does it actually generate rust code and then you let the rust >> compile generates like a rust rust project for you with all the modules even uh looking as as the ether ones but you have to compile it uh to Rust uh and in VM I didn't really go for a real garbage collection. You may argue [sighs] because I I went with like memory lanes, but that's the topic on its own because of the simplicity of the language. There is a lot of things that are not like in every regular language. For example, it's easy for me to uh to track uh when something should be and it's imut immutable as you said. So it's easy for me to say okay so this like TCO loop has ended and I can discard all the things >> your escape analysis is much more trivial.

[00:19:46]>> So it's like escape analysis on different yeah on couple on couple different levels. So like you have this very local lane of memory then you have like TCO one then you have one for the handoff and you have for the hand of from the functions so return values etc and you have like the okay this stuff lives forever pretty much because uh that's that's how the program is is done.

[00:20:11]>> So how much AI were you using for the architecture design and implementation?

[00:20:19]That's that's a really good question and I don't have a good answer for that because it depends at which stage of a yeah because at the very beginning I I came up with idea pretty much on my own and then I like was ping ponging that idea with AI without even implementing it at at the at the moment and then I went for implementation in which like probably 90% of code is written by I I won't be saying no. I I I don't want to lie to you guys. It's it's it's true.

[00:20:54]But uh like every decision there there is mine. There is no single decision that AI has made for me. And I've uh like I've I've argued a lot for the decisions there are in neighbor because AI tends to >> I don't know where it gets it from.

[00:21:14]Maybe from the training data. That's the obvious uh explanation, but it tends to to force you do some stuff. It's >> going to steer you towards towards something it's familiar with and what you're >> and I don't know if familiar is a good word. It's [sighs and gasps] it's it's just I would have to come up with specific Oh, the specific example is it was forcing me to have like a Z3 uh invariance everywhere.

[00:21:46]Yeah. And he was arguing that's the better choice for the design and it's like a common topic really and I didn't really want that because it seems like there is another language layer at at your language which I really disliked and so on and so on. So there is a lot of topics like that that AI tends to force me to going in that direction but I don't like.

[00:22:07]>> Yeah. Yeah. So you're you're building the you're building a the actual like parser lecture VM all that kind of stuff in Rust and is that right >> and then how are you are you working in in some kind of markdown spec for the actual like PL design or how do you do that piece of it?

[00:22:31]Uh I hate markdown. So no not markdown spec but it's coming from uh usually from a long conversation with AI and like arguing for for my uh my design decisions really and the only aver code I has I have ever really written is like exa example codes how I want a specific thing to look. So I'm I'm writing a ver code sometimes to to to for the design and that's that's that's very common to be honest. I haven't written a single program but I've written a lot of lines to show the direction of how I want it to look >> in in some ways your your spec is the like code examples like this is what I want the syntax to look like.

[00:23:17]>> This is what I want. This is what I want. How can we achieve that? And then I have to learn a lot because I that's the first ever compiler I have written uh or AI has helped me write. Uh I probably I wouldn't be able to do it so quickly and probably I wouldn't have chosen Rust because I uh I like Rust. I can read Rust but I find it hard to write Rust. So uh probably I would have chosen other language.

[00:23:48]We were curious if you had any intentions of self-hosting a at some point. Um I know >> self hosted.

[00:23:55]>> Oh, it is.

[00:23:57]>> Yes, it's obscure option in there, but there is an interpreter in a in a >> so so the a lot of the aver code is actually a today.

[00:24:08]>> Uh that's not the VM. Uh there is yeah I was talking about targets and one of them is called selfhost really. So every like run function a run and a or maybe only a run at this point. Yeah, a verify is not yet ported is running uh a a in a interpreter and that interpreter right now it's uh it's going through this rust code then so >> uh it's really a to rust compiled and attached to to cargo so so it's fun but [sighs and gasps] >> that was just showcase yeah that it could be done >> so what's your Um, do you look at it in ter like because we're used to languages that have standard libraries?

[00:25:02]Do you look at it that way? Do you go, "Oh, we'll develop a standard library."

[00:25:06]Or do you look at it and say, "Well, no, the AI will just generate whatever it needs to generate >> or is Rust your standard library?"

[00:25:13]>> Yeah.

[00:25:14]>> No, Rust is not my standard library. uh and I was there is a really small uh standard library right now and it's all the functions you need at at at uh a I would say at the moment. So it's like uh integer from string and stuff like that.

[00:25:35]Yeah. So so >> collection libraries and >> collections libraries.

[00:25:39]>> Yeah. But I to be honest I've been pruning those this standard library more than expanding it at the moment.

[00:25:46]uh because I had like two ways for example int integer to string and string from integer and I was like well there's two ways to do thing uh I should leave just one of those and so on and so on and I >> you then like replace that duplication with your lifting functionality and then you can like rip out you know the the stuff that was unnecessary boiler plate because now you had >> it's just it's just boiler plate uh for for standard the library at the moment and I also started with map and fold on list and I've removed it at some point.

[00:26:26]>> Huh. What?

[00:26:26]>> So there is no >> Yeah. What's what's your what's your like collection transformation things that exist then in the standard library?

[00:26:35][sighs and gasps] >> Nothing.

[00:26:38]>> Just I'm not I'm not joking. I'm not joking.

[00:26:42]>> Pattern match you have everything. Yeah, you can derive everything pretty much everything. Uh, and you also don't have closures. So people will already like why why why is that? But that's also the >> AI doesn't need them. I guess >> AI doesn't need them. That's a syntax sugar. And I keep explaining that to people and people get angry about closures. I saying about no if statements, no loops and everything and then closures somehow, you know, light people up. I don't know why.

[00:27:14]But I mean really all those all those funk doors on you know any any type of data class is really just syntactic sugar for recursion and pattern matching right like so you know you've got >> I hope it makes easier for me to write code yeah when I'm writing code by hand but doesn't make does it make review easier really like there is you don't have one more function somewhere in the module because that's what us usually it saves just one function which is named right now and you can reason about what it's doing without looking at it even.

[00:27:50]>> Yeah.

[00:27:51]>> Yeah. That's the part that I keep having to rewire my brain around. It's like does this serve humans or does it you know is it something that is essential that the machine needs you know and and what can we take away and still be able to to you know maybe it's even easier or better for the machine to generate code. I wouldn't say it's easier because I was testing that that part and uh because there are other languages meant for AI and the main purpose of those languages is to make it easier for for AI and that was not my design goal to be honest. Maybe [sighs] maybe it happened for other reasons. Uh but what I did I called it design by inconvenience really. So I'm removing all the stuff that's not necessary but other people's tried for example okay this language is minimizing the number of tokens that are used by AI so you have like one uh one letter variables or something or they not named and etc >> and it's hard for the human to review.

[00:29:00]>> Yeah it's really hard for human to read and validate. Uh so my assumption was okay AI is writing it. It doesn't need a lot of sugar. It makes everything easier for me those uh targets as you said and everything. Language is really easy.

[00:29:15]There is no closures, no not not a lot of things that can go wrong still. It's complicated stuff but not as complicated as regular languages. Yeah. Uh and yeah, that just happened. And real quick before we get on to more deeper on validation stuff, uh there there was a few interesting tools that you have that you provide that are in the same vein.

[00:29:39]So you can do a context and a shape which could be like helpful for the human but also are really helpful for the AI to just understand the structure of things, the interconnectedness of things and give us maybe a little more detail on those pieces.

[00:29:57]>> Yes. So has these non-standard uh functions the compiler compiler has or or commands. Uh one of them is context and it's like it's pretty obvious when you think in in introspection about it.

[00:30:13]So what the context is is AI doesn't need to read all your code or human doesn't need to read all your code. It's just it needs the context for AI. It's called context because uh of AI really. Uh and the context is like minimize view of your program. And that's was really easy to do because of the design uh of the language design. If you have this uh mandatory intent everywhere with all the functions, if you have those effects in there, it's really easy to export that without the function bodies. And usually that's good enough for AI to reason about what code is doing. Yeah.

[00:30:56]>> Yeah.

[00:30:57]>> So I can strip all the all the f all the all the code from it and it's Yeah. And it's still readable. Uh and it also does this this little trick uh in which you can um say what your budget is. So for example, give me this program for 10 10 kilobytes or something because that's my, you know, that's my window for AI I can spend.

[00:31:23]>> Yeah.

[00:31:23]>> Yeah. Or focus on specific function.

[00:31:26]That's another one because for example, yeah, I want to start with this function and all its offsprings whatever it's uh it's using. Yeah.

[00:31:36]>> So you kind of like >> Yeah. Yeah. you can traverse down the context graph uh and because the context will give you the related pieces and so you can be like okay we're working here but now we're going to switch over here and work so now go get the context for this thing. So it's like lazy lazy context uh loading as you as you traverse.

[00:31:57]>> So you may start with like overall view of whole program and then if you focus on specific modules or specific functions you can dig deeper or give more budget in kilobytes if you wish.

[00:32:09]Yeah.

[00:32:09]>> And AI is doing that. I I've seen it doing like there is cloth skill I've made for it and it's using it really really often and I find it really funny because I think codeex was doing that because I use clo code and codex usually both of them and codeex uh like this a context command so much that it's tried to use it on the rust code of compiler and then okay that's not working on rust it's only a thing and that's was quite funny to >> so what's your concurren currency story.

[00:32:43]>> Oh, concurrency.

[00:32:46][gasps] I really wanted to have some concurrency in neighbor that I didn't want uh it to poison the whole language kind of a thing and I think coloring like async await would be problematic. Yeah. Uh it's a lot uh to reason. I don't like reading code with a single weight. Uh I didn't go with effects because you can use effects for a single weight but I don't have such complicated effects like you have in Z or or or somewhere.

[00:33:22]>> Yeah. Uh so I'm I made this very simple observation that uh if you have a taple with two functions or three or four it's up to you you can reason about if those what the what those functions uh are doing is independent or not.

[00:33:50]>> State between them or something. Yeah, there is no shared state between them.

[00:33:54]Uh, and but they might might be effects in >> there might be effects and like I didn't want a compiler to guess for you because uh sometimes you can you can do like five HTTP posts because they are safe to do. Sometimes there aren't. They have to be done in order. Uh so it's asking you to to say if those are independent ones or those are regular ones and they have to be in order. Uh and you have just one gimmick at the end with exclamation mark which is saying those are independent and can be run independent. It's more like this hasll par that it's a hint for the compiler kind of a thing. So it can be done in any order but it doesn't have to. And right now only rust codeen is really doing that in parallel. Uh but yeah that's in place and uh it was really funny to wire it with the uh record and replay if you can imagine >> because then you have to reason about which branch uh it went on and so on. So it was problematic to do but I managed to do that. So, so it's like uh it's working.

[00:35:14]>> Did you go to to as far as like describing the like algebraic laws of the side effects so that you could determine if if something was commutative or associative or whatever.

[00:35:29]So that then you in the type system could could derive the the the parallelization capabilities of a given side effect or I was on that path but I like I gave up. It's uh as I said it's not always uh there are languages doing that. Yeah that's the first thing already and they uh try to reason for you a is not that smart. It just tells you, okay, that might be problematic for some known shapes. Yeah, for some known shapes, it can say, okay, you're doing uh this write and read here, and that might not be what you want. But it doesn't stop you from doing that at this point. I didn't want uh when I have to review that code, that's one thing you have to really dig into what those functions independent independent product independent tap thing are doing.

[00:36:24]That's one thing you have to focus on reviewing right now.

[00:36:28]>> So, it's not going to prevent you from having some race condition foot gun. But it does give you the >> ability to specify things such that if you've >> indicated that this is a place that I need to be careful of a race condition, then the compiler is going to help help you validate that. Yes, it will it will say that might be problematic, but it won't stop you from doing that because it occurred to me that there might be valid scenarios and you you're never smarter than uh than someone writing the code. Yeah.

[00:37:01]>> Well, and often times when you're talking to an external system, it's really up to that external system what its constraints are. You know, it's like is this request item potent? Depends on how the server defines it, you know.

[00:37:13]>> Yes. Um you you um use the word shape a lot and I think you have explored >> this idea that pieces of code have shapes.

[00:37:27]>> Yes. Yes. I really like that word and I to be honest I'm not sure if it's a good one in English if you hear that as a as a language designer because to me it occurred to me while reading the a code that the code or maybe I'll start with the anecdote from Python because I work also with Python a lot and a lot of Python code is kind of shapeless to me at the moment and what I mean by that there is no strong core like the I I don't immediately see what it's doing. I >> You can't look at it and see, oh, that's a triangle. That's a square. That's a >> Yeah, that's a triangle. That's a square. Okay, they're composed here and there. And maybe something is duct tile or whatever. And I have to to reason a lot. But when I'm looking at a code, it occurred to me, okay, those functions are usually this or that. So this function is match.

[00:38:27]Yeah, this function is recurrency. Those are uh this one is recurrent with the other one and it's obvious when you're looking at the code because of the language limitations again. Uh so I I've explored this idea of shape a lot and as you asked before uh there is even command for that uh called a shape which tries to it's not really guessing I would say it's seeing that this function is only doing a single match in in in in here. Yeah. Or this function is doing like [sighs] like the pipeline thing in it. Yeah.

[00:39:06]>> So like checking something for error, checking another thing for error and if it's okay returning some some something.

[00:39:14]Yeah. Uh or other stuff like I think I have I initially had like nine or 10 uh such shapes but I went with 14 at the moment. Uh and they are classified. Uh and I also made this kind of tiny discovery of mine that when looking at the whole modules or folders, you can reason about what architectural layer that code is by the shape of like his histogram of shapes of the functions.

[00:39:48]>> So for example, I have this pure callish domain stuff. So there won't be a lot of effects in there. Yeah, there won't be >> uh there will be a lot of math. There will be some recussion in it but not not a lot of effects for example and so on so on. So I and here the guessing part comes in that you can say okay this code statically statistically sorry statistically should be this layer of your program like domain or something you can redefine what those are uh so so I'm not forcing my numbers on you can redefine what those should be for your own program but you can basically have this additional layer of checking if the shape of each layer is what it should probably be.

[00:40:39]>> Yeah.

[00:40:39]>> Yeah.

[00:40:41]>> And so some examples of those shapes are like you can have a transformation layer >> would be a typical kind of architectural layer or you can have a business logic layer and by looking at the the the uh the shape of something in Aver you can you can make some statistical assumptions of what that architectural layer or shape is.

[00:41:04]>> Yes. Yes. Exactly. And I've started with that and then it occurred to me that there is [sighs and gasps] one more layer to those to this shape that sometimes there is two functions which are like interwined. For example, this function is only serving as the entry point for the other one. So I have like the for example Fibonacci one uh real one which does like the recussion in it and I have the other one which is just guarding the uh the input for example and I'm also kind of explore that idea right now a lot >> okay so let's talk about the validation side since that's I think one of the things that really differentiates a is the ability to define not just tests like so we've types and we've got functions with explicit inputs and outputs and effects. Um, but then we we need to be able to validate that our intent was actually fulfilled. And so there's layers to that. You can write uh a kind of more imperative assertion style test for a given function. But then you can also write a proof using and underneath the covers you can export or use lean or daphne. So yeah, give us a little more on on that whole piece of the machinery.

[00:42:24]>> Yeah, I I've started with really simple idea as always. So the really simple idea is I want tests collocated with the code and that's was meant to serve uh a sim similar purpose as this intent. Yes. So some I don't really have to look at the body of the function. Sometimes it's easier to look at examples. Yeah. you have them at uh you have the function and the a format is putting the the verify functions below the just below the function so I can see what it's doing on input and output side and it was meant only for pure functions but then I realized that there is more to it uh and there could be possibly more to it so you have this uh example once as you said so it's the it's the simple verify but you can also have like verify uh verify law I called called it law and then it's uh more like there is python thing called crosshair uh but there is a lot of it's it's a bit like property testing it seems on the surface a bit like a property testing so you have like a given integer being 1 2 3 or 1,000 yeah or integers from 1 to 10,000 or something these functions and you can also of guards in there like given the the one integer given the other one and when one is larger than the other one or something like that I'm invoking that function and knowing something about the output. Yeah. And you can define a lot of laws that way really. So I don't know a plus b is equal to b plus a and so on and so on.

[00:44:08]So a lot of functions could be a lot of laws could be uh explained that way. It's a very simple way to be honest. It's nothing nothing >> different than so while the syntax looks similar to property based testing you actually can can derive a proof essentially from from what >> there there are two two more levels to that because at the ether verify so what is running VM or or or was just checking the examples that's it so it's the it's the fast and fast and easy one and then I >> uh real quick so on in the VM you you essentially do like property just property based testing with with >> yeah in VM it's just property based testing nothing nothing fancy >> uh but then there is hostile option to VM to to verify which does substitute those values for you >> so for example you said that's integer and you provided some of them and here are the nasty integers for you >> uh so I'm checking your your law against uh against nasty nasty stuff and that's also happens for the effects.

[00:45:22]>> So for example because you can stab effects in those functions also when you verify uh effectful functions you are just writing the function which is stubbing it. So for example when I'm doing the disk read text uh it returns this or that uh and >> more like the effect handlers like so in the verify blocks you you can create the the mock implementation of what the what the effect yeah but uh and you can use those like in verify those those example simple ones and in loss yeah and in loss they only in laws they are lifted I I would say only in laws in hostile mode.

[00:46:02]Uh I'm substituting it for uh for bad things again. [laughter] So your this burning clocks going other other sides like rewinding clocks and so on or uh or random always returning one and and so on. And it says okay that's that law of yours might not be a a real law.

[00:46:27]you might be missing guard or you might just want to provide examples and those are not uh those are not examples. Uh you said it's it's something more than that. Yeah.

[00:46:40]>> So that's this this intermediate uh level of of checking and there is one more which [snorts] is exporting the exporting it's it's like a code gen but uh there is a separate command for that which is a proof and a proof is uh doing a daphne or lean project for you out of a code.

[00:47:03]>> Yeah. And then in Daphne or lin uh if you have example example verify which are not laws it's just by example which both Daphne and link can easily do but if you have the slow ones they are again lifted and they're lifted to for all the integers proof.

[00:47:25]>> Yeah. Uh and about the effects those are also lifted uh but they're lifted through oracle functions if you're familiar with the term. So it means that for every possible function uh of clock which might be returning whatever the clock is returning that holds true.

[00:47:47]>> Yeah.

[00:47:48]>> Yeah. Yeah.

[00:47:50]So in your in your lift to a actual proof, do you do you have to use AI to to actually derive the proof or do you can you do it totally deterministically?

[00:48:03]>> That's that's a really good question and I was exploring that idea too. So uh right now no I'm not using in there I'm again exploring the shapes of the functions.

[00:48:16]>> Yeah. uh and uh I I wouldn't say it closes everything because it doesn't uh but a lot of a lot of stuff is uh closed for you. A lot of proofs can be closed. So I'm again identifying shapes of the laws and shapes of the functions that are tested and I can say okay this function is oh a good example is guarded uh like I have Fibonacci and Fibonacci is guarded by something and then in lean this this guard is lifted to subtype uh for example >> and that's like a lean what what what lean person would write in there. Yeah.

[00:48:59]Uh or the the the opaque uh the opaque natural uh module which only has the constructor uh that is is guarding it. It's also lifted to to to this subtype. Uh >> so yeah, it's doing a lot of tricks like that and it's closing a lot of proofs. I wouldn't say that's ideal. So some of the proofs are left for you to to prove with AI help maybe or >> I will someday find a way to close all the gaps. Possibly no, not never. But >> is there any way for the AA compiler outside of AI to know if something is closed or not? If a proof is closed like >> right now I've I've added this uh pretty recently. I've added that it's not only uh like compiling to transpiling to lean or daphne but also running it and when it runs it it can check okay I I've closed this this uh this match >> the lean or dafne can do the analysis on whether >> yeah it's run it's run against lenor daphne and I'm also exploring the idea right now of [sighs and gasps] um because some projects are doing the thing in which like they export report to Lenor Daphne and they try different strategies in there and see what closes.

[00:50:23]I don't like that idea that much because I I'm like the code is in a very so simple. I usually can reason about it better than just guessing. But >> some some Daphne stuff you you you have like the fuel budget in there and sometimes just raising this budget helps you close the proof. Yeah. So maybe maybe I will add something like auto adjust or auto check and and try different strategies. Yeah.

[00:50:58]And so then in your skills that you have for people that are using Aver do you say like like okay you're going to you know do this and write this code and you're going to use this command to like check and then you know once you once you get through that and you're good then you're going to run um you know I don't know what the next step would be but ultimately get to like actually proof and so like does your skill kind of describe the actual workflow that the AI should use to like iterate quickly and then and then more completely you know as it moves kind of out or how do you >> it describes it describes all the tooling at the moment but to be honest I didn't want to switch everyone to to proofs and to formal verification because that's my honest opinion I don't think every single program on earth needs to be formal ver for u formally verified Yeah, it's it's opt in. So if you want it, you can use that. It makes it easier for you. you may uh just like the very core sorry very core function of of yours maybe that's needed or very core module uh that's needed to be checked but >> it's still up to the developer to decide when they want to add a law into >> yeah basically that law is yeah is magic word which which uh which does all the lifting and and proving but >> so if you're so probably generally if somebody's working on kind of a algorithmic piece of code that that you know needs to the algorithm needs to work verifiably and consistently then you would add a law. But if you're you know reading records from a database or something like that like that the law is not super helpful in that case.

[00:52:49]>> There might be people arguing that's the ultimate goal. Yeah.

[00:52:54]>> And I also added these effects uh effects in in proofs as those oracles and so on. But huh, usually that's not what you're proving with. Yeah, >> that's not the part uh that people tend to prove because it's >> so the skill doesn't say this is the one workflow you must use on any piece of code that you're using. and it describes here's the tools that are available but then you still lean >> you lean on the developer choosing when they want to add a law and then and then once a law exists in the code then then the skill is going to tell it how to how to actually uh execute the proof and stuff so >> or yeah if it decides to to wants the proofs which probably won't on its own because it's more complicated than those really simple example verify blocks.

[00:53:42]Yeah.

[00:53:43]>> Yeah. Nice. [sighs and gasps] Are there any other major features of of Avery that we haven't gone over?

[00:53:52]>> I think we covered uh pretty much all the interesting one. Maybe one more that uh also in those verify blocks you can trace effects. So if you add a word trace in there uh you might set okay this fired in this particular branch uh for example of this of these independent products or I had five uh HTTP get calls or something like that.

[00:54:19]>> Huh?

[00:54:20]>> Yeah.

[00:54:20]>> What is your what are you working on now? What are your plans going forward with the with the project? Uh to be honest, I'm I'm ripping apart the compiler right now. [laughter] >> Yeah. Yeah. Because I I think I I possibly made some technical depth in there. uh and I figured that out when working on uh recently on on the proof infrastructure and I was like okay maybe that's finally the moment I have like the typed uh ATR that's uh or stuff like that. So yeah, I'm leaving the compiler right now.

[00:55:06]>> So it to be honest. Yeah.

[00:55:09]>> Yeah. Um, and then yeah, what's uh after you get the new architecture in place, are there other kind of big ideas you're looking to tackle or anything that on the on the kind of language feature side that you're thinking about?

[00:55:26]>> Yeah, I'm I'm thinking I'm thinking about couple one of one arm of of this project is always the proving site because that's that's interesting. I I find it really interesting to try to close all those all those gaps that exist. So I have a lot of ideas on how to do that. And I'm even right now implementing this additional compiler internal layer of proof intermediate representation kind of a thing because it's different than what you what you need for uh for transpolation to to to rust or whatever. It's different. You you have different things to reason about.

[00:56:08]>> So that's something I'm I'm working on right now. Uh >> on that one real quick. So this is >> um maybe moving some of the validation uh closer to the the time of the AI writing code so that it can get more feedback quick more quickly as it's as it's doing iteration loops.

[00:56:32]>> Yeah. Also also uh the compiler like works in that way that you can explain like there is a command to explain specific passes of the compiler.

[00:56:43]So you can AI or you you can reason about what this a code is lifted interpreted to and so on. Uh so okay for example for the proving I okay I've seen this type of yours which seems to be dependent not dependent the subtype in lin or could be become subtype in lin or something like that so it's easier for you to to reason about how the how the stuff is happening really yeah >> it's like I've I've wondered at what point are AI AI we'll have like AI I integrated compilers that would almost like expose an a of the compiled code to to the AI instead of the actual textual representation. And that's like, you know, maybe something in the in the type system area, but then you are saying let's let's do something similar to that, but go into more of the validation realm as well beyond beyond just basic types.

[00:57:50]>> Yeah, that's that's that's possible. But also to be honest when I was checking something like that because I was checking different ideas on how a could potentially look and it seemed to me like on the generation side a current AI current lens are better used to have code as code as we know it. Yeah. Yeah.

[00:58:13]It's not some not some fancy uh higher higher apation or whatever of it. Yeah. Yeah. I guess they're trained on natural language and so code code is an more of a natural language to it than an a is.

[00:58:31]>> Yes. Yes. Still it is. Maybe that might not be true in near future. We don't know about it. So the whole thing I'm building is a huge bet about cap capabilities and what's happening with with AI and future. But um yeah, I'm seeing it more like a funny experiment of mine to be honest. I I >> Are you tracking the other languages that are being are coming out of this?

[00:58:58]>> I I've I've seen a bunch of them close to 30 at the moment or something. Uh >> yes. Yes. So many of them. Uh and there is there is a very good uh website which right now tries to track them agent languages deaf or something. Yeah, it's my creator of one of them. So so you should you should check and >> like usually they don't have a huge following. Uh and it's the guy even split them into three different uh categories let's say. uh and I've landed in verification one. So so the languages which focus on verification >> and there are ones that are focused more on orchestration for AI kind of a thing.

[00:59:49]So >> some that are more focused on like token efficiency.

[00:59:53]>> Yeah. And that like the syntactic or or something camp as the guy has described it. And I would say a lands in both syntactic and and verification uh for for AI but but there are different things you can optimize for.

[01:00:08]And I find it quite funny to look at the other languages. They feel like uh like like a mirror very often I I I I look at them at the mirror. uh there is there is theme in there going on which I think that's AI forcing people to do which is having all the requires and ensures Z3 uh blocks everywhere. So >> yeah, >> maybe that's forced by AI. I'm not sure.

[01:00:35]I'm not sure. Maybe people are coming up this design everyone at >> Yeah, cuz that even though that's been pushed for a long time, it's not something that programmers have been commonly doing. So the fact that the AI is >> doing it is interesting.

[01:00:52]>> Yeah, >> maybe if you ask, you know, a specific questions specific enough, it comes with this answer at the moment. That may change in couple months. Yeah. We don't know. Uh that's kind of interesting. I think AI is steering people building those languages a lot including including me. I'm not saying I'm I feel immune. Yeah.

[01:01:12]>> Yeah. [snorts] >> Yeah.

[01:01:13]>> Well, and it's it we have such a great opportunity to do experiments and and then uh I'm sure that many people are doing these experiments and probably uncovering common truths or something as they've done the experiments. So, Um, >> effects are one of the common truths.

[01:01:35]>> Basically, pretty much all of those languages have some form of the effects.

[01:01:40]Yeah. Sometimes much more complicated than averse one. Yeah.

[01:01:43]>> Mhm. Uh, one thing I'm curious about your perspective on is if you write a function definition, just the like inputs and outputs and effects and the the intent string and then you write a test or a law for that function.

[01:02:02]How valuable is the body of that function, the the actual implementation?

[01:02:08]like does it yeah do do as a human do I even care if like you know I've got the inputs and outputs and intent and effects and the the uh test the the verifications of that function like do I ever need to care about how the AI came up with the actual body of that thing >> I I really love the question that's the first thing because I was thinking about it a lot I was thinking about it a lot because one may argue that you don't need the body at at this at this moment like body is redundant it's described it's has the test so let AI write the body I don't agree at the moment I think that body is there first of all saving us a proof of what was done what was achieved and I love the shape of it I can reason about the things from the shape of of this body maybe you as as someone reviewing that when I'm looking at diverse codes I'm usually skipping the bodies to be honest they are not the most uh interesting part but I can see the shapes of them pretty easily so uh I don't need to go deeper into fifth line or somewhere I already seen it's the match one I like pattern match it's just by eyeballing it uh and I think that's that's really something and I find it only after I've done all the language all the design decisions behind it and then looking at the code I was like why why did that's that happened that's that's really something that's really something interesting and it all comes from what I've stripped from the language and AI I think it's having more difficult time writing in a because it has to to fit into those shapes yeah >> so I don't think it's easier for AI I would say it's a little bit trickier than in regular language, but then it forces it to have uh a very distinct shapes in the code. A very because someone might also argue that it's it's the same thing written three times because you have the intent, you have the body, and you have the verify block. At the very beginning I was thinking okay that's something that we can catch AI uh by by hand saying okay you you have to you have to say it three times for it to be more true kind of a thing so you won't uh you won't imagine it or I don't know how to how to describe it but it's like you have to write the very same thing three times so it's like more trueish to more true yeah like >> yeah I There's there's a triangle of validation that you're that that is that all comes together so that you can have confidence in your code. Just as an example, I've seen jokes about AI creating you say like uh create a random function and you know it's like like uh if you know input is one then this and you know you see like all these like if then statements where the AI like like only covered you know six of the cases or whatever and maybe you're like property based testing or or law based testing would would catch that kind of thing but it's like the AI like clearly like took a shortcut here and instead of like coming up with the general implementation of this thing. It it did the lazy way and being able to actually look at the body and be like, "Oh yeah, like like that body actually does match my intent. It it's not just taking the shortcut route." Um is probably an important piece of the verification system. Um, and then probably the iterative loop to get there as well is like often you don't know how to fully specify something until you've like iterated a few times on the body. And so there's probably also this like like iteration that's enabled by having all three instead of having the body be um hidden.

[01:06:19]>> Yeah. But there's one more interesting thing I would add to what you said because uh one thing is I can't I think about AI as being cooperative your favor because I can't guarantee that the intent that's written and the verify blocks that are written are what you really meant.

[01:06:41]>> Yeah. like I I it's it's not treating AI as uh I don't know a spy trying to sneak something bad or or stuff like that because I c I can't assure that I can't think about uh a way to to even proof like proof is proving whatever was written there to prove you have to read the read what's trying to be proved you you don't assume it's uh it's true you can you and verify that it's always true. Like that's that's not verifying anything.

[01:07:17]>> So you still have to read that and stamp it. It becomes like legal in Python, but you still have to do that. I'm not saying uh >> it has it's not meant to be to be read.

[01:07:28]It wasn't it wasn't more than a few months ago. I asked the AI to write a test for me and it was a test against a particularly complex bit of code and it tried and then it ultimately just landed on assert true and that was the test.

[01:07:43]>> Yeah. And >> and I've seen that in in AI languages that you have for example uh the Z3 uh ensures blocks uh somewhere there they are usually at uh the function close to function definition. So like effects in a there is ensures true >> so that's like good it's okay it doesn't ensures anything but it's there serving us as you know how to describe that even yeah as proof of nothing >> proof of nothing yeah exactly and so I think that is the challenge with with where the human is needed in the verification loop is that we express intent and then it's up to us to validate that our intent was actually fulfilled by the the written body the type signatures and the and the tests and and verification and laws and all that that we write. So it's the human is responsible for doing that to to we bring the trust that our intention was actually achieved >> and so the language needs to enable us as humans to provide that that validation of intent. Yes, language can do as much as being easy to read, not hide stuff as ivory is doing because I also think closures and all the syntax syntax sugar are might be hiding it. you have to reason more maybe you have to read less but you have to reason more >> kind of a thing and also by by the language design you can make some errors impossible to express in a language that's that's what I was initially exploring a lot so you know decisions like there are no exceptions obvious right now yeah uh with with the >> monuts returning stuff and so on so >> uh you can prevent like matches have to be exhaustive. You don't I don't have ifs because match is exhaustive and it's check for exhaustiveness for example. So there is things you can do and there are things you cannot do. You cannot uh assure uh intent was was >> expressed as you wanted it to be.

[01:09:56]>> Yep.

[01:09:59]>> Awesome. Well, thank you so much for your work on Aver and and uh love to see the all the the great things that you've brought out with that with effects and and laws and proofs and and uh great tooling for the AI and human readability and yeah, it's I think it's uh super exciting to see what you're what you're building.

[01:10:18]>> So, yeah, thank you for all the all the work you do on it.