Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
# 44 - Tims Gardner
51 Plays7 years ago
Tims on twitter - https://twitter.com/timsgardner
Arcadia - https://github.com/arcadia-unity/arcadia
Recommended
Transcript
Introduction and Guest Introduction
00:00:15
Speaker
Okay, so happy new year and welcome to Deaf and episode number 444. And today we're going to talk to Mr. Tim's Garner from New York. I'm sorry. You said some other place, I forgot. Brooklyn, Brooklyn, New York. Oh, okay. So it is still New York. Okay. So welcome to the episode, Tim. Thank you. Tim's, sorry. Is it Tim's? It's Tim's, yeah. Tim's, okay.
00:00:43
Speaker
I thought it was Tim or...
00:00:46
Speaker
I go, when I'm introducing myself to waiters or something, I say, people who are having a short interaction, I say, Tim, because otherwise, because we can just skip over Tim or Tim's debate. Or you're going to say, there are more of us. Yeah. Right, exactly. Or it could be less than one. It could be 0.3 Tim's. True, yes. So maybe it's nice to introduce ourselves. So this is me, Vijay from Holland. Yeah, it's Ray from Belgium.
00:01:17
Speaker
And Tim's. Tim's from New York again. So can you give us some introduction about yourself?
Tim's Project Arcadia: Clojure Meets Unity
00:01:26
Speaker
Sure.
00:01:29
Speaker
Most sort of interesting project I'm working on now is a system called Arcadia, which is the integration of the Clojure programming language with Unity 3D. I'm working on this with my very good friend and collaborator, Ramsey Nasser. And we've been developing this thing for about five years.
00:01:53
Speaker
It's been going to various phases of development, a slow burn that whole time. We recently had a full beta release of it. We are also currently engaged in a company called Arcadia Technologies, where we're going to be developing lines of products that are directly based on Arcadia and take it from there.
00:02:23
Speaker
So before we get deeper into Arcadia, can you give us some layman explanation of what Arcadia is and what it is doing?
00:02:34
Speaker
Sure. Arcadia is a, well, perhaps a place to begin to answer that question is what is Unity, which is the system that we're integrating Arcadia with. So Unity is a game engine and development platform and a very widely used one. In other words, it's a system that people use to develop and publish video games.
00:03:03
Speaker
One of the salient features of it is that it can target multiple different platforms, so PlayStation, iPhone, Android, Xbox, many different desktop, many different systems.
00:03:22
Speaker
And it is, I think, over half of all mobile games are made in it. So it's a quite industry standard system to use. It's not used as much for massive AAA games like Destiny or something like that. Most of the time, companies making games like that have an in-house engine that they've built up themselves over the years.
Unity's Technical Landscape
00:03:50
Speaker
smaller developers or smaller games, Unity is probably the first stop that they go to. One of the very interesting aspects of Unity is that it, unusually for a game engine, actually has a managed runtime.
00:04:13
Speaker
So a lot of times these systems are built in C++ because of the rather demanding performance characteristics of games and the tradition of everybody writing video games in as low a level of language as possible.
00:04:28
Speaker
So there's both a technical reality, which is that you want them to be very, very fast, on an underpowered device, which is sort of the trick here, and having a particular kind of fastness. So the kind of fastness you need for real-time animated interactive games, which is different from the kind of speed you'd want in high-frequency trading or something like that.
00:04:55
Speaker
So there's that sort of technical reality. And then there's also just a tradition where a lot of the wisdom and know-how in games is sort of inherits from people trying to get them to run radically like underpowered systems like an Atari. And a
High-Level Systems in Game Development
00:05:14
Speaker
lot of the wisdom has been sort of, you know, lore about how to write a game has been in that vein traditionally.
00:05:22
Speaker
It was only sort of recently, arguably, that making a game in a higher level system was feasible because the hardware had caught up to it. So Unity, again, unusually for a game's engine, has a VM inside of it and specifically has a cut of the CLR, the common language runtime, the same system that C Sharp runs it.
00:05:51
Speaker
Unity has .NET or .NET CLR inside it? Yes. There's an understructure of C++, but then there's a scripting layer on top of that, which is the CLR.
00:06:11
Speaker
And the way Unity programming generally progresses is the user defines a particular kind of class in C sharp.
00:06:26
Speaker
And then Unity notices the existence of this class and incorporates it into the world you're building out. And you compose your game out of this. So the class could be, I don't know, a mage or whatever, or a character or something like that?
00:06:43
Speaker
Yeah, more or less. And they're using an entity component system of sorts. And there's different interpretations of what an entity component system is. They have a particular one that it's built on. They may be transitioning to a slightly different idea of that or sort of extension of that idea, but it's
00:07:00
Speaker
is basically an empty component system. Without getting too deep into that, the idea is that you have a sort of the world is composed of a set of unique IDs, and the behavior and data of these IDs are expressed by cooking so-called components up to these IDs, right? The IDs are called game objects, and then everything else is components. The components are instances of classes that the programmer writes in
00:07:29
Speaker
C sharp in addition to classes that they just ship with Unity and that they can attach. And these things give them their substance and behavior in the universe. Then during the run of the game, in response to different events and to just a new frame in the animation loop, it fires off methods that are defined on these component classes as a callback system. And that's your game.
00:07:54
Speaker
That's what Unity is. Does that make sense so far? Yeah, it's great. That's what Unity is. Out of the box with Unity, you get a physics engine, which can do really pretty fast.
00:08:09
Speaker
3D physics simulations or 2D physics simulations. You get a lot of support for the incorporation of art assets. You get some other niceties like player navigation support, light baking, some graphical things. Unity has its own idea of how to write shaders. Shaders being programs that run on the GPU, the graphics processing unit, rather than the CPU, which
00:08:38
Speaker
you know, the programs that non-graphics programmers write. And then it can take all of these different ways of writing your program and export it to all of these different targets relatively seamlessly, which is a quite distinctive aspect of Unity.
00:08:59
Speaker
So and then that's a very compelling combination of features for many programmers and game studios. Now, again, what was it? What was it? So before when Unity started, so this C sharp layer or whatever, is it something of a newer thing, or is it since the beginning? As far as I know, is there from the beginning?
00:09:29
Speaker
Okay. And one of the distinctive things about Unity, again, is that it had a scripting layer on top of that. So you weren't just dropping directly into
Tim's Journey from Art to Programming
00:09:38
Speaker
C++. Typical Unity development was never deals with C++ at all. So the whole thing is usually just through C sharp.
00:09:48
Speaker
But is the scripting thing similar to, because there used to be, I'm not sure, because I tried some 3D stuff almost 15 years ago, I think. And 3D is max four or three, I don't remember. So there used to be a 3D script in that one. And also Maya had Maya script. Is it something similar?
00:10:09
Speaker
a bit, one of the big differences or to like Emacs Lisp or something. So it's scripting in the sense that you use it to extend the system you're interacting with, with the exception that this is also how you're going to be doing all of your programming for your game. So it's much more sort of mandatory to have some kind of
00:10:33
Speaker
Like you have to touch code if you want to do something programmatic, right? And the code you're going to be touching is going to be in the scripting layer. The other distinction I draw is that just the language you're scripting in is not a sort of super high level language like that. It's C sharp.
00:10:48
Speaker
So, you know, it's in this sort of realm of between, depending on who you ask, is it compiled? Is it interpreted? It's a little of both, similar to Java, right? Where there's a bite note representation, but it's relatively low. I mean, sorry, it's relatively like high level. There's a garbage collector. It's just a bit of both. And there's like types and things like that.
00:11:13
Speaker
So it's like full C-sharp environment. It's not like half-assed C-sharp. No, it's for full thing. It is C-sharp. So C-sharp bytecode, they're running an instance of the C-sharp VM, the CLR.
00:11:31
Speaker
And they're emitting CIL bytecode, which is the bytecode representation of it. So it's the same thing. Specifically, the system they're using is a fork of another system called Mono, which can run on many different platforms. And there's all sorts of licensing vagaries that we don't really need to go into.
00:11:58
Speaker
Yeah, so it's the real thing. It's truly
Arcadia's Development and Challenges
00:12:00
Speaker
C-sharp. I guess the Microsoft have their own 2D and 3D engines. I guess this is a different thing from the Microsoft stuff? Yeah, this is a different thing. To best of my knowledge, I can say more than that. It is a different thing. Unity is its own company.
00:12:24
Speaker
some of the other infrastructure is recently acquired by Microsoft, but not of Unity, just sort of affiliated programs. Like I think Xamarin has been acquired by Microsoft. But Unity is its own entity. So it's not related to or it doesn't use Direct3D or something or DirectX or
00:12:45
Speaker
I'd have to dig through it to figure out like exactly. I think we should go a bit higher than them. It makes more sense that we talk about the... So CLR is the interesting part in Unity now. So that is the way you use Closure on top of it, right? Yes, exactly. So by virtue of the fact that it is really and truly the CLR, and they are really and truly emitting bytecode, if you can come up with any way of
00:13:14
Speaker
producing that bytecode, then you'll run. And Unity couldn't stop you from doing that if they wanted to, right? Or maybe they could if they really liked the VM and were scanning all of your bytecode to make sure it looks the right way, but they'd have to do something crazy like that. And the- They're not Apple. You're right. Well, yeah, we'll get to there in a minute. Okay.
00:13:45
Speaker
And that means that if there is a version of Clojure which can compile to CIL bytecode, then it'll run a unit. So five years ago, and I can go into some personal history about how I came to this juncture, but. Of course, we would like to. So how did you end up starting into getting into this kind of venture?
00:14:15
Speaker
So I guess, well, I'll just sort of put a pin in, you know, how Arcadia got started and then I'll circle around. I was an art major in college, so studio art, illustration and sort of cartoons and drawing and a little bit of painting. And
00:14:35
Speaker
my senior year in college, I started to program a little bit through a system called processing, if you're familiar with it. It's sort of a little sketch.
00:14:45
Speaker
Oh, yeah, processing, yeah. Yeah, it's for Quill issues. Yeah. Yeah, Quill, yeah. Yeah. And that's pretty cool. It was for throwing together little graphics things. I went to graduate school at NYU for a program that was about sort of creative experimentation with programmatic stuff. I got a little bit more into it there. I was fascinated with this idea that you could, in principle, visualize
00:15:15
Speaker
the structure of mathematics. And the idea there is that if you can come up with a visualization of foundational logic for mathematics that scales in the right way and is sufficiently expressive to provide recursion and definition and things like that,
00:15:37
Speaker
then you might be able by extension to visualize anything that has a well-defined foundational treatment, which is a lot. I didn't really know what I was doing at the time, but I was obsessed with this idea that you could come up with this categorically more powerful form of visualization for all sorts of things.
00:16:03
Speaker
And I mean, if I was doing that now, I would say that it would be something like a visualization for a theorem-proving system like Coke and see where you can go with that. But as I continued to pursue it, it became increasingly clear that
00:16:20
Speaker
you know to really do it would be like a phd or two right and i didn't feel like um as an art major i would probably go to the programs that would support that um and i was just like okay
00:16:36
Speaker
got to move on from that, but I was still really interested in this idea of visualizing how we're dealing with a computer. Most of my experience at that point was through Java, and I was getting into C++ some, because that's what a lot of the so-called creative coding tools are written in. Things that you're going to make graphic art things in and interactive applications in.
00:17:02
Speaker
But I was still thinking about logic a lot, and people saw that I was trying to sort of replicate, I was trying to come up, I was obsessed with notation and coming up with ways of notating logic and that. Some people were looking over my shoulder and saying there's this new thing called closure that people are talking about. Like Lisp in general seemed to be the direction I was drifting in because of the way my sort of notational systems were going, and closure in particular.
00:17:28
Speaker
Then complete coincidence, I found myself on a gig sharing a workspace with David Nolan. And I was talking about logic. And at the time he was working on core logic. And I kind of looked over his shoulder and he was like, dude, you got it. You got it.
00:17:46
Speaker
check this out more. And so then I taught myself Emacs, I taught myself closure, I got all the way into it, I joined that workspace and for like five years I was just there, David Nolan was like a couple of desks over and I was you know breathing all that air and that I mean that was a really
00:18:09
Speaker
terribly transformative experience for me. And Kovas Buguta was also part of that space, if you know him. He's a Mathematica guy. He did session and a bunch of other kind of mad science stuff with closure. And then one day at an art show in Chelsea that I heard about, somebody was
00:18:39
Speaker
showing a programming language that was written in Arabic. So it was a list more specifically that where the text you see is actually
00:18:51
Speaker
rendered as Arabic, which changes the way it works a bit because it flows in the opposite direction from the usual way. And this is about how programming languages are typically assumed English as a kind of... And so no matter where you live and what language you speak,
00:19:09
Speaker
you are kind of forced to buy into English assumptions, assumptions of the English language. And I was one of the few people who could actually write a program in it because a lot of it follows just from the structure of Lisp. That guy was Ramsey Nasser. He wound up joining the space
00:19:28
Speaker
And then one day over a handle of bourbon, Ramses was a games programmer and had a lot of experience with games development. And one night we were just hanging out in the studio and talking about Clojure and Unity, which she had a lot of experience with. And we realized that there actually is a branch of Clojure out there that can compile to CIL bytecode.
00:19:59
Speaker
And if we sort of hack it a little bit, maybe. And therefore, like in principle, we should be able to get it to run immunity.
00:20:10
Speaker
if we sort of go into the code base and we edit out a few lines and we make a few little tweaks. And I think in like, yeah, that night we got the basic proof of concept for this, that we could get that, you know, closure compiling inside of Unity.
00:20:28
Speaker
The branch of closure in question is ClosureCLR, which is a very old cut that was sort of there almost in the beginning. It was one of the PMs that Rich was considering from the start. And this isn't even in the name of Closure. Supposedly the CLR and the word Closure refers to the CLR.
00:20:49
Speaker
So it's been maintained since then by a wonderful gentleman, David Miller, sort of as a hobby. And it's sort of quietly been keeping up to pace with the main line of closure all along over all these years because this one guy's work. And then once we realized we had this thing, it was like, oh my God, just
00:21:16
Speaker
we can really do a different kind of game development with that. And then we were off to the races. So we continued to work on it sort of as a passionate hobby. Eventually we had this sort of announcement of the first version of what we were willing to say is worth the sort of alpha that we were willing to say is worth playing around with. That got a bunch of attention. We did a bunch of talks. And then in the time since then, as our own kind of passionate hobby, we've been building it out more and more
00:21:44
Speaker
trying to converge on a more or less stable release of the system, where the API at least is stable. And like last month, we made that beta release. So now the Arcadia API is stable, and we're encouraging people to be building systems on top of it and trying it out.
00:22:10
Speaker
We've also secured some funding to start our own company on the basis of this. Excellent. I said excellent. That's really good. Yeah, it's great. I mean, it makes a lot of this much more possible now. So now that Arcadia is in place, we're going to be, again, building out game products and game development products on top of it and just seeing how far we can run with that.
00:22:40
Speaker
Nice. That's a very interesting direction. So you started from art, and then got into programming, and then turned into functional programming, and then finally ended up in, I don't know, close your CLR. Yeah, well, CLR and doing aesthetic stuff. So it's kind of, there is something constant there. Yeah, yeah. It's a little bit windy.
00:23:05
Speaker
But it's an amazing story as well, if it all comes off. Because essentially, like you said, kind of like crazy dream is now turning into something that might take you a lot further. Yeah. Yeah, exactly. And hopefully it can take game development a lot further. Yeah. Yeah.
Live Programming in Art and Games
00:23:26
Speaker
Because I did some processing stuff, processing and quill things some time ago.
00:23:35
Speaker
I need to think a bit because there was some New York artist. He had some project or something. And then I was trying to cover some closure code. It's in 2014, around something that time. I don't exactly remember when it was. I need to look it up. But yeah, it was really nice to see having a processing window. And then you keep typing closure.
00:24:03
Speaker
changes the stuff. There is a really live endowment that was amazing. Yeah, I think live programming in artistic contexts is fantastic. And part of it is that live programming can mean many things. In fact, it's a semi-old idea. I mean, it's a really old idea if you really want to get into history.
00:24:32
Speaker
in terms of how often people use it, there's sort of spatterings of it all over the place. But there's a big difference between live programming in like a JavaScript console even as JavaScript or a system where it kind of serializes everything and then restarts quickly whenever a sense of exchange in the code. And live programming in a language that was
00:24:58
Speaker
written from the ground up to support it by closure and written well from the ground up to support it by closure. I think that that's something that games programmers are not used to. So the ideas people have of what live programming means could be quite different in Arcadia.
00:25:17
Speaker
One of the things we're trying to do is communicate to people what real live programming can be like, where any part of the system at any time can be redefined in the same environment instantaneously, and you see those updates. In addition, these updates are supported by a very extensive data story.
00:25:38
Speaker
where you're not just doing like control, but very important parts of your program can gracefully be represented as persistent data, meaning the cost of like failures or mistakes is less because you're not just mutating everything all over the place and the connections between the different parts of your program are relatively sparse. And that gives you this freedom to play around and really sculpt the logic of your system.
00:26:04
Speaker
So I don't know if you even do any web programming these days, but if you were comparing it to something like Fig Wheel, for example, where you can have an application running and then you change something and you don't have to go back to the very beginning and log in again and do everything. Is it a similar feel or is it a similar concept for the game programming that Fig Wheel has? Is that something we can relate to?
00:26:32
Speaker
Yeah, there's even a flag in Arcadia that enables pseudo-fig wheel style programming where it listens for changes to files and it will just reload those files if it sees a change. It's not doing the full walk of all the macros to try to figure out the complete set of things it needs to reevaluate to be sure that it's updated everything it needs to, but we could do that if we want to. The other thing we can do is just throw new logic at the world that is put together.
00:27:01
Speaker
It's relatively easy to just copy and paste that in. I mean, the way we have it set up now, I think it's fairly easy to, just with that, have the live programming experience. One of the differences so far with 3.0 system and web development has to do with just the structure of games and the
00:27:28
Speaker
Some of the ways that games are perhaps distinct from the web. One of them is that oftentimes games just are kind of imperative simulations of what's going on. For certain very important classes of games, this is not the case, like a simple card game or something.
00:27:45
Speaker
I consider that whole thing in a very pure, functional way. On an Android device, that's good enough. There's just not that much going on to hit any kind of performance hurdle.
00:27:59
Speaker
But for some kinds of games, you really do want very fast 60 frames a second, lots of stuff going on, physics simulations, a lot of math happening. And that is traditionally not a great fit for
00:28:16
Speaker
functional programming at all, let alone dynamic functional programming. I've been listening to some other episodes of this podcast and one of the points people make is that
00:28:32
Speaker
There's perf trade-offs in terms of A, you're functional, B, you're dynamic. And one of the things in Clojure is people can obsess about perf and multi-methods versus protocols and all this stuff, but it doesn't really matter. I mean, we're already here, right? We're already in here. Yeah, exactly. And for us, that's unacceptable, actually.
00:28:52
Speaker
So I think one of the reasons some people, and this has come up now and then on like Hacker News when people have remembered about us is like, oh, how can you do a list in games? The whole thing seems like a complete non-starter, let alone closure, which is this sort of weird list. I don't know what that is. That's kind of true.
00:29:16
Speaker
And here I'm going to get into the nitty gritty, if that's the course. Do it, yeah. Come on. Unbox those numbers. Exactly. Exactly. Until you apply an unusual level of. So we're going to read out the code now. Open parentheses. Right, right, right. So why are dynamic languages slow? Is that a question for us?
00:29:45
Speaker
No, no, no. It's a rhetorical question. It's okay. A rhetorical question. We'll let the audience stew on that one, you know. Well, like, what are some reasons why a dynamic language is slow? All right, so we're doing a question. Okay, so, so of course, yeah, when they have the garbage collection thing, they have to check all the objects, all that kind of stuff all the time.
Performance Challenges with Dynamic Languages
00:30:07
Speaker
You have to do that in the static language, too. Oh, yeah, that's true. Yeah.
00:30:11
Speaker
But what about a dynamic language that puts more pressure on the garbage collector? Well, it's constantly recreating objects and creating new stuff all the time as you record things and as it evaluates things. It's intermediately expressed, isn't it? Because there's a top-level expression of do this. And then the implementation varies according to the conditions, even in the gits and stuff like that.
00:30:39
Speaker
Yeah, well, there's the, I mean, the JIT would make it faster usually, right? If you have a full-on like JVM style of JIT where it's just, you know, sort of doing induction on the code base and analyzing it for patterns and optimizing the image. I'm getting it wrong now, so let Vijay have a go. Let me be wrong now. Exactly. I want, we have voice.
00:31:08
Speaker
No, I think it's probably because in dynamic languages, you don't have any runtime information available or precompiled stuff. And also maybe the lifetime of an object is pretty tricky to identify. And also reflection, obviously. So you need to constantly do the reflection to identify what type of an object this is. So what about in an imperative dynamic language? Like Python.
00:31:35
Speaker
Yeah, it's kind of a ruby. But in that case, there is an interpreter, right? Because you're not actually compiling. So you're essentially submitting your program to the interpreter. Yeah. Maybe another question here, and I'm fishing, which is a bad question.
00:31:54
Speaker
Well, I would say that really there's not a lot that is inherently slower about a dynamic language than a static language when you really get down to it. There is an overhead to doing type checks. You can't just jump to the method definition on whatever system you're in. So there is that. That's a big one. The big one is boxing. And that's where all of these objects are coming from.
00:32:20
Speaker
Right, so you need a pretty good allocator and garbage collector to be able to keep up with that.
00:32:28
Speaker
And even then you need to be, I mean, these alligators and garbage collectors do exist. Like the JVM has a great one. V8 has a great one. Modern cuts of the CLR have a great one. But it gets down into, there's all these trade-offs and it's very complicated. At the end of the day though, you're making lots of objects. And sometimes you can get away with that. Sometimes it's going to all be cleaned up after you.
00:32:53
Speaker
The other way of doing it, but they're on the heap, and you're going to have to deal with that sooner or later. The CLR, unlike the JVM, is designed to allow another way of dealing with numerics. So in the CLR,
00:33:18
Speaker
Well, I mean, the JVM does something similar to this too, but in particular, if you pass by, it has, sorry, it has better support for user defined value types. There's any support really for user defined value types, meaning types that's similar to like primitives on the JVM are going to be effectively passed by values. And that means that you can avoid boxing them.
00:33:46
Speaker
Now, and for people who are listening. In JVM, it's pretty, well, it's like a few years ago, right? Until then, we didn't have box primitives. So JVM caught up with this thing, I think. I don't exactly remember, probably Java 6, Java 7 period, maybe. I need to look at it. Yeah, I'm not really familiar with the history. The big idea is that, just to get everybody up to speed, I guess, is if
00:34:11
Speaker
This is the stuff that people usually don't need to worry about. The language is supposed to take care of it. Most of the time when you're passing by, and some people might get mad at me for saying passing by reference rather than passing by reference and so on and so forth.
00:34:31
Speaker
We're among friends, don't worry. Are you passing pointers or objects around? Or are you copying byte values? The values, yeah. So the idea is if it's a pointer, you are copying just the minimum number of bytes you need to to know what region of memory you're supposed to be pointing at. And that's effectively passing an object, this reference. But usually that involves some idea of the heap.
00:34:56
Speaker
Because that object lives off and then keeps somewhere. And that's where the garbage collector and the allocator needs to worry about. Because keeping all of that sorted out and efficient is a task for almost a possibly sophisticated system, which is why there aren't very many of them. They've been done less than 10 times to the full industrial level. And then the other way of doing it is that you have a bit representation of
00:35:26
Speaker
something like a number, like a float, or an integer, or a long, or a short, then you have all these different ways of doing it. And those are going to get copied directly into memory that the method or function is looking at. And if you're doing that, you can just bypass the heap altogether.
00:35:44
Speaker
You actually are copying something, but it's faster than, in a certain sense, it puts less memory pressure on the system than passing by reference width. It's all in the stack, you don't need to collect it, you know when you're done with it, it's okay.
00:36:06
Speaker
So in the CLR, you are allowed to, now in Java, I'm not an expert on the way the JVM deals with this, but basically you can do something like that with a couple of types, like the numeric type, the numeric primitives, which is a closed set. There's like seven of them and there will be forever. And the, or I mean, unless they start adding more. But point is, that's not the user's decision. You don't get to add more value types that are gonna be passed by value rather than reference.
00:36:37
Speaker
On the CLR, you actually can define your own. So if you want a vector type, like a 3D vector, that you're going to just pass by value all over the place, you can do that. And people do. So there's lots of these zero allocation, because you're just copying them between regions of memory. You're not putting them on the heap. Types flowing all over the place in the CLR.
00:37:05
Speaker
Now, the only way you can actually do this, where you know how to copy one thing from one place to another, is if you know the type at compile time. Right? Because otherwise you know how to save it. Yeah, how much space it's going to take. Right, exactly. And this is a problem in a dynamic language for us. So the alternative, if you don't know what the types are, is to basically wrap them in an object, which is boxing.
00:37:34
Speaker
And then you pass that object around. And then the bytecode level, you know how to take it out and look at it and treat it as an actual value type instance and then put it back in and all of this. But that means that for every value type you're dealing with, you are allocating a new object. So 1 plus 1 equals 2. So that's the object you're dealing with. If you're dealing with it on the pure function level, and you don't have any other information.
00:38:07
Speaker
Now, so that's kind of a non-starter for us. And if you have this constant allocation on a VM that doesn't assume you're going to be writing this kind of program, like the VM we happen to be using, and you're putting it on a little device, this might be problematic. Maybe for some games, actually, you can get away with it, but not the general class of games.
00:38:32
Speaker
However, the CLR has a deeper concept of generics than the JVM.
00:38:43
Speaker
Whereas in the JVM generics, generic types are really type erasure. So it's all going to get erased at runtime and they're not making new types to fit. On the CLR, you can actually, it will make new types just for the sort of generic signatures you're making.
00:39:03
Speaker
That means that if you say, this is a function and there's going to be a type parameter in it and I'm going to give it an integer or something, it's going to make the correct amount of space and memory to fit that value type.
00:39:26
Speaker
In Closure JVM, there's a file somewhere where they have hundreds and hundreds of interfaces defined to support primitive passing non-boxing numbers back and forth between primitive type-handed functions up to four for long and ints. Is that it? Or maybe just longs. Are you familiar with this? No, not really, because I don't use that level of
00:39:52
Speaker
So there is a little bit of support for non-boxing type information on the JVM version of Closure. But it's, again, a closed set. And if you want to do something else, you're out of luck. We can't do that. It doesn't work for us, because the user could define any kind of value type they want. But we can, in principle, use generics to achieve the same effect. So if we come up with a way of making Closure functions responsive to generic types, that means that we can actually, with one definition,
00:40:22
Speaker
emit a special kind of closure function that knows how to take any kind of value type or correctly size itself to that and therefore avoid boxing. And what this means is that we can have a much broader form of non-boxing closure than on the JVM.
00:40:46
Speaker
I'm not going to make any claims about our characteristics versus the JVMs, but I will tell you that we are feasible for extensive numerics on the SLR. To the point where, in principle, we are as fast as C-sharp.
00:41:03
Speaker
So technically, this is because of the feature that CLR is providing you, right? The ability to define the value types. Yeah, exactly. So it's the value types plus the generic type system. This does mean that we have to have a more powerful kind of type hint.
00:41:20
Speaker
So we have to be able to communicate that sort of thing. And we're still working out some of the details of what that will eventually look like. But that's one of the most exciting things about the Closure TLR compiler we're working on. In Ramses, I should say, this has been Ramses' project. So I've been spending most of my time working on the high-level code for
00:41:42
Speaker
Arcadia than the Arcadia API and Ramsey's been focusing on, you know getting some of these compiler things landed and maybe we go back and forth but this is the general thing. Ramsey did an amazing job getting this thing together over the past couple of years and the other thing is just doing an overhaul of the current implementation of ClosureCLR to get all these optimizations in place. So the way that
Arcadia's Performance Innovations
00:42:10
Speaker
The maintaining this port from Closure JVM to Closure CLR at all was feasible is by as much as possible doing a copy and paste. David Miller has been basically copying and pasting the two things. It's a different VM. It's a very different system in a bunch of ways.
00:42:30
Speaker
have real performance, you kind of need to write the whole thing again, or at least the admission phase where you're actually spitting out the bytecode. And so we are doing that. We are writing another variant of the ClosureCLR compiler effectively in the Closure because we already have one version of it that works. So what we're working towards is basically a meta-circular Closure, like a bootstrap closure.
00:42:54
Speaker
Yeah, closure on closure here. But this has been a big thing or a point of discussion comes up every now and then. I don't know why closure is not hosted for closure or something. Yeah. So, I mean, I think no one's, well, I mean, the
00:43:12
Speaker
There's different things that can mean. The one that we're working towards is not really host agnostic because it's very much about the exact bytecode that we're using. One of the side effects of this, in addition to being pretty fast and on the CLR, is that we're going to wind up with a very powerful bytecode metaprogramming library for closure on the CLR, meaning that if you want to inline
00:43:40
Speaker
custom bytecode for a particular closure form and express that as a macro, you'll be able to do that. Oh, so it's almost like writing assembly in C. Yeah. Yeah. And you go inspect it. So it's like a common list feature where you can just say, oh, what does my bytecode look like? Oh, there it is. Right. Again, without really, it's not so much that we were like, oh, you should be able to do this is that we can't stop anybody from doing this giving
00:44:06
Speaker
this technology we've built. And what this means is that if you want to make a new effectively special form, we can't stop you. I think this is interesting for Clojure because
00:44:22
Speaker
One of the limits that people hit or questions that people hit up against is this perf thing. There's a high-level language, so we shouldn't be worried about that too much. But if you're defining a really wacky kind of net science system,
00:44:37
Speaker
One of the limits you hit in Clojure is perf. You're not going to hit a limit with sheer expressivity. If you had an infinitely fast computer, you don't need to worry about any of this. People do wind up a bit worried about that. A lot of the libraries I see, a lot of the thought and the art of it is a balance between perf and these really sexy sort of Clojure idioms.
00:45:03
Speaker
But we can actually, with this library, drop down beneath the usual floor for that into the absolute bytecode level. You can do that on a JVM too. You can emit bytecode if you want there and load that up and stuff. But I don't think people have built out that feature as much as we have to build it out for ourselves.
00:45:28
Speaker
Anyway, so what we're winding up with here is a system that is very high level by virtue of being closure at all, but can also drop down to the lowest possible level on the CLR. This very steep
00:45:47
Speaker
gradient there. But can you do something similar in the C-sharp environment already? Like you write C-sharp and then you write the bytecode or IL, whatever they call it, on CLR and then combine them? You absolutely can. I mean, the emission library is still there. The problem is that C-sharp is not built for metaprogramming. Yeah, exactly.
00:46:09
Speaker
This seems like a significant amount of work to get this going to the level where you want. What is the guiding principle? Why all this pain, just to get closure? For five years, it was basically, again, a passionate hobby and a friendship thing. It's an excuse to hang out with Ramsey.
00:46:31
Speaker
I said to all my students, if you want to get into programming, find somebody to embark on an insane project with. At the end of that, you will be good at programming.
00:46:50
Speaker
five years pass and it's there, right? So we actually have all of these things, or we're very close to having a lot of them, and we're realizing that this could be categorical, could enable a categorically different form of games programming, right? And that could have, you know, that's something worth sticking out.
00:47:11
Speaker
What you're saying here, just as a smaller side really, is that it turns out that if you're running your programs on the CLR, you might get a lot better performance out of it, even for standard programming models, not just the games programming models.
00:47:33
Speaker
I want to be very careful here because any kind of performance claim that I have in benchmarks, I'm very, you know. But you're holding out that kind of dream or that possibility. I'll say that if you want to go there, and there's a lot of reasons you shouldn't, but if you want to go there,
00:47:54
Speaker
You are not limited by anything in the language in terms of the kind of performance you can get with the system that we're probably going to wind up with. If you can emit your own bytecode, then there's nothing about closure per se that's going to be slowing you down at all.
00:48:12
Speaker
Whether it's idiomatic closure, whether it composes well with other pieces of closure, whether it can, you know, correctly deal with a deep walking macro or something like that, you know, probably not. But if you know what you're doing, if you're like, and if you, if you really want it, right, which I think is one of the great appeals of closure.
00:48:33
Speaker
It is a language that enables this radical freedom about the kind of program you write. And that's one of the reasons why we think it's a really great fit for games programming as a creative tool. It's that I don't want to be worrying about the language when I'm writing a game. I want you to be knowing with the creative process of making that thing. So does it mean my Skyrim will have Repel finally?
00:48:56
Speaker
Skyrim is not written in Unity. Well, one day, you never know. That's one of the... I think the way I think about this, there's... One level of what we're doing is about making games development much more productive.
00:49:16
Speaker
So maybe something like rails for game development, something where you have a much faster, more expressive system to quickly iterate and make games and maybe express them as data, merge them together, a framework for saying that. So it's just very far removed from the overwhelmingly imperative and type-laden and kind of hacky
00:49:41
Speaker
game systems people more usually write them in. And a studio using such a system could have a massive competitive advantage over another one, like a casual game studio.
Functional Programming in Narrative Development
00:49:53
Speaker
So that's, from one business perspective, something that we're very interested in. Another level is, what does it even mean to have a game?
00:50:06
Speaker
In practice, I think a lot of games are sort of rather constrained, imperative simulations that you kind of puddle around in. And one of the reasons why games are considered a great fit for object-oriented programming, I think, is that the kind of game you're making is sort of the circular thing.
00:50:26
Speaker
Games are a great fit for object-oriented programming because object-oriented programming is the only option for making games. In a Skyrim or a third-person shooter or something like that, that's actually not a bad fit for object-oriented programming in some ways. You have these physical objects that are literally bumping into each other in a world, like your balls.
00:50:47
Speaker
But what about narrative? It's not a great fit for that kind of structure. Most of the research into narrative systems for games, as far as I can tell, is based on logic programming and things like that, which are just a very different kind of, or solvers, a very different approach to these ideas.
00:51:10
Speaker
It's also not a great fit for a data-centric programming model or something that cuts across concerns where you want to be able to merge game aspects into each other and stuff like that.
00:51:30
Speaker
Another aspect of games is that once you've defined the system, there it is. You're kind of hindered by the limitations of an algorithm. You have a computer, it's a machine that's running some code.
00:51:50
Speaker
however interesting your experiences is always going to be bounded by that. I think one sort of extreme example of this is maybe No Man's Sky where everybody was very excited because there's this promise of a kind of transcendent experience of an infinite universe. Are you familiar with this
00:52:09
Speaker
No. It was a game that was widely advertised, an indie game that was going to be impossibly ambitious where they were degenerating deterministically an almost infinite universe that would fill up the memory space of your computer in terms of the possibilities.
00:52:29
Speaker
It was deterministic, so you can fly back to every planet. The planet would be generated on the spot by a pseudo-random algorithm. You could always revisit it again. Fauna, the whole thing. It would be completely continuous. You can fly from one planet to another in this unbroken chain.
00:52:49
Speaker
They did that. They sort of screwed up the release of it in a couple of ways. People got very disappointed about that. Now it's actually a decent game because they kept releasing patches. Anyway, one of the problems with this approach is that you do start to feel
00:53:08
Speaker
The limitations of any algorithm, anything that we currently know how to make short of hard AI, there's just going to be a constrained system inherently. We don't know how to encode a certain kind of richness into a computer. What you can do is get a human to show up.
00:53:25
Speaker
in the system. So if you have live programming in almost a performative context, where somebody has like a narrator or just another player, but a player happens to have a REPL in the system, what does that look like when you're in a shared world with this level of control and expression?
Interactive Game Experiences and Live Programming
00:53:47
Speaker
We've done some performances actually where, ourselves in New York, where there's
00:53:54
Speaker
like a projector in the back of the room that is with a 3D world of some sort on it. And there's a website that the audience goes to, and as soon as on their phones, as soon as they go there, their phone just displays a controller. And you can, and as soon as you log on to the website or visit it, a little character drops into the world, the next you.
00:54:20
Speaker
but everybody in the audience is in the same world. It's just one screen. And then we say, okay, you're one team, you're the other. And then in response to what the audience is doing, we start trickling in more and more game mechanics and modifying the world as a live programming thing. Right. It's like overtone for games. Like what? Like overtone for games, like a live music concert. You're doing like a live game programming concert.
00:54:48
Speaker
Wow, yeah. What was interesting is that it really worked. It's like people got really engaged in it because they know that it's a unique experience and they can react to what they're doing, the very root parameters of the system. So very interested in what that might look like if you take full Turing completeness as part of the medium that your game is in.
00:55:09
Speaker
It would be super cool to have a REPL in the game, right? Then you'll be like Thanos with Reality Stone. We just kept reloading the whole thing in the way, whatever the way you want, and keep changing everything. Yeah, exactly. And I mean, some of the more
00:55:22
Speaker
kind of appealing versions of this which we've already done proofs of concept for and everything is you go into like virtual reality or something in the world, a repl pops up in front of you and you can just reprogram anything you want as persistent data. So you can like snapshot a part of it, transform it as closure data.
00:55:41
Speaker
put it back out there, or I didn't like it, go back. We've already stored a couple of versions of it in a vector somewhere. I mean, it's this great fit between that functional, persistent model and creative work, really. Yeah, because I think at the moment, people have these scripting languages on top of their game environments. But that definitely feels like a much shallower version of what you're offering.
00:56:07
Speaker
Yes. Explaining the difference to people who aren't already familiar with Clojure is one of our things we need to do. I really think it's a quite different thing. Clojure is this very subtle system in a way. It's many different things that all come together and make
00:56:30
Speaker
a hole that's difficult to quickly explain, right? Like it is very, and this is one of the struggle for people in the closure communities. How do you come up with like the one line or the elevator pitch for closure per se? Yeah. It's red pill, blue pill. Alice in Wonderland. You'll enjoy it. Don't worry. Sounds like a drug dealer. It's okay. You know, just take it. You're going to have fun with it. The first hit is free.
00:56:58
Speaker
It's a serious problem. When I was teaching, one of the things we would do is, once the students were fairly caught up with the basics of programming, we'd just assign them over a weekend, here, you learn Go, you learn Phoenix, you learn this, that we just throw in the language that we hadn't taught them at all before. The point being, you can do this. You're a programmer now, you know JavaScript, you know Ruby, you can code, and that means that you can teach yourself a completely new language that we haven't taught you yet, and you can do it in a weekend. We did it.
00:57:28
Speaker
One of the hardest languages that I only assigned once was Clojure. Part of that is the tooling around it. It's really hard. It's just hard for newcomers. So you don't let them use Emacs then?
00:57:47
Speaker
Oh, God. Well, I mean, that's part of it. I live in Emacs. I do all of my work. Perfect. That's all I wanted to hear. I live in Emacs. I do all of my work. How do you recommend Emacs to... It's like, oh, maybe just learn Emacs.
00:58:14
Speaker
You have to be in the place I was five years ago where it's like, I will learn this language. I'll bend heaven and earth to learn it.
00:58:25
Speaker
I mean, now, fortunately, one of the things, one of our great assets in Arcadia, and something that's really kept us going through this time, and you're asking, why would you go through this pain? We have an amazing community of people who've been using it from the beginning, just spontaneously like using it. And that's really kept us working on that, on this thing for a long time. And right now, they are,
00:58:52
Speaker
just doing a lot of work in terms of tooling integration. We don't have the like resources for ourselves right now, but people are just spontaneously picking this system up and really getting the Emacs integration. And there's also like Adam integration, basically, as soon as we can get good and repl integration, which we already have a basic version of it. But if you have the whole thing, then that opens up a lot of other editors too. So the tooling problem sort of goes away there.
00:59:22
Speaker
But yeah, I mean, back to what I was saying, the other issue for us is saying, given that it's going to be a somewhat steep learning curve, why would somebody give closure a shake at all? Why is, do we have a live programming story that's different from what you could do in Lua, or hot reloaded C-sharp even, or something like that? Or F-sharp, if somebody gets around to a good F-sharp port to closure.
00:59:51
Speaker
And without knocking those languages, I just think that what you don't have is a metaprogrammable, dynamic, data-centric, which is the real clincher system, like language for talking about that stuff, really. And if you did, it wouldn't have the same kind of like
01:00:15
Speaker
momentum this closure does. It's quite a quite distinctive language in that
Uniqueness of Clojure and Lisps
01:00:22
Speaker
regard. Yeah, I think well, being a lisp, it's like that, isn't it? Because, you know, it's the reason why other languages are not lisps, because if once they get all of those things, they just become a lisp. Yeah, right. Well, exactly. You know, they might, they might be like Mathematica, and they sort of shift, make it not look like a lisp. But yeah, yeah. And then and this was a fast enough. That's the other thing.
01:00:44
Speaker
Right. Like closures always compiled. So tan in principle make it really fast. Closures are quite fast language, really. You know.
01:00:55
Speaker
when you compare it to, I mean, another language I love is Mathematica. And Mathematica is the best excuse for being slow of like any language I know, which is that it's doing the lambda calculus effect is like doing is actually a rewrite system. And that's how it does all evaluation is through like transforming data structures. But what you lose there is this
01:01:19
Speaker
this ability to have a static bytecode representation that you're constantly emitting every time a new form shows up. But it's interesting, like you say, that, you know, and this is a bit of an off, it's on and off topic really is that many programming languages, you know, I mean, just the big, big sort of famous ones, I like Python and Ruby are not fast.
01:01:39
Speaker
but they're still popular. So it's definitely, you know, speed is a thing in certain situations, but it's not the only thing. A lot of it is tooling and community and being able to tell a story, like you say, having some, you know, killer features or some killer apps or some use case that can just really show the difference of this thing. Right, exactly. And I think for us,
01:02:06
Speaker
it's gonna be a, my suspicion is, I mean, that it's gonna be videos. So what we can do is show something, like a picture's worth a thousand words, so a video is worth like a thousand words times how many frames you have. We can show what you can actually do when you're in a repl in a world, a closure repl.
01:02:36
Speaker
There's just no way of doing that in another language, really. The whole thing is just data. You tweak the data structure. Now it's real. Something happens in the world that you didn't anticipate. You say, that's cool, and now you have the data structure. Back and forth between them, this clean, flowing, non-anxious way of dealing with it, where you're just thinking about the system you're making, the game you're making, the experience you're making, and you're in it.
01:03:05
Speaker
I think that's the best argument we can really show. So using Arcadia essentially would mean that I would build my entire game or whatever the thing that I'm building in completely enclosure then. So I could use the whole all the libraries or at least the closure core libraries and everything. It's a slight difference. You still have to port it all to this CLR. In fact, especially the sort of interesting libraries are
01:03:35
Speaker
have a certain amount of interop. You're going to have to come up with some way of reporting it. That said, for all the ones that I've looked at, you can do it. So you have core async transducers and all that stuff, or does that? We have transducers. Transducers are down. Core async remains to be done.
01:03:59
Speaker
things to watch out for is that again, sometimes the performance, you have to know that it's the right context to use a tool like that. But in principle, all tools are usable, whether that's going to be something that you use at like edit time before the game is actually running on a phone, but you're just setting up, you're trying to set up the system that is going to
01:04:15
Speaker
set up a system. All of that stuff is fair game or something that runs relatively infrequently or something like that. For the inner loop where it's just going really tight, we actually think it's fine to just do imperative programming there. Why not? I mean, I'm sure it's a perfectly good imperative language if you want to use it that way. There's quite a couple of macros to sugar it up a little bit and you're doing it.
01:04:42
Speaker
And that's one of the things that we're exploring, too, is what is the interaction between these two layers? The very functional, purer data layer and the inner loop, which is just the world flowing between frames of the program and mutating itself. This sort of, how do you grace pulling the data shapes with one functional imperative programming like that? Yeah. So spending all this time and building all this game engine stuff, do you get any time to actually play any games?
01:05:12
Speaker
Yes, I mean, I'm trying to, like, I have to, no, I'm very susceptible to games. I don't know, I like, I have a lot of Steam games that I play. I like kind of weird, arty horror games and there's also a game called City Skylines, which is like a Sin City variant, kind of a very good one, but it's, there's something about it that's incredibly addictive.
01:05:40
Speaker
I think that some sort of a horror game or something, I think the one that I really liked was some time ago. I'm not a really big game player or anything. Most of the time I spend my life in Skyrim. But there was a limbo or something. That was a super cool game. Oh, yeah, yeah, yeah. I started playing Skyrim 3D. With VR, yeah, yeah. How is it? VR version of it.
01:06:08
Speaker
Yeah, I mean, these are all cool games. I think with, again, with RPGs like Skyrim, I wonder what would happen if you could incorporate more of the academic research that's being done into narrative. Again, these sort of solver-based systems, like there's a lot of work people are doing and kind of thoughts that they're doing, but I think a lot of it is maybe not directly implemented in these things.
01:06:37
Speaker
And I wonder if language we can just spin out a new programming paradigm, social closure would be a better fit for that kind of thing. Yeah, I was wondering, you know, one of the things we were, I mean, I'm interested in is like, how the, because, you know, you've got an art background. So how do the art assets get integrated, kind of, because I think
01:07:01
Speaker
My son actually is also doing games design and he's looking at the artistic side and his friends do some programming and he does the artwork and this integration of the assets and the programming are a little bit rigid, let's say. It tends to be that he does some of the artwork and then they integrate it and it's done and he's out of the loop at that point.
01:07:25
Speaker
Which seems a bit, that doesn't seem like very nice, you know. Is that something you could change or? Well, I think, so there's a couple of questions. One is, has to do with like the structure of assets. If you have a 3D model, that's a rather complicated mesh.
01:07:49
Speaker
usually define it in a 3D modeling program, like Blender or Maya or something. And then you bring it into Unity, and now it's available for public access and for Unity to slot into the right place so that it can exploit it cleanly. And by virtue of it being a mesh at all, and this is in the case of a 3D thing,
01:08:12
Speaker
That's a bit difficult to, that can be a little bit difficult as data because it's an arbitrary graph of points and stuff. So you could still probably come up with some cool ways of doing graph algorithms on it and 3D algorithms on it if you wanted to write that. But then there's other things like what's the mesh going to do and usually define that in terms of a skeleton. So like a sort of a
01:08:41
Speaker
a much smaller number of points inside of it, which determine how the mesh should deform when somebody raises their arm or they turn their head around and stuff. And that's easier to access programmatically. Or you could have a number of meshes that are each tagged with some information so that then you can mix and match them programmatically or something like this. And actually, there's one of the oldest
01:09:03
Speaker
like members of our community is this amazing artist, Joseph Parker, who every year makes some kind of thing in Arcadia. There was one where many members of the community, in addition to Parker, but I think Parker really made a game called Swapland, I think, where
01:09:22
Speaker
It's a little top-down shooter, but all of the monsters that you're confronted with are generated on the basis of other assets, and so they're just programmatically cobbled together. It's really just a bunch of closure maps that are all functionally defined, and it builds these monsters for you.
01:09:46
Speaker
I think that in that sense, you can at the asset level actually have a way of structuring assets that lends itself to programmatically nice data. Usually, you don't.
01:10:05
Speaker
But you could. And I think you could have very powerful results by going down that path. We've already seen some instances of that. Another way, and there's another thing you mentioned, which is that just these tended to be two different people, like the programmer and the artist, and living in a different place, which is problematic if, and this is, there's many reasons for that, but one of the problems you get is in trying to put a kind of holistic product together, right?
01:10:34
Speaker
What we hope is that if you're in a situation where you can actually have the designer or artist sit down next to the programmer and have the programming process be fast enough that the artist can be like, oh, actually, I kind of want it to be like that, right? You can do it as fast as they say that. So a much, much faster feedback loop and iteration cycle between what are usually two very different sides of the production process. I think that could be really, really powerful.
01:11:06
Speaker
I think I was trying to remember if I heard your name before or something because the processing thing that I was talking about, I did something with almost six years ago, seven years ago. There was something like an earlight calendar thingy. Yeah, I worked on that for a moment actually. Yeah, so I think I was the guy who inherited your code.
01:11:29
Speaker
So I was the guy who picked it up and then I had to make it more web application sort of thingy. So that was my experience with processing. It was funky though to make that kind of things with Closure at that time. Good times.
01:11:47
Speaker
That was like in the very early days of ClosureScript too. Yeah, I think so. Yeah, pretty much. ClosureScript and then Quill was pretty new as well. So it was almost six, seven years ago or something like that. Yeah. Yeah. That was a pretty interesting project. And especially with the, I had to put all the astronomical algorithm stuff by copying from C++ and trying to figure that shit out. So that was super fun. Anyway.
01:12:14
Speaker
I think creative stuff in Closure, again, is a really good fit.
Clojure and Arcadia's Creative Potential
01:12:21
Speaker
Closure is usually used for server-y stuff and data stuff and these big enterprise-y applications.
01:12:31
Speaker
But it also works in a much smaller form, I think, like phone. So you're based pretty much on the Closure CLR thing, but aren't you a bit concerned about Closure CLR being like a follow-up, following project rather than, you know, like, because most of the efforts Rich and the gang are putting are basically on JVM. Yeah.
01:12:57
Speaker
This is one of the weird things about sort of where we stand. So one point is that David Miller is continuing to, like, CloyoCLR is up to date. CloyoCLR doesn't actually move that fast. It's not really a fast changing target. Sometimes it feels like it's kind of done, right? In a good way.
01:13:22
Speaker
Yeah, I mean, it just doesn't change that much. And what we realized for that is that design work is really hard, right? You have to get it perfect. First, you have to get the first time perfect. And that's really tricky. I also think that, yeah. And we're going to have to make some decisions too, especially with the type things that might deviate a little bit from the JVM.
01:13:51
Speaker
Our philosophy is just like, so be it. We get the core library. We get the core system in place. Changes to our expectations that changes to the closure of JVM are going to sort of trickle in over time. And we'll update to them when we get around to it or when somebody in the community wants to help us out. This is all open source. But in the meantime, we have a working system that you can make games in. We see closure as a means to an end.
01:14:22
Speaker
And we are already compatible with a certain version of Closure, right? There's no promise of full backwards compatibility with every Closure library in the same way that there isn't between Closure script and Closure. Very, very different system. So what is the plan for Arcadia then? Because there is this open source component that is essentially the programming environment. Can I say that
01:14:48
Speaker
Acadia is a game programming environment with Unity with closure. I just call this system because it's the framework. So that is going to be open source, right? That is the open source product. So what are the next plans? Where is the project going to and what are you working on? If you can reveal some details.
01:15:14
Speaker
I can't get into too many specifics about what the next thing is going to be right yet, but for us as a company, as Arcadia Technologies, we are working, but I will say that we are working on game development products. And game development products, you don't have to be a closure user to use them.
01:15:35
Speaker
It is to make any developers that are equally applicable to C-sharp developers. We think that's really important because nobody's using Clojure. There's a bootstrapping issue here.
01:15:49
Speaker
The, for Arcadia itself, we, so it's out there now, it's in beta. And as we go, we're going to be updating it. We don't foresee huge changes to it moving forward. We want a lot of that kind of thing to be expressed as libraries.
01:16:07
Speaker
One of the things that we're going to get is an integrated package management system. Exactly because we want to really encourage user libraries here and code reuse. And that will allow us to keep Arcadia relatively small and hopefully relatively low maintenance.
01:16:28
Speaker
And so right now is it at a stage that I can build my game enclosure and then actually get it to publishing? Like can I publish a game already? Yeah, with a couple of caveats. So right now we don't support export to iOS.
01:16:47
Speaker
Okay. Because you can't emit types, right? You see, you can't actually evaluate code in what Closure does. Unfortunately. But is it still true, though, because we have REPLs and Python as well? That's using JavaScript core. I think that's the difference.
01:17:10
Speaker
No, but because we have this ISH or something that's still in beta. It's like a shell on the iPhone, and that has Python now. I'm not sure what they're using, but. Yeah, so it might be interpreted. It might not be actually emitting executable code. Oh, OK. Or at the bottom, machine code. I think it all uses JavaScript code at the bottom, all the dynamic stuff. Right.
01:17:37
Speaker
All right, so that's the one caveat. It's a pretty big caveat, I know. As we continue to do work on Magic, we're going to get to a place where you can actually export it to iOS. OK. Because that's one of the biggest platforms, at least for casual gaming stuff. Yeah, it doesn't really make sense to make a game that can't export to iOS as a casual studio, if you're targeting mobile.
01:18:06
Speaker
right in a lot of ways. But the, I might be saying, well, the products that we're envisioning, that's not going to be an issue for where we'll be able to get these products out of the door, even before we start. Okay.
01:18:26
Speaker
I'm downloading it. I'm really excited about it actually. I think it's a fantastic system. Your explanation actually has got me going because I've always kind of been a bit, I've seen the demos and I've always wondered whether, where is it at?
01:18:44
Speaker
you know cuz I know it kind of like where you were very active a few years ago and then it kind of like I guess for whatever reason it just did the noise went down but it's really great to see you back again because you know I don't mean to offend you totally like the
01:19:07
Speaker
And I think, well, again, there are these recent things with closure in the contribution process and everything. I think one of the issues in the background is just that when you're defining a foundational system, the pressure to get it perfect is paralyzing almost from a creative perspective. And closure is such a...
01:19:30
Speaker
You feel like you're dealing with like one geniuses masterpiece, like very individual. There's this guy, Rich Hickey, who kind of like descended from heaven and held up in a hammock and he like got a morphos and a beautiful butterfly came out, but you don't really understand it. And it's got all these like subtleties and details and opinions and stuff. And I think people can find that really
01:19:53
Speaker
humbling and difficult to touch sometimes. But it's also just a fun system to play around in and to do mad science tricks in. For us, the need to get it right, we felt that maybe a little bit too intensely. But we think we're there now. We're pretty happy with the system we wound up with.
01:20:22
Speaker
and the direction it's going in now. The other thing is that we didn't have funding or anything before. Yeah, right, yeah. So slow burn, yeah. Yeah, exactly. But now if you're trying it out, I will just say one last thing, which is that be sure to get on the gitter. Because the community of people using this is amazing, and people are incredibly friendly and very, very happy to answer any kind of questions and give people help.
01:20:49
Speaker
Yeah, that sounds great. I mean, yeah, I'm definitely up for it. And like I say, my son is and his friends are like they're a little gang of they're trying to make a few games and stuff. So when things are right, you know, when you've got a few more demos of the new system up, I'll start to encourage them. Yeah, definitely. I mean, okay, fine. Yeah. Yeah, cool. All right. No holds barred. So do it.
01:21:18
Speaker
All right. So that's a fantastic first episode of this new year. Thanks a lot, Tims, for your time. I think we learned like a bazillion things. Yeah, that's fantastic. I mean, this has been such a great episode. Thank you very much, Tims. Yeah, yeah. Thanks a lot.
01:21:38
Speaker
Thank you. Before we go, I do want to quickly thank a few Patreons, actually. We have to pay our attributes, pay our respects, tip our hat to people who give us a few tips. If you don't mind, I'll just quickly dive in there and thank four people. We're trying to do it four at a time so that it doesn't get overwhelming. The first one is Will Acton. Thank you very much, Will.
01:22:08
Speaker
awesome stuff. The next one is Nathan Peele, and Nathan has been a Peele junk, so this is email. The third one is Kevin, Kevin Harald Rierskog. I don't know if I'm probably horribly butcherizing that one, but Kevin works. I know Kevin.
01:22:32
Speaker
Thanks, Kevin. And the final one is a friend of the show, a previous guest, actually, Mr. Arno Boss, who's doing the Heart of Closure this year in Belgium. So shout out to Arno. Thank you very much. Yeah, check out the heartofclosure.eu, I think, website. And the Lambda Island, of course.
01:22:54
Speaker
Yeah, Lambda Island. And it is happening in August at some point. August 6th, sorry, August 2nd and 3rd. Check out the website. I think it seems like a wonderfully put together, very nice new conference. On the same note, Dutch closure day is almost sold out. We have, I think, seven spots left at this time.
01:23:17
Speaker
The CFP is still open, so if you want to talk about Closure or want to share your experience, go to closuredays.org. Do we have enough time to get someone in to make an Arcadia video game for Closure this? Yeah, that'll be super cool.
01:23:35
Speaker
Yeah, come on, Tim. Do it remotely, okay? Yeah, yeah. That would be amazing. Yes. So, live coding, how to make Skyrim in enclosure. That's going to be super awesome, exciting talk.
01:23:52
Speaker
So, that's it from all of us for this episode, and we'll see you again in a couple of weeks, I think. This has been a fantastic talk again. Thanks a lot, Tims. Yep, have a good one. Okay, bye-bye.
01:24:32
Speaker
you