Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
#81 - Lojban edition with Joshua Suskalo
26 Plays2 years ago
We had fantastic chat with Joshua learning a thing or two about coffi the clojure FFI and farolero that is bringing Common LISP conditionals to to clojure.
As far as we know, this is the first Clojure podcast to have Lojban in it!
We would love it if you can join us for first ever defn call in show live with Joshua on 13th February 20:00 CET on our discord https://discord.gg/dDWd75xC
Recommended
Transcript
Discord Call-in Experiment
00:00:16
Speaker
Hello, dear listeners. This is a small interruption on your way to enjoy the podcast with an announcement that should help you to enjoy it even more. We're launching an experiment on Discord to have a call in style follow up to the episode. You'll be able to hop into the call as well as text, questions and responses.
00:00:38
Speaker
Our guests has kindly agreed to be part of the experiment. We'll add details to the show notes and follow mine, VJ's or the at Deffen podcast Twitter account for more details. Okay, let the fun begin.
Introduction to Lojban
00:00:53
Speaker
Which is to say hello and welcome to Deffen.
00:01:01
Speaker
But who constructed this? Sorry, because I just pressed record. So I think we need to step back a little or rewind a little bit. So what is the language name again? So I speak two languages, English, obviously, because that's what we're talking in, and Lojban, which is a constructed language based around predicate logic. Lojban.
00:01:21
Speaker
Yeah. The existence of the language, like who created it is a little bit fuzzy because the original version is called loglan. And loglan exists as a result of a split because of copyright, where the original creator of loglan tried to copyright, he tried to copyright the language and it didn't go over well for him. But by the time all the court proceedings were over, there was already this fork. Oh, wow.
00:01:51
Speaker
Yeah. Language folks are not unheard of, but that's good. Yeah. So, the author of Loglan
00:02:04
Speaker
I believe was John Cohen. And the idea was to test the Sapier-Worf hypothesis, which is the theory or hypothesis that the language that you speak affects what kinds of thoughts you're able to have. And so the idea was if we have a more logical language,
00:02:27
Speaker
do people speak more logically? Do they think more logically as a result of the language having those primitives built in? And it was a resounding failure of an experiment, not because we weren't able to actually test anything, but because we didn't have enough people to have a reasonable... None of the logical people learned this language.
00:02:54
Speaker
Oh yeah, there's a ton of people who are interested academically in the language and never learned it, including an entire committee around trying to change the language. Almost none of them can see it. Like C++ committee.
00:03:06
Speaker
Yeah, pretty much. You know, it's like C++ community. They, they all write the standard, but they don't use it for their work. Um, so there's, there's a community of people who do actually speak the language. Um, like I have a number of friends that I don't share a language with them besides Loshman and we're able to communicate just fine.
Lojban's Linguistic Features
00:03:27
Speaker
So it's able to work. It just.
00:03:31
Speaker
needed a few tweaks for usability past what was originally in there, um, in order to, is it also like a written language? Like, uh, there is a structured grammar and everything. And, uh, absolutely. Okay. The entire thing with the exception of a couple minor pieces that are used for, um, like conversation flow can be parsed with a peg grammar. So, um, and it is entirely syntactically unambiguous.
00:04:02
Speaker
Which means sentences like, I saw a man on a mountain with a telescope. It's ambiguous if the man had a telescope or if I used a telescope you see him. You cannot construct a sentence like that in Lózván. It cannot exist and be grammatical because it is
00:04:23
Speaker
a result of something called polysemi, which is a single word having multiple meanings. And that creates an ambiguous grammatical structure and an ambiguous semantic structure. And it just can't exist. So there are no synonyms in the language then. Oh, there's plenty of synonyms, but there are no homonyms. All right. Yeah. And is there a standard library?
Learning and Community of Lojban
00:04:49
Speaker
Yes. And a surprising amount of stuff that deals with quantum physics.
00:04:57
Speaker
There is a sigh. Yeah. Um, but yeah, so that is pretty cool. I mean, is it something that you can, you can learn online or is it, uh, I'm assuming there'll be a lot of online resources for this one, right? Yeah. It's a lot of online resources. There's a website, logpan.io or logpan.io. No.io means it's pretty recent.
00:05:21
Speaker
It's pretty recent and it's quite good. It's got like interactive grammar exercises, translation exercises. It's like dual lingo, but tiny. Yeah. Okay. So maybe the obvious question though Joshua is, you know, like, how did you get into this language? What made you kind of, what motivated you to learn it? Because it's, I've never heard of it and it's, you know, it's quite an unusual thing. Why do you have so much great time? That is the question, I guess.
00:05:50
Speaker
Well, why do I have so much free time? That's assuming that you have too much free time to learn the language. I think I had about three months between the graduating college and getting my job that I was just at home with my parents because they wanted me back for a while.
00:06:19
Speaker
And I picked up the language then because I heard some music in it and it sounded really cool. And then I read up on kind of the promises the language makes about syntactic unambiguity. And one of the other ones is audiovisual isomorphism, which is to say it is identical, written and spoken.
00:06:40
Speaker
Yeah. So a lot of people will look at it and like be confused by punctuation in it because you'll see periods in weird places, um, or, and like no quotation marks or anything else like that. But that's because it's entirely through words. Like in order to, it would be like speaking quotation marks and periods and other, other post punctuation marks. And they're a part of the spoken language. So there's like.
00:07:04
Speaker
These other pieces, and it has also one of the best methods for expressing emotion out of any language that I've seen. Because before Lojban, I studied like five languages, four languages, and never actually was able to speak any of them, despite studying each of them for multiple years. Yeah.
00:07:29
Speaker
It took me until I was learning Loshban to realize I was a language nerd, but okay.
Humor and Wordplay in Lojban
00:07:36
Speaker
You definitely got confirmation bias on that one. Yeah.
00:07:41
Speaker
But if you, if you don't have homonyms, then there is a certain, there is a big class of jokes, not possible. There is certain type of humor is not possible anymore in that language, right? Certain types of puns. So you can't make puns and you can't make, you know, double meaning jokes all the time. Yeah. There, there's all kinds of jokes that do get made that are wordplay, including those sorts of things, but they're different from the ones in English.
00:08:06
Speaker
Yeah, yeah. So you can't use the same word to mean two different things because that is basically the butt of the joke in some times. Or... Well, he said there are synonyms. Yeah, there are synonyms. But if you use a word in one context, there is this Zafranq video on YouTube. The guy makes super awesome comedy, not comedy, but natural history things. And he always says, you know,
00:08:33
Speaker
but john and then oh but you know he uses butt to sound like butt b-u-t-t but not but so that that kind of things were not possible right using the same word to make weird jokes
00:08:46
Speaker
Or the classic dad joke, I'm hungry, hi hungry, I'm dad, isn't possible. There's a lot of jokes like that that aren't possible in Lózefan and that's true. But there's a bunch of other ones that are. You're not losing much. Exactly. You're stopping the shit getting into it, so that's pretty good. It's like a compiler that's automatically telling you that bad humor is banned from this line.
00:09:19
Speaker
Not yet, but there might be. People have been working on ways to translate it to Word2vec and other stuff like that in order to try and get it in other translation engines and other similar work. There's like four different programming languages that have been started and been at least specified. I don't think any of them have like a complete runtime yet.
00:09:43
Speaker
that are written in the language. I've started one of them. It's a prologue-like language. Nice. This is amazing. This is absolutely amazing. Yeah. I think this is the first Lojban edition. I'm not even sure if I'm pronouncing it correctly anymore. Lojban. Yeah, you're pronouncing it much better than
Lojban's Vocabulary and Structure
00:10:06
Speaker
Lojban. How do you spell it? L-O-J-B-A-N.
00:10:11
Speaker
Uh, okay. That's why you can say my name. Sorry. Is it B or P? Uh, B.
00:10:19
Speaker
Okay. Yeah. Sound like auto ban in Germany, like a highway road or something. Nice. But what is the, where did the word come from that has meaning in the same language? Is it like a recursive thing? So the vocabulary in the language is entirely, or the core vocabulary, like group words are, are generated by averaging the transcribed by English people sounds.
00:10:49
Speaker
of the six most common at the time of creation spoken languages around the world. That included English, Mandarin, Arabic, I believe Hindi and Spanish and one other one. Russian, I think, I think Russian.
00:11:15
Speaker
Um, but yeah, so there was six languages transcribed by people who speak mostly English. So perfect. But, um, I mean, mostly, mostly spoken, then I assume like top five is going to be some five Indian languages, given that we are like one billion more than a billion people. And it's just Chinese and different types of Chinese languages. Yeah. It's, it was.
00:11:41
Speaker
Certainly not the most accurate in terms of actually waiting by population. Yeah, I wouldn't give it credit for that, but it tried. Okay. So as a word is a compound word from which means logic and which is for language. Okay, so is just a compound word of those two.
Lojban in Programming Contexts
00:12:10
Speaker
Wow, this is the first time ever I think we are having a guest who is speaking a decent language, you know.
00:12:18
Speaker
Well, I think the obvious question is, is there an Emacs mode for it? Yes, there are two Emacs modes for it. One of them is a dictionary search. The other one is syntax highlighting for particles and verbs. Well, that means it's a legit language. There is no question around it then.
00:12:41
Speaker
If you have said no, then, oh, this is bullshit. I mean, this is not real. This is not real. This is useless. And then immediately you said, Emax, OK, this is real and it is very useful. I expect you to be speaking in the next episode.
00:13:00
Speaker
I mean, that means our audience is going to go from two to one. It's just going to be Joshua. I mean, we can speak a sample if you want, but it's always hard coming up with something to say on the spot. Yeah. Well, you could say, you know, something along the lines of, you know, uh, I like closure because, you know, and you could, you could just give the first top reason for that in the Losh pan.
00:13:40
Speaker
I like Closure because it has an Emacs mode. The actual translation is more or less, I like Closure because it allows me to express solutions to problems in using simple stuff.
00:13:58
Speaker
So that, that took a pretty long time to say that maybe it's because it's very specific. It's less dense than English. It's about the same level of density as a Japanese excuse me, sitting on my shoulder.
Language and Humor: E-Prime Discussion
00:14:16
Speaker
Yes. So the people who are, who are listening, but not able to see, there is a beautiful cat on the shoulder, speaking in the low to Joshua in his ear.
00:14:27
Speaker
Is that a little root around your room, isn't he? He's going down, then he's going around and he's going to back up your shoulder. He's going down again. It's quite fun to watch. Yeah, she likes sitting on the back of my chair and then just headbutting me. I don't know why, but that's what she likes doing. Nice.
00:14:46
Speaker
I think, speaking of the specificity of the languages, I remember reading, maybe I mentioned this on the podcast some time ago, I'm not sure, because in English, there is also this, as you said, like, you know, how language affects our thinking. Like in English, you have this ease of P forms, like ease was and all this shit. And then they say that you conflate two different things, like asserting facts versus expressing something.
00:15:14
Speaker
So we just keep using the V forms to get away with shit without actually mentioning what you're supposed to say. Sun rises and he's rising is a fact versus, oh, it's hot. So instead of saying, I feel it is hot or something. So there is a E prime mode, obviously, in Emacs to use. And there is language called E prime.
00:15:38
Speaker
which disallows or which doesn't allow to use any of the B forms anymore. So essentially you cannot say to be or not to be in A prime anymore. So there is this, um, there is, I think there is a guy who actually wrote a novel and like English without the. Yeah.
00:15:57
Speaker
So without the, without the B forms at all, like ease was, or are, no, you cannot say that. So I cannot just say, you know, you know, the water, the water is good. I cannot say that anymore. I can only say, I think, um, I feel, no, I don't even fucking, I enjoy drinking your water.
00:16:19
Speaker
Yeah, exactly. I enjoy, yeah. There must always be like some subject and object, and then there is something linking that one. There is a correlation must be there. Otherwise, because it might be good for me, it might not be universally good. So you cannot conflict universal truth with this one.
00:16:36
Speaker
Oh, I enjoy drinking this glass of water. Right. Exactly. Yeah. At this moment.
Deffen Podcast: Episode Introduction
00:16:45
Speaker
Time and space. Fucking exhausting to read that shit though. Yeah. Yeah. I can see that. It's like, Oh my God, please. You know, I get it. Yeah. Can we just shorten it now?
00:16:58
Speaker
I think it really forces you to learn more verbs in the language because otherwise you keep just putting ease everywhere. You don't need to think about what you're going to say, actually, which is pretty interesting. Anyway.
00:17:13
Speaker
Yeah. But yeah, so I think it's a good time after 15 minutes to welcome it to the podcast.
Joshua's Programming Journey
00:17:20
Speaker
Yes. Welcome to Deaf and episode number, I think this is 81, most probably our last episode for this year. Excuse me. Okay. So I tried to mute the sound there, but I missed what roll. I have to fix that one in post right in the middle of the introduction. Let's try that one again.
00:17:43
Speaker
Okay. I'm going to say this again. Okay. This time don't sneeze. Leave it in. Come on.
00:17:56
Speaker
We've fucked up so many times on the show, how much time is it going to hurt? Fair enough. I think after 70 years, people are like, well, this is what we expect from the shit show anyway. On that happy note, welcome to the Deafend podcast. The Deafend podcast in Joshua.
00:18:16
Speaker
So, um, I think it's a, it's a good time to, you know, give us a bit of introduction about, um, yourself in English. Um, I'm pretty sure there's like hoards and hoards of people speaking large amount listening to the podcast, but I'm missing at least there are two more people who can only speak English than, than those people. And then also, I know tell, tell us about your, about your programming journey as well. Like how did you end up in closure?
00:18:46
Speaker
Yeah, so it's it's I don't know if I would say particularly interesting but it's been a bit of a long journey. I started programming when I was nine years old after my brother discarded a book on game programming because he found it too difficult and after going through it for like three months and I picked it up and went through it for a weekend and came back home the next day from the library with a stack of like
00:19:16
Speaker
12 ridiculous computer science tones that I had absolutely no business trying to read. And my dad took me aside and was like, here, we'll get you something better to start with. And he got me a Java book for Java 1.4 or something, even though I think Java 7 was out by then.
00:19:40
Speaker
When you were nine, holy shit. You're a young guy. Okay. Yeah. I'm, I'm a 23 now. Yeah. 23. Oh man. Okay. Good. Yeah. So I spent, um, yeah, I spent like eight years or something just working with Java and doing.
00:20:05
Speaker
Just like simple GUI applications and other things like that. Getting comfortable with that language. I did like some machine learning with it. I did like automation. Did you do the Minecraft plugins or anything like that?
00:20:21
Speaker
Uh, I did actually for a little while and I published a couple of them. I don't, none of them got famous or anything, but I did, I did make a couple. Um, I, I did like some financial automation software for myself. Um, like those kinds of things. And then I got to, uh, the AP computer science.
00:20:44
Speaker
I was homeschooled, so I didn't have this through a school, but I had an educator who was available to me, and he used Clojure, not for the AP Computer Science class, but on his own time, and he showed me a circuit simulator that he made using seesaw.
00:21:07
Speaker
And at the time, it just seemed like a weird language that I'm not sure I wasn't sure why you would pick it over over Java. But it kind of stuck in the back of my head, the things that he was telling me about functional programming and the style that could help make programs more effectively.
00:21:27
Speaker
Um, and then between then in college, I started branching out and trying a whole bunch of other different programming languages. By the time I graduated college, I think I'd used about 30. Um, and I went to college for game development. So like programming game engines, um,
00:21:47
Speaker
Like Unity or Unreal are game engines. They have hundreds of developers and millions of man hours into them, but it's the same thing. And that's what I went to school for.
Clojure in Game Development
00:21:59
Speaker
And in like some of the first courses of programming that I was basically dramatically overqualified to actually be taking the class. So I just had a lot of free time beyond the
00:22:12
Speaker
assignments i started to build a game engine and in a very very object-oriented style um and by the end of like the first month that i had i had like a menu system and a way to to swap out between like different states like if you're in a menu versus game loading systems and stuff like that but it was a complete rat's nest because of the fact that it was object-oriented and
00:22:39
Speaker
That might sound a little bit odd to people who still like object-oriented programming, although I don't imagine that there's many of them listening to this podcast. I don't think so. Leave the podcast.
00:22:55
Speaker
you're not welcome here but that kind of got me to think about what uh my pcs teacher had been telling me and it got me to try closure again and so i started learning closure with closure from the raven true
00:23:12
Speaker
And for the next like two months, I did all of my assignments in C++ like we were instructed to, but I also did them separately in closure and even submitted a couple of them to my teacher and they thought it was pretty cool that I was able to get them working as well. And that really made everything kind of click for me. And so by the end of the degree program,
00:23:39
Speaker
I had ditched C++ and was writing everything in C because I wanted to avoid object oriented programming that much. And I made a game engine that was fairly capable with like a Lua scripting engine and some other stuff.
00:23:54
Speaker
that was entirely without object-oriented programming. And that really got the ball rolling for me. And after college, I started diving into Clojure more and more and more. And at this point, I've released three I would consider relatively major libraries for the Clojure community. Some of them seem more usage than others.
00:24:17
Speaker
And those are Disclyord, which is a library for connecting to the Discord chat platform and providing bot applications for that platform using Closure. And all that's like core.async.
Joshua's Clojure Contributions
00:24:36
Speaker
There's ridiculous machinery behind the scenes in order to transparently handle sharding, some stuff to allow you to orchestrate
00:24:46
Speaker
splitting something across multiple boxes and coordinating between them. And the rate limiting stuff that Discord does is utter nonsense. And as a result, I finally got a really good use case for agents' enclosure. The second one that I need. That's not something people still use that much, right? Agents are like the one of the
00:25:16
Speaker
Yeah. So I have found that, yeah, Adams are the thing that everybody uses like all the time. Um, and that's, that's fair. They're useful most of the time. Most of the time they work pretty well. I have at this point in the last five years that I've been using closure is kind of like a primary language. Um,
00:25:39
Speaker
found good usage for every single one of the closure core primitives. For everything from delay to agents, refs, all of those, I've found good usage for them. But it is dominated by atoms. That's true. Yeah, yeah. I think if you see the original STM stuff when it was announced, like, you know, agents and refs and... People thought refs were going to be really... Yeah, exactly. That thing.
00:26:07
Speaker
I think everything converged to Adam. I think the rest of the stuff is now handled by other frameworks mostly. Interesting point about that is that nowadays people are moving to volatile. Yeah, I use volatile a ton, but only in things that I actually know the thread-constrained environment. I don't like sharing them across threads even though you technically can.
00:26:32
Speaker
Yeah. So for refs in particular, I found actually like only two instances that ended up being useful and it's because one of them was connected to working with, um,
00:26:45
Speaker
development time tooling where one of the references did not need to be changed almost ever, but the other one needed to be changed at runtime fairly frequently. So it didn't make sense to put it all in an atom because then I could cause contention at development time if I was debugging an environment, when instead I could just have them be refs and it would end up working out better. So this is all the Discord library.
00:27:09
Speaker
Yeah, that in the refs actually is used professionally. I work at Iris TV, which is a mostly closure
Error Handling Innovations in Clojure
00:27:16
Speaker
shop. Uh, and we do stuff in the ad tech industry for video context. Um, and that's where I've used refs. Um, the other place I've used refs is in Farolaro, which I'll probably get to a little bit later. Uh, but yeah, for, for discord, um, agents and, uh, Corey sink all over the place. They're the main concurrency primitives that I'm using.
00:27:40
Speaker
Okay. And what are the other libraries? Because if we mentioned around four of them right now already? Yes. I guess, yeah, three or four of them. One of them is a build library that I almost kind of don't count.
00:27:55
Speaker
Uh, there's, uh, there's Feralaro, which is a mostly faithful port of common-list conditions and restarts to closure. And I did this because...
00:28:10
Speaker
Every single condition system library that I've seen in Clojure is terrible in one way or another. I don't really mean that as a diss at the people who made them, but it's just that all of them solved a subset of the problem that conditions and restarts was designed to solve. And none of them are really compatible with each other. Yeah, it's better to explain
00:28:37
Speaker
what is the awesome stuff about Conditions Restarts? Because in Closure World, in Java World, we are used to this exception so much. I think in Common Lisp, there is a very elegant solution there, right? So maybe it's better to explain that one so people who are familiar with it. Yeah, for people who don't know, Conditions and Restarts is a system to decouple unwinding from error handling and error recovery.
00:29:06
Speaker
So there's three stages when you're dealing with conditions and restarts, as opposed to in exceptions, it's basically, um, error detection and error recovery, error detection happens when the error happens, you throw an exception error recovery happens somewhere up on the call stack. Um, but you lose all of the stack contacts, your local variables, et cetera, as you throw up the call stack, you lose all that context.
00:29:32
Speaker
The way conditions and restarts happen is you have your error detection. When you detect an error, you signal a condition, which basically asks further up the call stack to say, Hey, does anybody have something that handles a number format error? Like if anybody handles a number format error, then here's the error and you call it as a function and it winds the call stack for, it doesn't unwind.
00:29:54
Speaker
And inside of the handler function, which is what was just called, it determines what should be done about the number format error. And it does this by...
00:30:08
Speaker
either unwinding or by saying, I'm going to use one of x, y, or z premade ways that we could recover from this. And what defines what x, y, and z are available at the time is the code that signals the error.
00:30:25
Speaker
So whenever I'm going to write some code that might fail, there'll be a signal somewhere in it, but I'll wrap it in a block that specifies, here are three ways that I can recover if an error occurs. But the code right there never actually calls any of them. It's only called if something up on the call stack decides that we want to recover. And so the way that this works effectively is that you have code at the low level
00:30:52
Speaker
that detects an error and knows how to recover, but it doesn't know which strategy will be useful at any given time. So you might have a log analyzer that will see log messages that have an invalid format. And it'll say, hey, I found an invalid format message. You can either ignore it and not put it in your aggregate. You can put some specific value in here. Or you can try parsing again with a different format.
00:31:21
Speaker
But it doesn't know which one of those is going to do. Instead, it just signals this error. And then up on the call stack, you might say, oh, well, I'm in a thing that's just scanning for errors. And if anything doesn't match this regex, I don't care about it. So I'm just going to throw it out. But at other times, you might want to be able to actually track those. So it just allows you to express an idea of separating recovery from decision making.
00:31:45
Speaker
But how does this, so your library, so maybe, you know, you can explain how that works and how it interacts with existing flows of exceptions.
00:32:00
Speaker
So the way that it works internally is that it uses dynamic variables to bind the handler functions and the restart functions. The restarts are the recovery methods and handlers are called when you say go and error. Those are bound using dynamic variables. And then in order to unwind whenever it needs to get to
00:32:26
Speaker
the restarts or if you just decide to unwind as a part of your handler, it throws something that extends from java.lang.error, which doesn't extend from exception. The entire purpose of that class in the JVM is that it's not caught by saying code. There's an unfortunate amount of code that catches from throwable
00:32:51
Speaker
But I found that the majority of that seems to be in framework type libraries that will call your code. And then that throwable catcher is basically just making sure that there's some kind of harness so that it doesn't kill its thread that's like starting jobs or whatever. So it usually doesn't end up being a problem. The only actual
00:33:16
Speaker
problem that I've seen with that interaction is that the great library flow FM noise flow, um, which is for handling, um, errors as values, which is really good for data pipelining. Um, that catches throwable as well. So I, Ferro Laro has an extension inside of it that will detect if you have flow on your class path. And if it does, it'll load an extension to say, don't catch the, the, the unwinding mechanism from Ferro Laro.
00:33:48
Speaker
But the idea more or less is that it gives you facilities, especially for IO in terms of like, it allows you to write IO code that is more general because you don't have to bake your error handling strategy into your IO code. So if you want to do like retries or something like that, you can express that without needing to tie how you decide whether or not to retry to make them a request.
00:34:15
Speaker
But how did you how did you end up knowing about well, knowing is a bit, you know, condescending, I guess, because you started with C, C++, and then you went into Java already. And then because usually not many people I speak with, at least unless they have written some common list, you know, they don't know about, you know, condition systems or restart things.
00:34:37
Speaker
So how did you end up knowing this? And then did you write commonness? Did you learn it or? So I learned about conditions and restarts from special, which is one of the closure libraries that implements conditions. It doesn't implement restarts. And that's why I was saying that not all the libraries are.
00:34:56
Speaker
Are super good for trying to implement the whole idea. It's not that they're bad libraries. It's just that they don't implement the entire thing. Or they have problems with threads, which that's one of the biggest things with Feralaro that I was making sure doesn't break is you can use it transparently with reducers and all kinds of other thread mechanisms, even core async. As long as you're careful to not unwind past a parking take.
00:35:24
Speaker
Um, it works fine with core async, um, and all the other libraries like that. And the biggest thing with it is that it also has the debugger, um, which is the biggest thing that I think is missing from that's the biggest individual thing that is missing from all of the other libraries is.
00:35:46
Speaker
When a condition is signaled, that's an error rather than like a warning or something. If there isn't something that handles that type of condition on the stack, it will ask interactively from the developer to determine how to handle the situation.
00:36:05
Speaker
which gives you an opportunity to inspect your program as it's running. And it actually gives you a REPL that you can use from the context of where the error occurred to evaluate whatever forms you want before specifying which restart to use to continue the application.
00:36:24
Speaker
And then the way that this all connects to the larger closure ecosystem, because exceptions are a thing that is used in the closure ecosystem, is that the default debugger, instead of dropping in and asking the user for input,
00:36:42
Speaker
Um, you can turn that on intentionally, but if you don't turn that on, um, any kind of error that is signaled that doesn't have a handler will be wrapped in an EX info and thrown. So you, as a library developer, you're able to write code that uses Feralaro and not expose that to your users. If you don't want to, you just expose exceptions or you can expose it. It is internally using this restart or condition mechanism. Okay.
00:37:12
Speaker
Yep, exactly. And there's also a macro that I added, wrap exceptions, which just wraps a form. And if an exception gets thrown, it gets caught and then wrapped in a condition and signaled, which allows you to bind whatever kind of restarts you want, and then potentially just throw it again if you want to, without losing any context. Okay. But how did you
00:37:35
Speaker
Okay, I know that you were looking at special, but is it because of some production code? Is it because of some pain that you have seen in the production code using this? I am a conference talk junkie. So a lot of times when I'm working, I'll have conference talks in the background, and I'm pretty sure that there was a conference talk
00:38:02
Speaker
Uh, or I know for a fact that there was a conference talk that talks about the general mechanism, uh, that's used and they do it almost entirely with, um, just dynamic variables and no, no library. It was a library in this approach. Um, I'm forgetting the name of the speaker. Um, is it Chas Emerick? I just have a feeling or maybe it was Chouser. It was Chris Houser, actually, I think. Yeah, I think it was. Um,
00:38:32
Speaker
Yeah. So that clued me in onto the name. I'm a junkie as well, by the way. So that's fair. So that clued me in on like the name conditions and restarts so that I can search for it. And that's how I found special. And since then I have programmed a little bit in Common Lisp. I don't like it as much as I like Closure by a long shot.
00:38:56
Speaker
Um, but it is a good language. Um, and there are still some things to be learned, even though most of it definitely feels like it hasn't been updated since 2002. Um, like the fact that there's still no like standardized mechanism for threads. There are some libraries that allow you to like write portable threaded code, but it's not a piece of the language really. Um,
00:39:26
Speaker
Um, but I programmed in some it's in its, um, and that's what clued me in that special wasn't quite getting all the way to the dream. Um, special was special. Uh, special was special cause it put me on the right path.
00:39:40
Speaker
Um, and I have some plans for getting and repel integration with Feral arrow as well. So that way the normal repl in emacs and whatever other application you have, um, we'll be able to use, um, like the normal repl flow whenever a debugger is currently active. Um, that debugger, by the way, is the other place that I've used refs.
00:40:06
Speaker
because there's a very interesting problem that doesn't come up in common list because of this lack of a standardization of thread. And that is, how do you handle it when multiple threads error at the same time?
00:40:20
Speaker
And because there's only one standard out, there's only one standard in, you have to synchronize access to that resource to the programmer. But you have to do it in such a way that the programmer isn't stuck handling one error when others have occurred. Because you should be able to say, I'm going to handle this error later. I'm going to handle this other one first.
00:40:43
Speaker
And the ability to swap between them has led me to write a quite complex piece of code that's using like raw Java objects as locks using the locking macro in ClosureCore along with, I think I'm using some standard queues in there, but I'm not entirely sure. And I'm using refs in order to wrap them up. So the whole thing is,
00:41:13
Speaker
pretty complex. I'm happy that I don't have to, to write it that many times because it's just once and it's in there. I'm going to have to write it a second time when I get to N REPL integration because I need to have an N REPL middleware that will do that. Um, but, um, it was, it was quite a hairy piece of code. Um, but I, I learned a lot working on it and I'm very confident that it's working correctly now.
00:41:42
Speaker
Um, so that was, that was a very interesting piece of code to write though. Nice. Well, I've never seen any code with locking, um, the locking macro. So yeah, it's not usually called in the white. Um, I have probably used it a lot more than, than your average closure developer. That's fair. Um,
00:42:07
Speaker
I have a tendency to like I like closure and I like the performance guarantees that it makes. But sometimes they're just not good enough. And so I when I'm writing libraries, especially, I never want to force my users into making performance decisions.
00:42:29
Speaker
based on the code that I've written. So as much as I can, if I'm writing a library, I make everything
00:42:39
Speaker
as performant as I can possibly manage while still providing the same interface. Because that way I can prevent, I hate the idea of forcing my users into decisions. And so all of my libraries are based around that core idea. There's no decisions made for you.
00:43:03
Speaker
Cause I found that that works really well with the closure ecosystem of like you get little libraries for everything. You get frameworks for almost nothing. Yeah.
Java Integration with Project Panama
00:43:25
Speaker
work with coffee, but I ended up doing some stuff in Java. And it's kind of awkward, like you say, with closure depths. And I haven't, I haven't got to that bit yet. So maybe I'll just use Americano instead. Cause it's a different flavor of coffee. So, you know, yeah, it's all in black. You're taking your closure and you're watering it down with a little bit of coffee. Yeah.
00:43:48
Speaker
Okay. Or watering it down. Back to coffee, yes. Coffee is a foreign function interface library built on top of Project Panama, which was released in incubator
00:44:05
Speaker
in a form that is actually usable in Java 17. In Java 16, they had a decent bit of it available, but the API was very different and not as usable. But as a result,
00:44:21
Speaker
With Java 17 now, we have the ability to call into any C-ABI native code that we want using coffee. I want to note that coffee isn't the only library available in this space. There's other libraries built on top of JNA and JNI and a couple of other technologies as well.
00:44:45
Speaker
And those libraries are good, but I like writing game engines. And in a game engine, you can't afford to spend a lot of time marshaling data back and forth. And you can't spend a lot of time in overhead from needing to dispatch via GNA. So I needed as much performance as I could squeeze out of it. And so coffee is built using Project Panama, which is
00:45:11
Speaker
the most performant way to access native code from the JVM. And it basically is just a straight wrapper around the functions and classes that they provide, along with convenience macros to allow you to easily define a way to marshal closure data back and forth to native.
00:45:36
Speaker
and provide facilities to call whatever functions you want, even with callbacks that are just written as closure code, as if it was just closure functions. Go on. So I was going to say, maybe we should, because like a good conference talk junkie, I watched all of the talks about Project Panama in the background. So I kind of got all the different angles from the author.
00:46:05
Speaker
Great great project actually so maybe it would be worth having a quick chat around like what project panama is and what the goals were because i think probably a lot of the audience doesn't know it because it's a you know we're kind of like the majority of closure and we're stuck on java 8 or java 11 and like.
00:46:22
Speaker
Java as Java changes underneath, you know, it's kind of like, well, do we need to bother? And I think Project Panama actually gives us a reason if we're interested in these use cases to really leap forward to Java 17, because it's a fucking huge deal, in my opinion.
00:46:39
Speaker
Usually, I think when you're writing Closure, you're only interested in JVM, not the language or not the API that much anymore. Because you're just playing safe in the cushy area of Closure world.
00:46:57
Speaker
You know, well, okay, I'll upgrade whenever I want to upgrade, you know, you're already using closure, but this sounds a bit, you know, pretty interesting. So maybe as Ray said, I think it'll be nice to explain what, what project Panama is and what it is going to bring.
00:47:09
Speaker
Yeah, so the entire idea behind Project Panama is that it is bringing easy access to dynamically link against native libraries without the need to write native or Java code to do that.
00:47:29
Speaker
With the old JNI method, you had to write C code that would actually handle all of the marshalling of the data between the JVM and whatever native library you're calling. So you had to write C code, and you also had to write Java interfaces that would wrap all of that.
00:47:48
Speaker
I think it was actually more than just interfaces too. But there's also the library JNA, which is available on the JVM, which allows you to do exactly what I just said about Project Panama, where you get to write wrappers for native code that doesn't need you to write native code in order to link against it. But the problem with JNA is that
00:48:13
Speaker
It does symbol lookup and other forms of lookup in a very inefficient manner, redoing work a lot of the time. So the actual overhead of calling back and forth through JNA ends up being very high. So one of the libraries that I used to benchmark coffee
00:48:35
Speaker
is GLFW, which is a library that's used for native windowing across platforms. But one of the functions that it provides just gets time since the library was initialized as a double. And that's a very simple piece of native code. It does very, very little work. But if I were to call it with JNA, it takes around 300 nanoseconds
00:49:04
Speaker
versus with coffee, it takes about 30 to 40. So the difference is ridiculous when you're calling a lot of native functions all the time. And since one of my primary use cases for this is writing an OpenGL game engine, I'm going to be calling OpenGL functions all the time because I'm trying to render my game at 30 or 120 or 160 frames a second.
00:49:30
Speaker
And every single frame I'm going to be calling dozens or hundreds or even thousands of GL calls, so I can't afford to have that much overhead on every single call that I make to Nativeland.
00:49:43
Speaker
And so Panama allows us to bypass all of that overhead and all of the work of writing native code. So that's what Panama is promising, is it's promising a way for us to interface with native libraries in a way that doesn't require massive amounts of work and that doesn't introduce massive amounts of overhead.
00:50:05
Speaker
Obviously, I have no fucking clue about all this stuff, so I'm going to ask the dumbest question, as usual. You said that you can also write callbacks in Clojure that is being called back. If there is no marshaling or unmarshaling of the data, then how are you consuming the data in the callback as a Clojure map or Clojure or whatever data structure? It doesn't require marshaling.
00:50:33
Speaker
But coffee provides ways to interact with
00:50:39
Speaker
Both native buffers that are just full of native memory. And if you're being called as a callback, you're going to get either one of these native memory handles as an argument or a primitive. And those two cases. So if you're just like making a function to add two numbers together, everything's primitives. And even though closure does boxing, coffee does work to unbox everything.
00:51:05
Speaker
which takes runtime code generation, by the way. I do runtime byte code generation using Ensign, which is a fantastic closure library for runtime byte code generation. And I use that in order to make sure that all of the types line up with what the JVM expects. But you get handled with native memory and primitives.
00:51:34
Speaker
But coffee also provides convenience wrappers for everything that ends up being kind of the default way that you deal with things, where you can specify types using a syntax kind of similar to Mali.
00:51:49
Speaker
that the data description that you give or the data type description that you give tells coffee how to serialize and deserialize that from these memory handles. So you can write closure code that works with maps and use that as a callback that's supposed to take struct. And coffee will handle all of the marshalling that you need transparently.
00:52:17
Speaker
And I think it's worth saying there's a kind of DSL in Project Panama as well for defining these native structs. So that's kind of like, I guess you're using that. I'm not using that actually. I didn't find it to be very useful working with Closure.
00:52:36
Speaker
Because one of the primary concepts with it is the idea of a var handle, which is basically a way to quickly access data inside of a struct by basically completing a path. So you say it's in
00:52:53
Speaker
Um field a which is an array get index two and then get field b on that like and you'd fill in Pieces there you'd say like, okay Well, it's a some index b and then you'd fill in like the index that you're gonna access like that's what the var handle idea is And none of that is very like congruent with the way that you access data enclosure
00:53:18
Speaker
Um, so I decided to just kind of ditch all of that and instead allow you to use, uh, the functions that I provide, which just allow you to easily access fields out of a piece of memory based on the type description, the Molly like type description that you give, uh, coffee. So you can just call a serialize or deserialize function and pass it the handle and the type descriptor, and it gives you back whatever date.
00:53:48
Speaker
And so getting nested fields like that can be a little bit finicky if you want to be as performant as possible. But in the cases where you want to be as performant as possible, I am perfectly comfortable with the concept of just handing the user one of these memory handles because it's an unwrapped Panama type and asking them to write Panama code to interact with that. Because if they need that performance, then they shouldn't be using my custom marshaling because it's using
00:54:17
Speaker
multi-methods, which are fast, but if you're trying to be so fast as to not un-marshal data, you probably don't want to be using them anyway. That said, though, I've put in a lot of work into the macros and the other stuff in order to make sure that if you write a function that doesn't need any of that multi-method dispatch, that doesn't need any of the marshaling and un-marshaling, coffee adds zero overhead.
00:54:43
Speaker
So there's no function call dispatch overhead for anything in the library if you're not actually using any of it. So if you have something that only takes primitives and returns primitives, there's just nothing that happens at all except for a cast. If you're dealing with something that takes and returns these memory handles, it doesn't go through any of this dispatch at all. So you're able to handle all of the underlying structures if you want.
00:55:11
Speaker
But it also provides facilities to make it so that calling native code is like calling closure code. And that's how I've wrapped libraries when I've been using coffee myself is to write code that results in what looks like a closure library, but is actually running native code.
00:55:30
Speaker
Uh, obviously the, the game engines are one of the primary use cases where near zero cost interaction with the native code is required. So where else do you think this is going to be useful? I mean, that means that you can use any native libraries, like any C code can be used to spray a coffee. Uh, what I've been thinking about doing, um, is.
00:55:56
Speaker
for any kind of application that I write that has like some performance critical piece, it makes it a very easy, the existence of coffee makes it a very easy choice for me to then go and write that performance critical piece of code in Rust and then wrap it in closure and then never have to worry about ownership again. Yeah, yeah, yeah.
00:56:16
Speaker
I think it's fair to say as well that the Project Panama people, I mean, you know, and you have to wonder like, what's the driver here? And the driver isn't games actually. Although obviously we're benefiting from that. The driver is talking to things like TensorFlow because they give you a C API. And that's the thing that they're really concerned about in the Java world is making Java talk, play nicely, sorry, not talk nicely, but play nicely with these kind of like low level ML frameworks.
00:56:46
Speaker
Or like the bullet physics for robotics or other things like that as well. Yeah, because I think until well, there is, as you said, with JNA native access and native interface, I mean, there is some sort of interaction with the native stuff.
00:57:01
Speaker
There has always been either you completely write the whole shit in Java and then make it available as a library. There is never easy reusability of the existing code bases which are in C, C++, or the native code available. That's not possible so far, but I think the idea that you say is pretty interesting for me as well because I've been doubling with trust a little bit.
00:57:25
Speaker
I think it makes sense that you can just fall back to if there is expression that you can just switch to Rust and then build the whole thing. Make it really fast and then just use coffee as a low cost or almost no cost, you know, FFI into that one. It's super cool actually. Nice.
00:57:47
Speaker
Yeah. And that means that, you know, you've got kind of all these low level performance wins, but you've got a nice high level of expression language like closure. So exactly. And that's the same draw that like Python has in the ML world is that it's a nice high level language to interact with all the low level C stuff. And you just get to also do that in closure without needing to use like lib Python CLJ in order to call Python to call TensorFlow.
00:58:18
Speaker
There there are there are other closure libraries that have kind of similar goals and and one of the good ones is um Oh, I had the name of my head just to see type next I think yes we type next that's that's it. Yep. So that's also a very good library um the the difference that i've noticed uh between the library that i've written and a couple of the other ones is that um
00:58:43
Speaker
My library is focused on usability from the closure side a little bit more than some of the other ones are. Not to say that they're difficult to use necessarily, but that there's more convenience features for users in coffee and that they're designed in such a way as to not introduce a lot of overhead.
00:59:02
Speaker
And, um, my experience with dtype next is that it seems really good for like array programming, kind of in the same vein as like APL or something, um, where all of the array stuff stays in native memory and never, never comes over into Closureland.
00:59:15
Speaker
and you can do that stuff in coffee, it will be less convenient than in Dtype Next. They're not necessarily incompatible libraries, though. I believe that at least on JDK 16 and probably soon JDK 17, they'll use Panama as the back end for Dtype Next as well.
00:59:36
Speaker
Which means that once dtype-next gets updated to Java 17, its performance will probably be pretty similar to coffee. But again, the focus is a little bit different because dtype-next is all about keeping these big native memory slabs and operating on them from closure versus coffee, which is focused on either just providing you access to all the handles that Panama does or giving you access to call it like it's closure code.
01:00:06
Speaker
And.
01:00:07
Speaker
The other difference there is that Dtype Next targets multiple Java versions, which means it targets multiple FFI backends. And that means it provides a different interface, which means they have a harder time providing Panama as like a key central feature. And Coffee, I think of Coffee being hosted on Panama kind of the same way that I think about Closure being hosted on Java. It's not just an implementation detail. It's part of the core interface that's being provided.
01:00:37
Speaker
Nice. So before, before we go into other, you know, less important things.
Literate Programming and Emacs
01:00:42
Speaker
So emacs or some other shit. Not one, not gonna do two fucking bites at this one. I'm talking about other stuff.
01:00:54
Speaker
Okay. So I have three different Emacs configs. One of them is entirely custom. You win. Moving on. We don't need to just beat out Emacs to you. That's it. You win. It's Emacs to the max.
01:01:16
Speaker
Let's go through each of them one by one. Line by line. Why three though? So one of them is for work. It's like my old Space Max config that I was working with for a while. It started to get too slow. So I'm working on a Doom config.
01:01:35
Speaker
Yeah. And that's what I'm using on my personal machine. And then the third one is like an experiment, me trying to figure out why the hell someone would do, uh, literate programming. And it's still unclear after having written a lot of code. Um, but it's, it's, uh, it's when I do try, obviously I keep on wanting to like literate programming. It's just very hard to like.
01:02:02
Speaker
I think we, I did try doing the whole notebook world is all built on that, isn't it? Pretty much. Yeah. It's not, that's exactly what it is. Yeah. I don't think people are using notebooks to do like literate programming. I mean, it's just like cells of code. Yeah. The idea is to make the paper and do the, do the programming in the middle of the paper. Yeah, fair enough. Yeah. Yeah.
01:02:29
Speaker
That's true. And there are some good examples of, like, literary programming. For example, there's the Physically Based Rendering Book is a book that's written entirely as a literary program. Yeah. But isn't it a paper or something on Closure Code Base as literary programming? Yeah. Yeah. Yeah. That was a long time ago. Yeah. Ferret is a list that's designed for embedded programming. And it's written in Closure as a literary program. Yeah.
01:02:57
Speaker
And it's an interesting code base for sure. Yeah, but I think that the main thing that I found with later programming is that the code base or maybe I've been in that that tells more about my coding skills rather than later programming. But anyway, I think code is not linear, right? Because you it's it's very difficult to linearize the code because there are modules, there are interdependencies and
01:03:25
Speaker
Because literary programming assumes that you can read it like a book from from end to end, like a story, which is like global. Yeah, exactly. I tried solving that in in my own I tried solving that in my own projects by not sticking to the there is one document rule. Yeah. And instead splitting up and having modules be their own books and even splitting it up to try and make things so that
01:03:52
Speaker
Instead of it's like the whole program is one text that you read. It's like each piece of the program is one text. And then there's a final text that pulls everything together and basically is only cross references. Yeah. Even with that, I still couldn't really find it as something that was useful to my programming. And that might just be because I have like abused myself into reading code more clearly than I read English.
01:04:19
Speaker
That might just be what it is, but... You speak Lojpan, I mean, come on. Exactly. You're a difficult bit of anecdote, I think. Yeah.
01:04:41
Speaker
I think it never, I was intrigued by the idea and I like it in theory, being able to express that this is the idea and this is how it looks like code and then using art mode to tangle the code into different files.
01:04:59
Speaker
It's fun to think about as a theoretical experiment, but I don't think, was it Kanuth? Yeah, I think it was from here. Yeah. And I never felt like, you know, well, maybe in Closure, it is still possible because, you know, you can just use Declare and then, you know, make it make it linear more or less. But rest of the code bases, they're never linear. They're always dependencies.
01:05:24
Speaker
And you just give up like, Oh, fuck it. You know, I'm not gonna, I'm not gonna spend like explaining, you know, a lot of the rings level text to print a plus B like, okay, no way. And I think if you think about threading pipelines, you know, like the thread macro is a tricky one. There was another conference talk about that actually, about how you can.
01:05:47
Speaker
put some macros around the thread macros to make it more literate and more, uh, maybe you remember that one, Joshua. I don't remember. I do. I know the talk, but I can't remember the bloody author or the framework, the other library now, but, uh, I'll look that one up for the show.
01:06:04
Speaker
That's a call to an audience, but at least we did. Wasn't, wasn't that one also the talk that ended up introducing Azero, Condero, whatever. Could have been several bang something like that ridiculous thing. Possibly. I don't want to, I don't want to cast aspersions though. As thread aspersions.
01:06:29
Speaker
Anyway. Yeah. But what I was going to say was that, uh, that, that, that is the problem with, with like programming. The thread first thread last backwards question mark as arrow Condero bang is the name of the library.
01:06:45
Speaker
I like, I like the kind of names, you know, it just, it's what you see is what you get or what you read is what you get. Yeah. So yeah, this is, this is from a different talk. This is from every closure talk ever. Oh yeah. Which is a different one from the threading that we were talking about.
01:07:02
Speaker
Yeah, I think I've seen the threading one as well. Uh, my favorite like abstraction to throw in with. Threading macros though is just a when pred and if pred where it takes the values, the first argument, a predicate as the second argument. And then a third argument as a function to run if it returned true. And I've not found that in any of the utility libraries like that I've, that I've looked at whether it was like based on threading or not. And I don't know why I've never found it in one, but it, it's very useful. I use it in my code all the time.
01:07:33
Speaker
Can you say that again? I must have been slightly screwed for that one. So when pred takes three arguments, first argument is the value because you're using it inside of a thread macro. The second argument is a predicate. And if it returns true, you call the third predicate on the value before returning it. And if it returns false, then you just return the value without changing.
01:08:01
Speaker
Right. Right. And then if bread is the same thing, except there's an else. Yeah, there's a branch function. Yeah. But isn't, isn't it? Cause that's the only thing about like when, when enclosure is always a bit odd to me is that by the else is actually nil, you know? Yeah, that that's true. Um, which makes it a little inconvenient inside of threading macros. Yeah. Yeah.
01:08:28
Speaker
So, um, what, what else? Um, so we talked about, uh, the, um, uh, well coffee as well as the condition system and then discard thing under a small build, uh, library as well. So I'm, I'm really surprised how not surprised, but I'm really amazed by, you know, how much knowledge you accumulated within this time. And when I was 23, I was trying to figure out how to make a,
Critique of Clojure's Error Handling
01:08:55
Speaker
VB button do something, you know, that's my, uh, that's my achievement, you know, back in the day. So I'm really amazed by how, how many things that, that you dug into and then how much knowledge acquired and including, you know, all the way from C plus plus until a common list thing. And I'm curious, you know, um, about your ideas of what sucks in closure, because you wrote C plus plus, and you're now providing a way to reach into the native world.
01:09:25
Speaker
Um, when would you say, well, this is not something that I would do enclosure or when would you say, well, this is pretty shit enclosure. You know, this is going to sound kind of funny considering the library that I just thought was talking about air handling, air handling is awful enclosure. Yeah. It is, it is terrible. Um, there are good libraries that can pull in to make it better, but the fact that we don't have a default error handling strategy besides throwing exceptions, which.
01:09:55
Speaker
Maybe I have to make the argument that throwing exceptions is a terrible way to do error handling, but I think that that's the case is that it's, it's not a good way to do error handling. And so in diskly or, um, this is the first like major public library that I made. I had no idea how to do error handling. And as a result, that code base does not throw an exception except for an illegal argument exception. When you try to start up the thread for the first, first time.
01:10:24
Speaker
That is the only exception that occurs in the entire code base. The only other way that I interact with exceptions is trying to catch exceptions that are thrown by user code. There isn't really any other error mechanism inside of it. And it's because error handling enclosure is terrible because you basically have
01:10:43
Speaker
either, um, nil punning, which is okay. If you want to like ignore some kind of data error, but it's terrible. If you want to understand what's happening in your program, um, throwing an exception is great and all for getting a log of like a stack trace. If something actually went wrong, but I treat it like a panic and rust, you throw an exception when you can't recover.
01:11:05
Speaker
And so all that's useful is a stack trace and you can't really get anything else. Um, using errors as values with flow is really nice and it works well for data pipelines. But when you're not writing a data pipeline, which considering how many IO libraries I've talked about that I've written, like I'm not always doing data pipelines. So I'm stuck with basically no, no good facility except for the one that I wrote.
01:11:35
Speaker
And even that one could be better. And part of the way that it could be better is if it was integrated into the library ecosystem. Not necessarily the language itself, but like the library ecosystem. If people were using it, it would be a more pleasant experience to use. But that's kind of like a chicken and egg problem.
01:11:59
Speaker
I think that's what ended up being the thing of Chris Howiser in the end. He was saying that it's like putting it into the libraries, putting it into things, it's just impossible. So here's some ideas about how you can handle, you know, problems.
01:12:14
Speaker
But it was kind of like almost a kind of a hands up in the air, kind of. Well, yeah, that, that kind of error handling with just the, the dynamic variables and providing that as a part of the public interface is part of what I provide as a, uh, instruction for library authors in the README of Feralaro. Um, I give utilities for library authors in order to make things that can integrate with the ecosystem.
01:12:42
Speaker
And I think it's mostly just that either the library isn't old enough yet, or people haven't tried to use it, or maybe it sucks. And I'm the only one who doesn't know. We're getting a word out here. Expect a huge uptick in adoption next month or two. That would be pretty cool. 2022.
01:13:02
Speaker
It is currently my most starred repository, so we'll see how that goes. There's a bit of code, like there's a bit of pornography going on there. I love the idea of watching it, but not quite using it. Yeah. But isn't it something like, you know, the, the, the philosophy of the language itself, right? I mean, in Rust, you're, you're, you're always using a result and you're always like kind of, it's like a, you know,
01:13:29
Speaker
idiomatic way of doing things. And then enclosure being a dynamic language. And I don't think anybody cares about, I've seen so much of closure code where it only deals about happy path. Nobody cares about exception because it's not there. Obviously it's not forcing you, you know, and nobody thinks about, Oh, you know, like the conditions or he starts or because happy path is working and fuck it. And I'm done. And then it's when people are using it, when it blows up, they know what to do. You know, like that's, that's, it's more, you know,
01:14:04
Speaker
Garbage-in-garbage-out philosophy is fine. I actually don't mind it. That's how Discord works. I have everything internally specced, and if you turn on instrumentation, everything will be fine unless you fucked up somewhere putting something into one of the functions that wasn't supposed to be there, and then everything will blow up. And I don't have a problem with that. I consider that just the documentation is the specs. You can look at them. That tells you what you can put in there.
01:14:27
Speaker
Yeah, the garbage and garbage out philosophy.
01:14:32
Speaker
Um, and if you turn on instrumentation, you'll see what's going wrong. I don't have a problem inherently with the garbage and garbage out. What I have a problem with is when things that are errors that are part of the happy path, because those exist, there are happy things that are errors and closure doesn't have a good way to handle those.
01:14:55
Speaker
And because like everything from honestly even baked into the language is the what I feel about this because EX info is a terrible mechanism for signaling errors.
01:15:12
Speaker
because of the fact that it requires every single person who catches one to check to see if it's actually the EX info that they think it is. And if it is, then do something about it, otherwise re-throw it. And if they're not doing that, it's because they're not considering what happens when someone else's code is running inside that context.
01:15:30
Speaker
And people don't think you're right. People don't think about errors that much, but I think that's just an unfortunate aspect of, um, the escape from Java, honestly, because in Java, we spend like half of our code by lines of code inside of a catch block.
01:15:49
Speaker
Like everything is a catch block. And if people are escaping from Java, part of what they're escaping from is that. And I can appreciate that. And I can appreciate that it is nice to only worry about the happy path. But it just leaves us in a situation where it's less than optimal when you have to actually handle an error.
01:16:18
Speaker
Yeah. Yeah, that's a fair point. Yeah. So I think- I think there was, I think one kind of like saving grace from this though.
01:16:31
Speaker
It's not the perfect retort, but the fact that xinfo is now data is a lot better than raw exceptions prior to 1.9, I think it was. I think there is progress being made there, but you're right. There's still a lot of work to be done for sure.
01:16:55
Speaker
Like there are libraries in that space that help out and they do help out and they're, they're good. Um, but I don't think that they really solve the core issue necessarily. And I, I can't say that I necessarily know what the core issue is. The reason that I wrote Farol arrow in the first place was to see if having that facility would help me realize what the core issue is because.
01:17:22
Speaker
Um, as I experienced when I first heard about closure in AP computer science, all of the things that you can do in closure just seemed like weird things that someone else would want to do, but I have no reason to. Um, because I was in the Java mindset and working with closure before working with Feralaro, I have been in the nil punning and happy path mindset. And I figured.
01:17:50
Speaker
If I, if it, if error handling feels bad and I don't know what the core issue is, maybe if I try this thing that someone else thinks is the solution to the core, the core problem, maybe I can start to understand what I think the core problem actually is. And so I wrote Faroe Laro so that I can try that. And in the last six months, I've gotten to use it, um, both in production at work and, um, on my personal projects. And I think now I'm at the point where I have enough experience using it.
01:18:20
Speaker
Um, that I'm pretty comfortable with the facilities that it provides. And I'm hoping that in the next like three or four years, I can actually finally figure out what the core problem is with error handling and closure. And then maybe I can write a library after that that will, that will actually solve the problem, but we'll see. But I think it's good to have ambitions on that bombshell.
01:18:48
Speaker
Yeah, I think before before, wow, we are almost, you know, one and a half hour. And I think we can keep talking forever. But I'd like to mention just, you know, the it's it's really the mindset, you know, problem, right?
Rust's Influence on Error Handling
01:19:04
Speaker
It's as you said, like we were used to so much in writing Happy Path enclosure and and
01:19:08
Speaker
If you switch to a language where it, it forces you to write, I mean, I write Rust with unwraps everywhere. I'm like, I don't give a fuck. I'm just going to unwrap everything and then continue. It's just obviously not, you know, the way, but it's actually putting it front and center in front of me. Like I'm doing some shitty thing here and sort of thinking. Yeah. And you can grep for unwrap and see where the problems are. You can't do that. You just grep dash V unwrap.
01:19:37
Speaker
Yeah, so so you know that you know, I think it's it's more like a mindset thing but Which is something similar to writing test right? I mean the the more time you spend thinking about the code and closure gives you this
01:19:51
Speaker
I'm probably going to be unpopular if I start talking about tests. I know. Yeah, but that is the thing with, I mean, I've seen this in Python as well. I mean, all the libraries, they just do like one thing and then they're happy. Fuck it. No design, no errors thrown, nowhere. You never know what kind of shit is going to blow up and down the lane, like seven transitive dependencies later.
01:20:20
Speaker
So which is something worries me. But, you know, hey, it's been working for Closure for 10 years, more than 10 years, you know, so maybe there is something and maybe people will pick up, you know, rethinking to make code more robust in that sense. Yeah. I mean, the fact that it's been going so well for so long tells me
01:20:43
Speaker
That even if it is like a fundamental problem that we don't know how to handle layers, it clearly isn't getting in the way of us actually solving problems. So it's not necessarily a huge deal. It's just one that I think would be beneficial to everyone in the closure community. Totally. I think it's a rough edge and it's okay to say that there are rough edges. And even if it wasn't a rough edge as such, innovations and improvements can always be welcomed.
01:21:13
Speaker
Like you say, especially in the user space where, you know, you're not asking for, uh, for the core team to change anything really. I mean, I guess that would be nice, you know, once you've kind of got down to the core bottom of it all and like, you know, you can sort of say, look, this is the fundamental challenge. Um, but on the other hand, like you say, if you're learning from, from common Lisp, then, you know, that that's already a great place to start. Um,
01:21:40
Speaker
Until you want an immutable data structure to work with a library, it's a good start. There are libraries that give you immutable data structures, but they don't work with the other libraries. You have to write everything yourself. So good luck with that. Common Lisp is a good place to start. It's a good language, but the library
01:22:03
Speaker
I just mean as a source of inspiration, you know, rather than a sort of, I'm not trying to advocate for common lisp as a language on the Closure podcast that we've been doing for a while. We came for immutability and we stayed for the error handling.
Appreciation for Clojure's Problem-Solving Focus
01:22:26
Speaker
Nice. Yeah. Awesome. I think, wow. Maybe that's it before we wrap up. Maybe since we already, since I already asked you, like, what is wrong with closure? Well, not in that strong sense, but what do you like about closure? That's exactly how you asked it, you know.
01:22:48
Speaker
Yeah, sure. At this point, I don't care anymore. I'm like, we're too popular to be awkward anymore. What do you like about Closure? Did you try Closure script as well or mostly you're doubling in the Closure side, JVM side?
01:23:09
Speaker
I like the fact that closure gets out of my way and I can actually like think about my problem space. I have like done more whiteboarding with closure than I have with any other language because the whiteboarding that I do isn't a U of L diagram because I don't have to think about all of that. Um, I like not being stuck in that. So instead I get to actually think about, you know, the problem space, how do I connect the pieces together? How do I decompose things into a set of reusable parts and then put them back together? Um,
01:23:38
Speaker
And that's, that's why I like closure. Um, and then what was the second question? Closure script, like, uh, do you, did you try, you know, other flavors?
01:23:51
Speaker
Yeah, so I have used Closure CLR on the Unity project Godot on Arcadia. I actually did like a game jam game with Ramsey, Nasser, and that was pretty fun. I did like an input system for one of the games that they did.
01:24:16
Speaker
Um, there wasn't that much code, but it was fun to get my, get my feet wet in that. I've tried, um, I've tried closure CLR for a couple of other things as well. And I've used closure script. Um, Farah Lara works on closure script.
01:24:33
Speaker
And because it's all CLJC and I had to do some shenanigans, the debugger doesn't work in ClosureScript because there's no standard in or standard out. But the rest of it does. And there's ways to connect the debugger if you want to. I've used ClosureScript for mobile development, and I've used it for some website development. I don't have anything that's public with it now. I really like using Expo for the mobile development with it.
01:25:01
Speaker
And last time I used it, um, even with fig wheel, like fig wheel main and shadow CLJS, it still could use a little bit of work on the reload ability aspect compared to JVM closure. At least that was my experience. It's really good. Um, but it could be better.
01:25:21
Speaker
Put it that way. Um, I don't use it for, for anything significant now, although I have been thinking about starting a blog to try and talk about the, uh, implementation decisions and stuff in the libraries that I, that I make and other stuff like that. And we're going to try and talk through those, those thoughts, even like I'm working on a. A compiler to compile closure code to GLSL in order to run closure on the G on the GPU. Um, and like.
01:25:51
Speaker
That kind of thing would be something that would be useful to like have like a blog or something. And I've been thinking about enclosure script. I think it makes sense. I haven't gotten around to it just yet.
01:26:02
Speaker
I think it's really nice to have that written down on the internet because it's much more searchable.
Encouragement for Content Creation
01:26:07
Speaker
Obviously, our podcast is the thing in the closure world, as you noticed already. If we are not talking about it, then it doesn't exist. That's the level that we have. But if you expect plenty of calls from cheap imitations, but this is where it all, this is the main thing.
01:26:28
Speaker
But I think it'll be really nice to, you know, I know writing a blog, you know, telling other people writing a blog is pretty easy. So I'm just going to do that. But because all these things, and we can only condense so much in 90 minutes, right? So there you can point to the resources point, explain the, you know, your thinking behind it, because you have amazing ideas. You're working on really nice libraries and, you know,
01:26:55
Speaker
moving closer to the next generation, bringing closer to Java 17 and all that stuff. So I would really urge you to write the blog post probably in English, not in Lojban. Yeah, English is far more likely. Despite the fact that most Lojbanists are programmers, there still isn't that much vocabulary for talking about programming yet.
01:27:20
Speaker
Uh, okay. I think the other thing to do, I think that some people are doing, I mean, you can take this, uh, anywhere you want, but I mean, you're, you're a great speaker and very fluid, um, you know, in English as well by the looks of things. So, uh, you know, I think people do things like on, on Twitch, on YouTube, uh, streaming, you know, and that could be something that you could do to kind of get, get, um, get the sort of, um, the people who want to, want to.
01:27:48
Speaker
watch these videos on the side, like us. You can get a bit more content out that way. And obviously the nice thing about things like podcasts is that you can kind of listen to them on the go. And I think if you have a blog, then I guess people can read it on the go as well by text-to-speech type stuff.
01:28:10
Speaker
But you know i think it's worth considering other media strategies as well because i'm definitely i think the stuff that you're doing having a kind of like interactive you know explanation of these things would be really interesting.
01:28:25
Speaker
I mean, I'm not on TikTok, but I would say, you know, just make a TikTok video like, why coffee? Then you know this and do a dance while you're doing it. Yeah. I'm considering the average age of Closure Developers. I'm more the exception than the rule. I don't think I'll get that much viewership. That's true. But I think, you know, this is the beautiful part. Like, you know, we are we are very happy to see that
01:28:53
Speaker
people talking about, oh, I started with Java 7. I'm like, wow, that's amazing to hear. And it's amazing to see people like you who are so young and getting into this one and also bringing so much of knowledge within such a short amount of time, which is really admirable. And I think you are probably inspiring way more
01:29:19
Speaker
TikTok generation than old age crappy people like me who never installed TikTok. I don't even know what the fuck people do on that shit, but anyway. Jesus. Well, but that's the thing, right? This is the time because the ideas need to evolve. The idea needs to get into the next things. Otherwise, just to conclude, when you said that people are not
01:29:48
Speaker
thinking that the error handling is a big deal because we are so used to our ways that this has been something in the closure thing since we started talking about closure because I've been doubling with closure for almost like maybe 10 years now. So the beginner experience has never been a thing because all the people who are getting into closure has always been like
01:30:10
Speaker
people who have written 20 years of code coming here. And then if I see a stack trace, I know exactly where to look because I've been conditioned like a Pavlov's dog to ignore all the CLJ RT shit now. And that means I can't see the problem. I'm too blind for this thing. I'm too old for this thing.
01:30:27
Speaker
Um, but he's been basically good through the 10 years of Java himself. So it's kind of, yeah, yeah. I had, I had eight years, nine. That's the problem. So, you know, he's kind of like all before his time. Yeah, exactly. I had eight years of Java before I started with closure. I was never puzzled by the fact that they made sense to me. Uh, that's probably large bond, you know, you shouldn't have learned that language. Oh, I learned most fun. Like.
01:30:58
Speaker
Two years ago in 2018, like October of 2018 is when I started. I started a closure well before that.
01:31:06
Speaker
Yeah, yeah. But in any case, I mean, I love the, you know, the ideas that you're bringing in. And then Closure is not this old ass people complaining and grumpy old folks sitting remotely somewhere, writing like, you know. Well, the funny thing is that actually the sort of the grumpy view of things is shouldn't we be handling errors better?
01:31:31
Speaker
It's quite nice to have a young person basically saying to all these old folks, hey, old folks, why are you handling errors better? I know I'm going to get scorched for this, but I remember one of the Closure Core team saying that Closure was optimized for correct programs, and I nearly spat my coffee out. I'm like, what the fuck? That's intolerable. You're absolutely right, Joshua.
01:31:59
Speaker
Yeah, I'm sorry. If we're looking for proofs of correctness, we should be looking at Idris, not Closure. We're writing in Closure because we want to get something done, not because we want to prove it's correct. Exactly. It's done. It's not correct, but it is done.
01:32:14
Speaker
I can't prove that it's correct. It behaves like a good program. Yeah, but I think we're going back to philosophy now because nothing can be provably correct. Well, I think that's kind of the entire point of Idris is that the type system is a prover that proves that you're not accessing things out of bounds, et cetera, et cetera.
01:32:35
Speaker
Well, I mean, you know, that, yeah, okay. That, that proves certain, that proves a certain thing, but it doesn't, it doesn't prove correctness. It doesn't prove that your, yeah, it doesn't prove that your program is a correct implementation of the. Yeah, exactly. Yeah, that's true. Yeah. That's like, things like cock and, you know, uh, I think might be the only way that we can do that.
01:33:03
Speaker
We look forward to the library that you're going to build for that one. GPT-5, prove your requirements are correct to the program. Maybe I can write a library for that, sure.
01:33:18
Speaker
But I agree with Vijay, I think it's really good to have like young people like yourself, you know, the under 30 crew, you're well under 30, you know, to be like, it's not just the next generation, it's the next generation below the next generation.
01:33:35
Speaker
You know doing getting stuck into dynamic programming and closure and also doing all the things that are awkward, you know, like the foreign function interfaces and the the refs and the bars and those kind of stuff, the error handling. No, you're doing the awkward stuff, which is really great. You know, you're not just kind of floating along.
01:33:52
Speaker
I'm taking all the adventures you're actually saying oh, there is some fun parts to this to the edge of these environments which aren't well well explored. Yeah, pretty much every time that I've published something like publicly it's been because I ran into a very jagged edge of whatever whatever system I was working in.
01:34:18
Speaker
Farolaro coffee, disco yard, all of those are examples of, it was a jagged edge at the edge of closure. So I figured maybe I can provide something to smooth it out a bit. So yeah, it's, everyone, no one over 40 years ever heard of discord anyway. So, you know, well, they're trying to fix that now. They're trying to market to everybody. I don't know how well that's working, but not me. It doesn't work for me.
01:34:43
Speaker
We have, we have a, uh, a deaf and disco and actually, but that's what I refuse us to go into it. I do, I do have the app I joined. I mean, there are so many fucking chat apps now. I I'm kind of done with this, uh, this thing anyway. Yep. There's, there's a lot of them. Yeah, totally. Anyway, on that bombshell and, and Hey, Joshua, thanks again for, for, you know, coming on and talking about all these things. And, uh, as Ray mentioned, you know,
01:35:13
Speaker
finding fun in the things that are not that mainstream. It's not yet another web application, yet another web framework or some other thing, but you're doing awesome work. And I love the way that you are thinking about the errors and conditional stuff. I'm going to check them out as well because it gave me some nice fuzzy feeling of Common Lisp again a long time ago.
01:35:40
Speaker
So hey, thanks again. And yeah, I think you should come back again when you're going to solve the core problem and build your next library. Then we should have more discussions soon and maybe about Rust as well. Yeah, it'd be really cool. Thank you.
01:35:56
Speaker
Awesome. All right. Thank you. And, uh, for the listeners, you know, most probably this episode will be, you'll be listening to this in the new year. So we wish you a very happy new year. It seems like we are reliving 2020, uh, which is a good thing. That means we are not aging another year and I could just get stuck in one year and then we're not getting older, which is good.
01:36:18
Speaker
Uh, but anyway, yeah, yeah, exactly. 2021 has been like foggy, but, uh, you know, I hope everyone who is listening to this is happy and healthy and happy holidays. Um, and, uh, we'll, we'll keep doing this fun stuff. That's it from us.
01:36:35
Speaker
Thank you for listening to this episode of DeafN and the awesome vegetarian music on the track is Melon Hamburger by Pizzeri and the show's audio is mixed by Wouter Dullert. I'm pretty sure I butchered his name. Maybe you should insert your own name here, Dullert.
01:36:52
Speaker
Wow, sir. If you'd like to support us, please do check out our Patreon page and you can show your appreciation to all the hard work or the lack of hard work that we're doing. And you can also catch up with either Ray with me for some unexplainable reason you want to interact with us. Then do check us out on Slack, Closure in Slack or Closureverse or on Zulip or just at us at Deafened Podcast on Twitter.
01:37:21
Speaker
Enjoy your day and see you in the next episode.
01:38:00
Speaker
Hello again, dear listeners. This is a small interruption on your way to enjoy other high-quality closure podcasts with a reminder about the Discord experiment that I mentioned before the show started. In case you missed it, we're launching an experiment on Discord to have a call-in style follow-up to the episode.
01:38:18
Speaker
you'll be able to hop into the call as well as text questions and responses. Our guest has kindly agreed to be part of the experiment and we'll add details into the show notes and you can follow mine or Vijay's or the Deafn Podcast Twitter account for more details. Thanks again for listening.