Transcript
Speaker: Welcome to DeafN, episode number 65. Official retirement age for this show really, isn't it? Aren't we increasing the retirement age every year? Yeah, that's right. Yeah. So by the time you reach the retirement age, it's going to be extended for another five years. I think with the financial crisis and all these coronaviruses, we've got to keep on working, you know, keep on grinding out the Patreons. Exactly.
Speaker: Thanks for inviting me. Hey, welcome to the DeafN. So I think we started, so fuck it. Episode number 65, I guess. So it's the same usual people, Ray from Belgium and Vijay from Holland, and our special guest today, Vlad. Yes, my name is Vlad.
Speaker: Hello Vlad. I thought your name was Vlad. Yes, I prefer, I prefer if you pronounce Vlad. Yes, okay. So. The Dutch way. The Dutch way. Uh -huh. What do you call that when you extend? Is it like syllables or not syllables, right? Still one syllable, but. Isn't the vowel. No, that's true, but you know, Vlad. What is the, what is the
Speaker: The linguistic difference between blood and blood. I have to write it down. We're not linguistic experts here. So if you are listening to this podcast and you are the linguistic expert and if you want to win an amazing prize of we saying your name on the podcast, please let us know.
Speaker: Who the fuck is X? Yes. So maybe it's a good idea to introduce yourself. So tell us about your, you know, what are you up to? And where did you come from? And where did you come from? Exactly. I came from Russia. Oh my God. The Russians are coming. The Russians are coming. They're invading everywhere. Is this going to be a disinformation podcast?
Speaker: Is this going to be a disinformation podcast? Maybe. Probably not. Well, if we've got anything to do with it, it will be. So I'm from Russia. Actually, I started to be a designer.
Speaker: But later in the university i realize that i prefer programming. But i still got my degree and i guess i retain some desire for good ui and ux. So my puffin programming started with.
Speaker: Games. I was writing action script at my very first jobs. So it was, it was, I was writing flash games for social networks. Nice. Yeah. Yeah. And now where is the flash? Yeah. But how do you feel about Flash's funeral, official funeral?
Speaker: I guess I moved on already. I don't feel anything anymore. You've gone past it. You're in acceptance now. All the five stages are done now.
Speaker: But early on, I discovered Java, and I was blown away by its power, which I guess may sound silly now, but compared to ActionScript, I could write generics. There was so much possibilities for that. And then I discovered... Because that means you must have joined Java a little bit late then, because they were only in Java 5, so that shows that you're still a youth, you know?
Speaker: So I think we now measure people's age by, you know, uh, do you know diamond, Java diamond operators, you know, is there all the time. Ah, okay. Now we know you're one, you're one not seven, you know. Yeah. I joined, I joined Java and one that seven. Okay. And then I run Scala and I was again blown away by its power. Yeah. And then I discovered closure.
Speaker: And then you're just putting like, you know, you're not blown away. You're just, you know, stably staying because lack of power. No, but then I was truly blown away because. So you blew away from Russia. Yeah. Because I guess, yeah, I just realized that with color,
Speaker: I felt very powerful, but I struggled with actually writing stuff because there was always this desire to make your problem, like the whole problem be checked at the compile time. And it gets harder and harder. And eventually I realized that there is not much benefit to it if I can just
Speaker: For example, I fitted in a repo and have it working. Yeah. But what kind of projects did you do in Java and Scala before coming to closure? Because you said you had a bit of a gaming experience in ActionScript, and obviously Java and JVM is not really known for gaming. Yeah, but I actually did write some games in Java. Yeah, for Android only. OK.
Speaker: Yeah, which is, I guess, a bit strange for a mobile game. But that's what I could do. And I didn't have access to iPhone. I think, I think they're one of the most popular games of all time. It's written in Java, isn't it? Minecraft, right? Yeah. Actually, I currently work at King, which is
Speaker: And as far as I know, Marcos Pearson, the creator of Minecraft, also worked at Kink. And yeah, I heard some stories that he pitched this game to Kink, but it was rejected because they didn't think it will get popular. Yeah, that's like the Beatles, turning down the Beatles, isn't it? That was a pop band in the 60s, by the way, of Ladsauce.
Speaker: Nobody knows your references. Yeah, exactly. I think by this time, we're like, we're just not. We were not boys. We were not. So we are at that situation now. But I think most of the games that King builds are also mobile games now? Yes. And they are not written in Java. They are written in mostly C++. Oh, OK. So what are you doing there with Closure then?
Speaker: Well, actually, I don't write closure on my day job, unfortunately. Yeah. Yeah. Then what brought you into closure from Java to Scala to closure? Well, yes. The power to do what I intend to do. I guess I feel the most
Speaker: So it's like expression, expressivity. Yeah, yeah, I feel the most enabled writing closure. Yeah. Yeah, I think it's like you said with Scala or some other languages, you can feel like you've got a big sword, but you don't exactly know how to wield it. Closure is you know, you can definitely it's a pocket knife. Yeah, it's a pocket knife or a dagger or a scabbard. I don't know.
Speaker: What the fuck is this cup with? You must have really long pockets, man.
Speaker: Nice. Yeah, so I started in -game dev, but then I thought that maybe more enterprise Java pays better, so I tried also that. And I wrote some Java for Russian government a little bit.
Speaker: Nothing about meddling with elections, just... Well, I mean, why would you say that anyway? Maybe I'm obliged to say that. Yeah. Did you use any frameworks or something in Enterprise Java then? Spring, yes, Spring Boot. I have never understood it. I just...
Speaker: Just used it. I just slipped some annotations on classes and enrolled with it. Yeah. And then I discovered closure and was...
Speaker: pretty happy with it. And I, yeah, I worked writing closure for a Russian logistics startup. And then I moved to Sweden to write closure there at Kink. So I did write closure at Kink at the default editor. It's a default is a game engine for
Speaker: Well, for developing games. An editor for that is written in Clojure. So I joined the team. It was very fun. But then Kink decided to... Default on default. Yes. So now I'm writing Java. Okay. But is the default thing, was it JVM Clojure or was it something like Arcadia?
Speaker: Like the Mono. No, the thing is the engine itself is written in C and C++. And the scripting language for this game engine is Lua.
Speaker: But closure is used in the editor for that. So you have like a desktop application, which is written in closure that allows you to iterate on this editor, iterate on the game using this editor. So what is it? What is it? What do they use now for that? Sorry. Is it still closure that you use or did you just switch jobs or did you, um,
Speaker: Did they decide to write it again in Lua or something else? Sorry, I don't understand your question. The editor, you said you stopped working on it.
Speaker: Yes, because Kim decided to shut down the default. Oh, they just completely shut it down. They open sourced it and there are two guys working on it and I hope they will make it fly. I'll be able to get back to them, but currently they just don't have enough funds to also have more people at the dev team.
Speaker: But I think using Closure for desktop applications is an interesting choice, right? Because that's usually not that common in the Closure community, I would say. Maybe using Electron. So how did you build this one? This could lead into your open source projects now. Yeah, so we are still leading to CLJ fix. Yes, yes. Spoiler alert.
Speaker: Yeah, so before joining King and default team, I was in a small startup that they used Closure on the backend and Closure Script on the frontend.
Speaker: And I was using reframe and regent and was pretty happy about how this whole stack works because from my previous experience using in -game dev where everything is super mutable, usually it was very painful to do any UI. So I was kind of curious like, how is it going to be a default? Do they have something like that?
Speaker: And unfortunately, they didn't. So they made the core of the editor, which is all about incrementally building your project and hot swapping parts of it when you are developing it to provide some repl -like experience for a game dev. So they had this very
Speaker: functional core, but the UI for that was still this imperative mess. So that's when I decided that there needs to be something like a React for Java fix. And I just did it. So that's the CLJFX then. Yes.
Speaker: Okay. And you built the default editor in CLJFX or is it just a plain swing application or Java fix? It's Java fix application. I mean, they already had it when I joined them.
Speaker: for like quite a long time. It was, it's like a quite a big application. So we started replacing like smaller parts of it with CLJ fix, like where it's made sense, but we didn't have time to, to rewrite it, to use CLJ fix like as a whole. Yeah. So what about Java effects then? I mean, I'm kind of like, uh,
Speaker: I don't know, it seems like a, maybe it looked like an abandoned project a few years ago, but then I think there are enough people just about keeping it alive in Oracle. So, or am I wrong now? Cause I lost, I lost touch with it, you know, maybe it's five years ago.
Speaker: What's the current state of JavaFX itself? Well, if you judge it by Twitter accounts of people who maintain it, it's very rocking. Right. Is it still maintained by Oracle or is there something on OpenFX or something? Yeah, I mean. Because I remember there was some open dolphin at some point and then
Speaker: some shit happened around it. So JavaFX was a part of the GTK distribution in Java 1 .8 and then they decided
Speaker: they want to split the part and make that just a separate dependency that you can install. So they moved it out. But as far as I know, there are still team at Oracle that develops it. But now they're on GitHub. Nice.
Speaker: So what kind of changes have occurred in JavaFX in the last few years, then, that you've noticed? I mean, I guess the question is, you're using it. You're just using it because you're using it? Or are you using it because you think, actually, it's a pretty good platform now?
Speaker: I would say actually and this is maybe a little bit of a spoiler before we start talking about review, but I had some thoughts about like had some vision of review even before I started writing CLJ fix.
Speaker: I just felt that if I want this kind of visual tool to be extendable by people, they wouldn't want to write in this imperative mess, which is Java fix. They would prefer to use something declarative and just like vision data structures and be done with it. I think
Speaker: Java fix is a fine framework, but it's like, you know, I would split it, like my perception of it in two parts. First, there is like a lower level UI element, like labels and some layout, like grids and horizontal and vertical boxes. And
Speaker: Those are great. But then there are controls and tables and charts and they are very fragile and they really go against you if you want to behave them differently or look differently. So there are good and bad parts.
Speaker: That would be my opinion of JavaFX. So the integration with Closure, then, is it because JavaFX has, I'm assuming, does it have its own programming model? Like Swing, you know, because I did some Java desktop development a long time ago.
Speaker: And there was still AWT, and then we moved to swing, and then a bit of an Eclipse RCP related things. So does JavaFX bring in its own programming model that you need to translate into Clojure? How did it work?
Speaker: Well, you just create multiple objects and call setters on them. Okay. And in addition to that, there are like some sort of observable pattern that is used everywhere in Java fix where you can like
Speaker: bind every mutable place to another. And, uh, well, in still your fix, I just don't use it at all. I just translate the data structures to calls to setters. So in terms of like, like, let's say reactive react, like the idea of react is that the, you know, you have a function to transform the view.
Speaker: Um, but it's got a sort of, you know, a virtual dorm and all this kind of stuff. So, um, how does that, how does that play out with Java effects? Is it just, are you really just doing a straight pass through or are you doing some buffering or some optimizations or are you doing some other things that are like working on the rent, making the rendering more efficient or am I just talking out of my hat now?
Speaker: I'm doing pretty similar thing to what React does. So it has diffing. So it's like you don't recreate the whole display graph on every change. But that's it. So JavaFX isn't meanable to that. It's actually got a kind of view. You can grab the whole view and do a diff on it.
Speaker: That's something that I'm quite impressed by, actually. I didn't realize that JavaFX had that kind of... But, I mean, I don't read from JavaFX. I just, I mean, all the different that I do is a different in front of closer data structures.
Speaker: Ah, okay, okay, I see, I see, it makes sense. So I see, like, I compare new one with the previous one, and if there are changes, I just call setters. Right. So I completely, completely ignore the state of Java fix objects. And it seems to work out fine. Yeah, good.
Speaker: But how is the threading model in JavaFX? Is it something similar to swing? Because it's not thread safe. It's not thread safe. Yes. And there is a UI thread. But there are, like, in CLGFX, there is a,
Speaker: I an entry point for that which does which is a frets safe and you can just i don't know the dose it with data. It's it's it's dossing it is a single distributed it's just just do not love services.
Speaker: Yeah, and it will do all the duplication for you and will queue like the minimum amount of refreshes on UI threads. So even though there is like a phrasing model, when you're using CLG fix, you don't have to care about it at all. Well, I guess, except when you are doing event handlers, because they happen on the UI thread, so you shouldn't really
Speaker: do blocking IO in your event handlers. But yeah, that's all. OK. And how does this compare to things like, for example, Electron? Because these days, I think all the desktop applications, they're basically built with this Electron framework, the web UI stuff, bringing them to the moon. We're talking in Discord and all this shit. I think Visual Studio Code and every fancy thing is now built in.
Speaker: I don't know, 20 gigabytes of RAM requiring browser window running in a native application. Yeah. I mean, Closure and JVM is also pretty intense on resources. That's true. So it's probably not as much as the electronic applications, but... Yeah, I guess. I don't know. I mean, I'm using VS Code. It seems to run very smoothly. Yeah.
Speaker: But yeah, not every Electron application is like that, I would assume. Yeah. So if I were to compare Java fix to Electron, I would say that Electron is a solid choice. But I mean, as a language runtime, GVM, I think is better than JavaScript VMs. And this is also true even when you're in closure, because
Speaker: They have different compilation models and in Closure you can define markers in the same compilation stage, like in the same namespace. In Closure Script you have to be very careful about that. So I would say a development experience is better when you are using the GVM and if you want to be in the GVM.
Speaker: Then, then I think JavaFX is a good choice because Electron is a different process probably, so you will have to, there will just, there will be just more moving parts that you will have to be careful about.
Speaker: Yeah. And also, I think if you want to use all the libraries, I think JVM has better access to those libraries, I'm guessing. I don't know. I mean, maybe now JavaScript ecosystem is way better now with node and shit and whatnot. I think the difference is that it's like, I mean, it's the UI part. The funny thing is, I would have thought that, again, like the JavaFX is a bit starved of frameworks or render, you know, sort of things to make it look pretty to things to kind of like
Speaker: to make the UI experience more modern, I guess, all the typefaces and all this kind of stuff. But I don't know. Maybe, like I said, I've lost a bit of touch with JavaFX. Does it have web fonts and all these kind of things? How kind of like startable is it compared to the browser, which has got tons and tons and tons of options?
Speaker: resizable and scalable, all these kind of things that have been happening in the modern browser apps in the last sort of 10 years. I just was about to mention that if you want some kind of type setting, then I think Electron and browsers are obvious choice because they evolved from that model that
Speaker: the web pages are documents of text so you can like just use ctrl f to find any text on the page this isn't possible in java fix you have to implement it yourself if you if you need that and like effortless effortless zoom in or zoom out so in that sense web is better so i think the
Speaker: I'm not sure. I think maybe it's a Java effects is more intended to replace swing, right? I mean, like the building desktop applications, which are not, I mean, you can't zoom in and zoom out into any native applications anyway, regardless of your system. So I think it's the similar kind of, um,
Speaker: It's another stab at, OK, let's use Java. That's going to deploy everywhere, sort of. That never worked. And they always looked ugly. And that's a funny thing, because the only application that, even at that time, that didn't look like Java application was IntelliJ. I think JetBrains folks were doing a lot of stuff to not to make it look like Java application. And every other thing, by just looking at it, people can say, oh, this is Java application.
Speaker: It's like this one stinks, so I know there's a shit, you know? Well, the reason you could say it was a Java application was it took about three minutes to start. Yeah. And also the stupid logo. And then there is this abomination of Java web start or something. And that's another shit. Anyway, good old times. But Java fix uses CSS for installing.
Speaker: Oh, OK. So you can configure it pretty far to click something else. So you can configure it to just enough to say this is not a Java application. But I think these days, the difference is not going to be that difficult, especially given that all these electronic applications, they don't behave like native applications.
Speaker: So the proliferation of electron -driven shit. There's so many apps built in this one. And none of them behave in a reasonable way, you expect on a platform. So I guess it's OK now, I think. The bar is low. Yeah, exactly. The way I look at it, it's like a lot of these Java effects applications. I mean, it's interesting you say that, Vladio. I've got a design background, because a lot of people
Speaker: use JavaFX because they're Java programmers and they want to do something in the UI. And actually, the UIs are always shit. I mean, really terrible, you know. I think the nice thing about Bootstrap and stuff like that in the browser was you could be a developer and, you know, just use someone else's CSS and it would kind of look half decent, you know, even if, I mean, obviously Bootstrap is kind of like aging a little bit now and everyone's a bit pissed off with it.
Speaker: It looks a lot better than most people CSS did. Handcrafted web pages and stuff, you know. And I think JavaFX applications, you know, I'm looking at a few that I've seen in the recent years mentioning no names. Rebel! But ugly pieces of code. Rebel just uses the default JavaFX styling. Exactly. Yeah, I guess they need a better CSS. Yeah.
Speaker: They should use bootstrap CSS. I mean, come on. It would have used to be just better. Exactly. One little line, you know. Anyway, yeah. No, but definitely, you know, we're coming on to reveal, I guess, now. The big reveal. Yeah. This is the big reveal. It's time to reveal it. So what is reveal? Revealed reveal. Reveal is a read -of -all visualized loop.
Speaker: Oh, yeah. I like that. Yeah. I was pretty happy when I came up with it. I mean, as they say, that is the most difficult problem to solve. And then if you solve that one, like naming the thing properly, then yeah, then you're really much done. I like that. I like that you went with reveal or rather than revel. I mean, you could have went with that. Like, you know, revel is a sort of like repl and revel in something is very, you know, you're kind of happy and
Speaker: So, but reveal is more, yeah, because of the visual aspect. So I liked that. Yes, exactly. Actually, I still have like a private repo on GitHub, which is called it's called rebel. Yes. That has early experiments. At some point, I realized that it shouldn't be called rebel. It should be called. Yeah, it's, I think you made a good choice then. Yeah. So, so what is the, what is the idea behind it? So.
Speaker: Well, there are many ideas behind it. But I guess the main, like, I think the main vision I had for that is to be able to hold a value in your hand, which is, I guess, impossible thing to do. But I guess I'm trying to get closer to that.
Speaker: And as a step which brings you closer to holding a value in your hand, is being able to select it and do immediately something with it.
Speaker: So this is, I think, one of the bigger things about review. Can you explain it like I'm five?
Speaker: No. Okay, three then. Okay. Hello, Vijay. Are you saying comfortably? Put the crowns down. No, no, stop, Vijay. Stop, stop, stop. It's going to be like the Sesame Street sort of thing. My daughter is three -year -old. I can't explain anything here.
Speaker: So what does it mean actually to hold a value in your hand? Well, to me, holding a value in a hand means being able to quite easily see it from different angles just by rotating your arm.
Speaker: And if we translate this metaphor to a desktop application model, then what Reveal provides is a way to select any text that it outputs when you print the data structure. You see the text, and you can select parts of the text.
Speaker: For example, you can select some value inside the map. And you can immediately evaluate some code in it. So you just bring up a context menu and can write any form that will do something with it. And there are many built -in contextual actions for different types of objects
Speaker: to make ability to look at the value from different angles, like closer at hand, which means easier. So how do you compare this to Rebel, for example?
Speaker: It's better. Okay, you said it, not me. It has better CSS, I'm assuming. Yeah, at least it has better CSS. I remember when I was doing early prototypes of Free Wheel and then Rebel was released,
Speaker: I was very worried like, oh, shit, now I have to compete with CodeNetect. I'm doomed. But I think the ideas behind them are very different. So I guess to each their own. What was I talking about?
Speaker: So the difference between comparisons, what you perceive the different visions to be. Yeah. Well, I think one of the bigger differences is that I don't use data file.
Speaker: which is a newer protocol which was later added into closure pretty recently. Because I think when I develop something, I am working with objects in the VM. And DataFi transforms these objects into something else.
Speaker: I mean, it transforms them to data, which is, I mean, usually it's very good because, I mean, if you are,
Speaker: Well, it's usually immutable and you can inspect it. But the problem is that you had an object and now you have something else. So your ability to view what's in your process is reduced because of that.
Speaker: Because you were thinking you have an exception, like objects, but all you see is that the fight throwable. And I think this is the thing that angers me most is that it transforms atoms to single element vectors for inspection.
Speaker: But I mean, it still puts the original atom into metadata of that vector. But I think it's very confusing when you try to work with the atoms, but you just can't see them. So Reveal uses different approach that it doesn't try to hide what you have, and instead it allows you to
Speaker: See what you have from different angles and that if I and now is just one of those angles, so I. Even though I don't use them by default, I still have contextual actions for them if they make sense.
Speaker: So it reveals something like you're going to use it in addition to the REPL, or can it be just like a REPL that I open? So how do I use that thing then?
Speaker: I use it as a REPL. So I use cursive. And in cursive, there is a default REPL output panel. And I just don't use that one. I just close that when I start reveal, and I use a reveal window to see the output. So it's just like a window that is
Speaker: like on the side of the screen, which contains the output. So it can plug into, so essentially you start reveal and then you connect to that reveal session from your code.
Speaker: Is it just a normal REPL or something that you can connect to? It's a normal REPL or I mean it's many things.
Speaker: You're revealing one by one now. It's one, it's normal REPL. It's a REPL itself that you can see from many angles, I guess. How do you hold a REPL in your hand? The simplest thing that is revealed is it's a function that has a OS window. And when you call this function with some value, it shows it in that window.
Speaker: Okay. So you can just create this reveal windows at wheel and use them to submit values to them. And there are a bunch of repos and they are just built on top of that like lower level primitive
Speaker: They're just lightweight wrappers of other repls that just submit values to that function. And it also has nreple middleware because nreple is popular. So it has many entry points. You can use it as a REPL or
Speaker: in as a part of an apple or just as a window if you want to submit only like very occasionally while it's a bit so so the editor integration is just via apple then so it doesn't matter which editor you're using so you can just connect to yes your code from that one
Speaker: Yes, I think it's a great thing. It's a process and that means it's available to every closure ID that can send forms to Apple. I mean, the only closure ID that matters is Emacs anyway. As long as it works in Emacs, then it's fine. I think that's one or two people who are using other shit. I still have PTSD from Space Max.
Speaker: I know. This session is going to resolve them. Don't worry. We are here. From your designer point of view, I'm pretty sure it might be completely different experience, right? Looking at all these different editors. Yeah, but it doesn't matter because reveal is available. So just to escape badly designed editors, you had to build your own.
Speaker: I think actually it also might be a good thing for ecosystem because it might lift the burden from the IDE offers to create exploration and inspection tools because currently
Speaker: Basically, every ID has their own, and they are not transferable. It's like you have your debug panel in IntelliJ, and that's it. It's only there. And then you have, you know, ciders inspect you, and again, it's only there. Yeah. But I'm guessing that you don't really integrate to the debugger, do you? Or is that, do you do that? No.
Speaker: I don't use debugger and I haven't felt the need to use debugger enclosure. I think one honorable mention here would be top. So I used to use print lines for debugging and now I don't use it anymore because top is much more powerful.
Speaker: So, yeah, it's also a recent addition, the closure. Yeah, yeah.
Speaker: reveal, reveal to me, haha, what the actual point of tap was, you know, you know, it was fucking ridiculous, really, you know, that the people who made tap couldn't explain it. But but actually reveal shows that once you tap a value out to something like reveal, then it's just a data rather than a string. So therefore, whoa, you know, if you can hold a bit of data in a in reveal in your hand, then
Speaker: Suddenly, the print line is a waste of fucking time. That is brilliant. Forget pretty print, forget print. All print subsystems are dead now.
Speaker: Tap is the king, you know? Yes. You just need to tap into reveal. Another pun. Oh, yeah. But it's really awesome. I mean, I'm really, it's super fabulous now that the tap is suddenly like, you know, useful. Yeah, it's suddenly useful. Have you ever used it, PJ? No.
Speaker: No. Yeah. Why would you? You're thinking, what the fuck is this thing? It just disappears into the ether. Exactly. It's just like data file. And then, OK, we heard about that one, and then moving on. And then, oh, we heard about it, and then it's moving on. And especially if it is behind the closed source thing, and I'm like, yeah. But I think I got to try a reveal, and then probably it will. Then I can tap into the awesomeness.
Speaker: Yeah. So reveal can also be used for both closure and closure script, or I'm still trying to wrap my head around it. So how does it work? So can I just open CLJS REPL into reveal?
Speaker: It's complicated. Yes, it's doable. So when I was thinking about reveal and designing it, I felt that there is not much need for this kind of tool in the closure script, because when you are doing closure script, it's usually in browser and you already have pretty powerful tools there. So you have like a.
Speaker: a page inspector and browsers console output, it's actually sort of a reveal because when you console lock something, you don't lock strings, you'll update there. So you also can inspect from there.
Speaker: So yeah, I mainly felt that such a tool is needed in the GVM land. So that's why a review is primarily about the GVM. But since, I mean,
Speaker: since reveal is just a window and you can wrap different apples. Reveal in its default package provides a way to talk to remote peer apples.
Speaker: Uh, and that makes it usable or that makes it composable with the color script, for example. So you can have a color script purple and you can connect review date and you can evaluate forms and see your results in the review.
Speaker: But I mean, there is a slight difference still, is that when you show the values in the real output window, they are the values that you received from the network. So they are not the objects in the target process. So the exploration ability in that sense is limited.
Speaker: But I think it's still pretty nice. And reveal has various table and chart views that you don't have to do anything to use. You can just
Speaker: Just by having data in the proper shape, your wheel can show it as a chart or as a table. And you still have this when you're talking to Closure Scriptable, for example. Yeah. I think one of the things, because I work on a reasonably large Closure Script, Closure Application.
Speaker: And the front end is completely reframed and that kind of stuff. And then it uses the pneumatic tubes to send the events back and forth on WebSockets. I think over the period, I get really pissed with these two repls and all this stuff. And still, the development experience is still kind of hacky. It feels a bit fragile.
Speaker: So obviously, I'm not a guy who can come up with new ideas. So I'm just hoping someone is going to think about this shit and then build a better tooling around this crap. When I was writing only Closure Core, it was pretty easy because I just use Emacs, and then I have Cider, and then it's happy La La Land. And then suddenly, this Closure Script shit comes in. And then there is fig wheel, fig wheel main, shadow CLJS, and all this. And we keep adding all these things. And then suddenly, there are two different places that I need to inspect the stuff in.
Speaker: And especially because they both are talking web sockets. So there is no unified way to resolve this, I think. Well, there are two execution platforms. So what are you going to do? Yeah, but that's what I'm saying. But the whole idea of Clojure is that to have like, OK, it's going to be the same language, and we have CLJC, and then it's the same kind of things available. That's not the idea of Clojure, in fact.
Speaker: Yeah. Well, the whole point is that you use the same kind of structures everywhere. If I have like fucking... No, it's a host of language feature. Remember that? Yeah, then that means there is going to be only JVM somewhere, and then we just use shit there. Now, we don't need to jump between these apples. It gets so fucking annoying and frustrating these days. You're like, oh, fuck it. You know what? I'm just going to write Java effects, and I'm just going to... I think you've got your answer. Exactly.
Speaker: eventually give up and then just use Java effects. Everything is on JVM, so screw this. Yeah, just a single process. How simpler can it get? Yeah, but it is something that if I had to explain this to someone who is already new to Clojure and then I'm introducing them to this project, it's
Speaker: It is slowly getting to a point like, wow, this shit is pretty difficult to configure and then get your everything up and running.
Speaker: So yeah, yeah, I will say this is one of the reasons why I love soccer triples. Over and ripple. I mean, I don't have anything against and ripple. But yeah, soccer triples are just so simple. I mean, it's just just dreams in out. And what do you think of the the P ripple and Vlad because that the P ripple to me is even more awesome, because you're getting data out.
Speaker: Yeah, it's pretty awesome. You've got soccer ripples, then you've got data on top of soccer ripples. Nice. Yes, I think ripples are useful only when you're doing inter -process communication, because then you have data over wire, and this is something easy to deal with.
Speaker: But if you have a REPL in the process, then you just don't need it. I mean, just have your regular REPL. So yes, I think it's great for networking. I think, talking about the developer experience, remember there used to be this thing called Meteor Framework.
Speaker: with the MongoDB as the back end and everything. I think that they tried to solve that in a pretty decent way. I mean, starting a media application and then it's a full front end and the back end and everything. So it was much better, I think, at some point. But I don't think Herwheel can do anything about it. Hello. Yes. Hello.
Speaker: No, I think the thing about Meteor, again, it's an island mentality, isn't it?
Speaker: So, you know, if you think that meteor is the future and everyone's going to come to meteor, then great. You know, but in fact, I think meteor just like flamed out, you know, just like a meteor would. So I think that was it was kind of in the name, you know, I was like, I was always going to flam out. So a nice idea, but it was never going to never going to win because the other islands are just too big. You know, yeah.
Speaker: The server side and the front end are just dominated by other tech. So Reveal is built in CLJFX? Yes. And you can extend it like it has a pluggable extension point.
Speaker: uh where you can define your own uh like contextual actions on objects like contextual inspections and you can also use such a fix there uh so if you have your
Speaker: problem domain that is visual, you can easily build a UI for that in Reveal. So what are the future plans for Reveal then? Revealing the future plans. So is it in a production state right now? Like, you know, people can just download it and then use it, like going to vlog .github .io slash reveal. Yes, I think it's in 1 .0 for a couple of months already.
Speaker: Nice, I actually have been using it. I guess more for more than a year. Like as soon as I would stop this. So it was usable as a repo. I just use that. Yeah. But about future plans there are some. One of them is I want to investigate JavaScript and web support.
Speaker: Because job fix can show built in browsers you can build in the browser as a view but there's still a big problem with that is when you.
Speaker: go from Java to JavaScript, it is possible that you no longer have access to your Java objects. I mean, this is the part that I haven't investigated yet, but I plan to do it. And for enable continuous exploration of objects and inspection of them, one of the problems to solve is that I want to see
Speaker: I want to get a hold on the reference to Java objects from inside that JavaScript subsystem for reveal or how can I name it? This is to be done.
Speaker: Another big thing is, I would say, being able to control reveal from the REPL. Actually, I got these kinds of requests from Emacs users who, for some reason, just don't want to leave their operating system.
Speaker: So they just want to control. I know how it feels, yes. But I think it makes sense to do such a thing. I think it can be very useful. So I'll think how to make it controllable from the ripple or from somewhere. It would be nice because when you set a new window, I mean, usually, Emacs is full screen. So I'm not going to use any other windows here.
Speaker: Yeah. Well, you've only got one screen now. Come on, that's not good enough. Well, I have three now, but everything is just mirrority max, you know.
Speaker: One thing I want to ask you actually, in terms of usability, if I can get some user advice from you, the thing that I find a little bit with Reveal is that I use it on Linux with cursive, like civilized person.
Speaker: the, just, that's the only reason I do it. So when I open reveal, and I sort of do things, all the views are kind of lined up at the top. But it kind of like runs out of screen pretty quickly. I'm navigating, it seems to be a bit tricky for me. Am I missing some trick here with don't use the options are in terms of the UI? Yeah, I'm an idiot. Yeah, I should read the manual. Maybe it's but
Speaker: No, yeah, it's OK. Not a bug close. Use the error. Fuck off. Exactly. You know, the B, B, C, S, K, S, you think, like back in the day, there used to be like, problem makes us between keyboard and the chair. Oh, God. Yeah, absolutely. That's the problem there. It totally is. No, no, so just to... I'll have another crack at it, OK?
Speaker: Sorry, I couldn't understand the problem from your description.
Speaker: So let's say you right click on some map or some data. Yeah. And it comes with a list like Java Bean or nav or table or pie chart or whatever. So you click on something at view table and it gives you the table and it's all very nice. Then you click on other views and that view is also, it's all part of like a line across the middle of a reveal.
Speaker: So you have this long line of things and you can, you can go, you can kind of go left, but I can't find a way to scroll it. I can't find a way to like, other than to sort of click on the left. It's difficult to scroll through. Maybe I'm missing something. Yeah. So yeah, two points. First is that there is a bug with scoring. Oh, okay. But fuck you. No, duplicate close.
Speaker: It's either one fix or it's a duplicate. We know that it's okay. Fuck off. Do you know that you can use control left and control right to switch between the views in the results panel? Oh, I didn't know that. There we go. Yeah, it does work.
Speaker: So if you have multiple tabs there. Oh yeah, I forgot to mention this is like a part of a more closer.
Speaker: plans of reveal is that I'm reworking the navigation. One part of that is that I'm making structural navigation and I will also experiment with how auto scrolling works. What does that mean to me? I don't understand. From your description.
Speaker: You're going to be a repeat, Gasploit.
Speaker: Sorry, I wasn't sure if I should say that. Please don't apologize. We invite people to tell, you know, basically that thing to Ray. Oh, come on, DJ. You've missed out for too long. Go on, Vlad.
Speaker: Yeah. Applying to improve the navigation a little bit. So it's like currently if you evaluate some value and it's like really, really big, usually you just, the screen just keeps scrolling down, down, down and you don't really, I think like when you evaluate something, you expect to see like the beginning of the value, not the end.
Speaker: So this is one of the things I'm planning to experiment with. And another is a structural navigation, which is currently absent, but I'm working on it. And it's going to be great. It's going to be better than any other structural navigation that exists in the market. Maybe this question should have been asked in the beginning. So what is the inspiration for review?
Speaker: So is there any prior art or something that you saw or some idea that you got in sleep, like DNA helix thingy? It was a long time ago. I think it was summer 2018 when I started to think about review. And this is all I remember. It does be a long time ago, man. I think it maybe started with dev cards.
Speaker: So I was looking at them and I had the idea of like having some similar thing for the GVM. But initially the idea was to have like, like, uh, like a dev car, sort of a pop -ups, like, you know, post notes on the window that just,
Speaker: Appear when you request them and disappear when you request them to disappear. Yeah, but since then it's evolved to something else. Okay. So maybe dev cards. So right now, so it's 1 .0 and then you're working on a couple of fancy new features and structural navigation you said, right?
Speaker: Yeah, this is what's currently on my plate. Yeah, yeah. So is there something that, because it's open source, right? It's on GitHub, so we can contribute. So is there something that, are you looking for contributions? Or are you saying, OK, fuck off. Open a Jira ticket, and then fuck you. A Jira ticket. Oh, my god. We fix it when we fix it, you know? Do you have a Jira of land, do you?
Speaker: Not yet, but why not? It's free now. Well, I mean, if there is something obvious to improve in code that I'm, of course, I'm open for contributions, but I'm not currently seeking for contributions. And I mean, I think the best
Speaker: think you can do for a view is use it and tell me about your experience with it. And I don't know, whenever I've done that, I've always found that you've told the fuck off. So I guess it depends on who opens it.
Speaker: But it's coming from deafened people in a direct -to -deaf null. Fuck it. I mean, I guess in that sense, it's a proper closure experience, really. It's not about me. But there is a Slack channel in Closurians. I don't tell people to fuck off there, so you can ride there.
Speaker: No, I mean, it's very good actually. You're very, very, what I should say, very affable and charming host. Thank you. And I think, you know, there is, as you probably with your design experience noticed that, you know, the whole
Speaker: Um, in general, the developer experience is less concerned about the user experience, I think most of the time. And, um, it's, I did some flash development a long time ago, uh, when it was still macro media thing. And, you know, writing code in different IDs and all that stuff. And it never goes to a point where you, you really like the tool and enjoy the experience. Okay. This is, this is very well thought out from, from, uh, user experience point of view.
Speaker: Well, I mean, apart from Emacs, you know, Oh, it's great. We're having a great time tonight. I think closure is about user experience. I mean, repl is a great user experience compared to compiled languages. Like being able to see the results of your code, the code immediately. I think that's a great user experience. Yeah.
Speaker: Yeah, I don't know. I think the problems I work in them are sort of open, so it's not like there's any obvious thing to do. For example, I was reworking a talk by Brett Victor, which is called invention on principle, which is a very interesting talk. Yeah, true.
Speaker: Yeah, I don't know if Closure was inspired by that or not. I think the Brett Richter talk came later, I think. Yeah, yeah. Or at least the Closure script and the fig wheel thing probably inspired by Brett Richter thing as well. Yeah. I think it's a live editing sort of thing, or live changes.
Speaker: Yeah, but it's like, I feel that there is a unsolved problem that I currently can't quite formulate, but I can try a little bit. And the thing is like, the tools he talks about, for example, are for problem domains that are very visual. And
Speaker: For visual problem domains, I mean, using some kind of reactive UI, it's sort of easy to build interactive tools. But I think the general programming is not that visual. We are dealing with highly interconnected graphs of
Speaker: I don't know what. Yeah, systems of components, yeah. Yeah, or symbols that have different connections and trying to display them as a box that's connected with lines. I mean, it's just a complete mess. So I think there are yet now not many good, maybe, visual metaphors for
Speaker: the kind of stuff we are usually dealing with like on the daily basis and well I guess apart the visual problems that we have. So this is another thing I'm thinking on is that how do you make visible what is such an abstract thing
Speaker: Yeah, it's like, yeah, I mean, contributions for that kind of stuff are very welcome. I think one of the things that I'm kind of interested in is these, there's a lot of this stuff around like, like you say about like graphs and nodes and edges and stuff like that. And it's a lot of still, you know, to me, that's a very interesting, like space because
Speaker: On the one hand, it's kind of like it's very quick to get like an unwieldy graph because, you know, if you visualize a graph that's got all these interconnected edges, then it suddenly just becomes a kind of like, you know, just a mess. It just becomes like a spider's web or, you know, it just becomes like a tall labyrinth. But, you know, if you can say, OK, well, something along the lines of
Speaker: if a particular predicate is true, highlight this truth through the graph, through all the vertices, through all the edges. That seems to me quite promising, but I haven't seen much around that really in a lot of these kind of graph visualization things.
Speaker: don't seem to be that, um, programmable. Yeah. Or maybe they're just, they're maybe just like the visual metaphor wasn't invented yet. Yeah. Oh, it's a lightest. They're not programmable. I mean, they are programmable in the sense that you can, you can program them, but I know
Speaker: in terms of live interactivity. Isn't this because it's too general, right? I mean, the problem domain is too general. And also, I'm assuming everybody, when they're reading the code, they will build this model in their mind. When they're working on a project, I'm pretty sure they have some idea of, in the case of closure, how the namespace are connected, how the functions are getting called by each other. Yeah, yeah. All this stuff. But yeah.
Speaker: Yeah, that's what was bothering me from my very first days in my career is that there is a code and there is a mental model. Yeah. And they're different. And I build this mental model from code like over the very long period of time. And it would be nice if I was able to see like to make this process of learning, of building this model more easy.
Speaker: Yeah, yeah. Attractable. That's the Brett Victor thing though, isn't it? That's the Brett Victor thing is that you should be able to sort of visualize from the text to some visual thing and then from the visual thing back to the text. But I think it's a very elusive kind of dream in some ways. He made some interesting examples, but it does elude us in the general sense.
Speaker: Yeah, I feel that all his examples are sort of about visual domains, so it's possible to
Speaker: I mean, one example he gave that was not visual, but was the, I think he was doing a sort, a quick sort. Yes. Yes. Yeah, I remember this example. So there's like an algorithm that you implement in a text editor on the left and on the right, there is a sort of a ripple output.
Speaker: Yes, exactly. Yeah. Yeah. But isn't this something like, you know, code visualization is something kind of sort of, you know, UML shit was trying to solve? But they solved it. No, they didn't. But that's what I'm saying. Because one of the, for what it's worth, I mean, when if you have large
Speaker: Java code base, I mean, I can quickly whip up and then say, okay, show me the class diagrams for all this shit then. Then of course, you know, it will, it will point to all the links are everywhere. And then you could at least, at least mix, you know, generate that kind of stuff, but slowly, but these kinds of tooling was, was very popular in the nineties, I guess. And then, and then later,
Speaker: none of the other programming languages, nobody seems to focus on this side of the programming. Like how do I visualize this one? This is a big challenge when you want to explore the code, right? I mean, I just want to open some large code base and I don't know where to start from. And then I have to have a lot of implicit knowledge about which modules are connected to what, where should I start and these kinds of things.
Speaker: Yeah, I just think that the metaphor of boxes connected with lines is wrong. It's like, it's very wasteful on space. It's like, you know, there's a loon along, which is a visual programming language. Yes.
Speaker: And I just saw some demos of it where, for example, they build the charts from to stock market tickers, like Bitcoin and Ethereum. And they have the whole screen to connect three nodes, like Bitcoin, Ethereum, and then something new that they connect to.
Speaker: And I mean, you can represent the same thing in text in like, you know, for words or free words, and some parents. Yeah, I mean,
Speaker: the text is already a very visual and dense environment. So I think text wins over boxes connected with lines. Yeah. But I think you make a good point, which is essentially the complexity budget or the complexity capabilities of visual programming is very limited.
Speaker: I think that's essentially the big issue. Maybe that helps in writing simpler programs, you know? If you're bringing the constraints in, then...
Speaker: By the time you introduce the complexity, it will be fucking in your face and like, oh, fuck, OK, this is now getting complex now. Because we hide away the complexity in text and then modules and then move that away. I mean, obviously, the rest of the 200 classes, I don't care about them. I'm only going to put an annotation in this tiny place and move on. So this shit will be much more visible if it is visual.
Speaker: That's the interesting part. But I think this kind of ideas keep coming to all these text -based user interface. I mean, there is this new wave of terminals that are much more richer rather than just plain dumb bash, just piping shit into text in this way and that way. And then that is another place where people are trying with
Speaker: web tech or make everything clickable and that kind of stuff. But doesn't it boil down essentially to Vlad's point earlier, which is essentially, and it's closure's point in general, I think, which is, or it seems to be the evolution of closure. That's the way it's going.
Speaker: more and more and more and more things as data. And then once you've got things as data, then they're innately more explorable and more kind of open than text or kind of classes or things like that. Because they're just more obvious and more, yeah, more explorable, more. Yeah. So until we solve this problem, it has got revealed. Yeah.
Speaker: Well, this is the nice thing about reveal to me is that suddenly as as closure itself is becoming more data oriented and things like tap, which I didn't get before, but now I do, thank God, you know, and as a lot of the frameworks are moving towards data as well, you know, feeding data as kind of like.
Speaker: input to how systems work, you know, use maps and configurations and this kind of stuff, then your ability to visualize those things, it's going to be more powerful with things like reveal. Yeah. Yeah.
Speaker: Yeah, and I can say that, well, Unreal already has some interesting things that I experiment with from time to time. It's like, for example, it has a ref watcher. Right. So you can create your view that is reactive on the contents of some ref. And vars are refs.
Speaker: So you can create a quick sort example from bread victors, where you can create a watcher that watches your expression, your var that you iterate on, and continuously show the result of evaluating it.
Speaker: write some codes, send the form that defines this var and it will immediately update it. And I think it might be very useful. Maybe right now it requires some setup.
Speaker: But I mean, that's not a big setup. It's all can be built from the built -in extensibility features. You just have to know how to use it. You're using it wrong. That's another way to close the bug. You're holding it wrong.
Speaker: No, I think it's very important to know that there exists something that you can use. Yeah, I think this is one of the biggest challenges with the new age UIs. I mean, the discoverability is a really big problem. And obviously, that's the reason why I prefer Space Max, because with discoverability, I just press space and I know what is available.
Speaker: And I think that is truly not possible in any other IDE so far, or editors. Yeah, I really love this part of Space Max. So reveal also uses space as a domain shortcut to open the context menu. So that's where you got inspiration from, Emacs, we know now.
Speaker: Nice. I think we're out of time now. So let's talk about Space Max then. So that's when we say, oh, no, no, no, no, no. Anyway, so any other things that you're doing that were to mention now?
Speaker: Because I think mostly CLJFX has multiple projects in it, I think, and Reveal, and also the bigger problem space that you're thinking about. Yeah. I'm not sure if there is anything left to mention. Well, maybe. Well, I guess.
Speaker: The problem is that reveal is visual and we are in the podcast where no one can see it. Yeah. Well, I guess they can visualize our podcast by now. It's basically bleeps and you know. Yeah, but I'll be giving a talk at Cyclosh on 7th of November where I will give a presentation with slides and anything. And we will be talking about reveal.
Speaker: So if you want to have a look at it, please join. Perfect. I think hopefully our episode will be before that 7th November, because our episode is usually lazy loads. So in fact, they're going a little bit later, I don't know, depending on the situation. But if you are listening to this before 7th November, what time, by the way? Oh, I don't remember.
Speaker: I think. Okay, 7th November at some point, you know, follow Cyclo's Twitter account. And obviously the people at Cyclo's, they're doing some awesome stuff. So if you're listening to this before 7th November, now you know. If you're listening to this after 7th November, we told you so. Just watch the YouTube video. Watch the YouTube video, yeah. Exactly.
Speaker: So on that, I think you've got some very nice, just before we finish, I think you've got some very nice visualizations on the GitHub page as well and animations and stuff like this. So I think people can very quickly get a good feel for what Reveal does. Yeah. Yeah. Sorry to invite you on a podcast.
Speaker: We've got to make a live videos again to show what is happening. But maybe, I'm not sure. I think, Ray, you can do this on Apropo, right? Then you can show. We actually featured Portal, so I might invite Vlad on Apropo as well, because then we can do a YouTube. We do it on Discord again, but it's all kind of streamed live. So that could be another good place for you to actually do a demo on. So we can do a bit of cross -promotional work here, OK? Yeah.
Speaker: Yeah, I think that sounds great. Right. Excellent. Because obviously, I mean, the biggest challenge is how to visualize. We have a hard time visualizing stuff in an audio -based medium. I think it makes sense to just show it instead of telling about it. That's much easier, I guess.
Speaker: Yeah, I think this has been very good exploration of the ideas and of the architecture and stuff like that. But yeah, you're right. We need another way to actually show it off for real. You know, it's a pretty excellent tool. So, you know, I encourage everyone to go and try it out and have a look no matter what you edit. All edit is welcome. So it's. Oh, that is only one that matters. So as long as it has a connectivity between emails and everybody's happy.
Speaker: And sooner or later you will be able to control it from the Emacs. Exactly. Then it is the perfect world. Everything should be controllable from Emacs.
Speaker: Nice. Okay, so on that bombshell, I think we can wrap up the episode. Thanks a lot Vlad for coming on the show and then trying to explain something such a visual thing via the only sound.
Speaker: Thank you. Unlikely, I haven't tried it yet, so I'm going to give it a try, certainly. Then probably bother you with some questions on Slack, where I'm going to get to a point where, if I cannot connect it using Emacs, then you'll close it as won't fix. I think that will be a big fuck off. Fuck off from me. Fuck off from him. That's a perfect way to end the show. Exactly. So does everybody fuck off now?
Speaker: And hopefully everybody is staying safe in these times. And we will see you in another episode soon -ish. And don't forget to check out
Speaker: or maybe you have checked out already, 7th November, the presentation by Vlad on Cyclodge. I think you should be able to see the links for them on the regular stuff like Closure Reverse, Closure Worse, Closure Worse, and also Cyclostrator account and all of the places and Reddit. So that's it from us for this episode. Thank you.
Speaker: Bye! Bye bye! 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.
Speaker: 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 won't interact with us then do check us out on slack closure in slack or closure verse or on Zulep or just at us at Deafened podcast on Twitter
Speaker: Enjoy your day and see you in the next episode.
Speaker: We keep insulting old guests so they will show up again to kick our asses. Who is this fucker that we've wanted to show before?
