Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
#3 - A tour of the REPLs with Mike Fikes
91 Plays9 years ago
This episode we welcome Mr Mike Fikes to help us on a tour of the Clojure REPLs
Recommended
Transcript
Introduction and Podcast Goals
00:00:26
Speaker
Well, should we just restart? So, that's it. Episode 3. Here we go. Hello, Ray. How are you? I'm good, yeah. Like you say, hello, Ray. Ray McDermott here from Belgium. This is Vijay from Holland.
00:00:44
Speaker
And we just wanted to make sure that we introduce ourselves a bit so people don't forget us already. And just a quick reminder that we're doing this podcast to try and give people a deeper technical understanding about closure and closure script. Hopefully still keep it fairly accessible.
00:01:06
Speaker
But I think we've had some pretty good support and follow up from the listeners.
Listener Feedback and Community Engagement
00:01:14
Speaker
It's been pretty positive. In fact, remarkably positive, even on places like Reddit.
00:01:19
Speaker
Yeah, I mean, I'm actually really surprised and it was pretty amazing. And as you were pointing out, there was before even we announced it that a new episode is available, somebody else already tweeted following SoundCloud upload. So we are very happy with the feedback that we got so far. And we hope to keep the level up and then help you guys. I don't know whether you're listening while you are doing your workout or going to your work. You know, we want to be we want to make sure that you get some closure knowledge.
00:01:49
Speaker
exactly yeah actually the other thing we should do is uh make a shout out we've got a website on deaf and audio we're also on the twitter's um you can find email on there as well if you want to get in touch with us to tell about conferences or meetups or other things that are happening in uh in the closure sphere um we're in europe but anywhere in the world really you know this is a global thing so we're
00:02:16
Speaker
We will tell a bit about European things, I guess, as things get a bit more exciting in Europe around about October when we get the Euroclosure bandwagon rolling into Bratislava. I've booked my aeroplane tickets, by the way, for that. Oh, OK. I was planning to do a road trip
EuroClosure Conference Plans
00:02:32
Speaker
there. So I'll probably drive... Oh, you're making a road trip? Yeah. All the way from the Netherlands to Slovakia, I think, is it? Slovenia. Slovakia. Slovakia, yeah. Bratislava. Yeah. Yeah.
00:02:42
Speaker
It's going to be a pretty long road trip, but I hope to have some maybe nice company during that time and then we can talk stuff. Or maybe we'll do a podcast on the road. Okay. All right, good. Let's get into
Interview: Mike Fikes' Contributions to ClojureScript
00:02:56
Speaker
this episode. I think last episode we discussed a lot about the reader and we promised that we are going to get into REPL. And I also, I think, made a
00:03:07
Speaker
nice tweet or I was picking some people's interest that we are going to have an pretty good episode with a surprise for you guys and girls. So let me introduce our special guest for this episode and he's been very kind to
00:03:22
Speaker
respond to our request and then as you probably know him or the closure people already know him I think so he's been the primary developer for plank to bring closure script to the Mac and also the replete so you guys are I think Ray was showing off replete on his iPad Pro and so I'd like to introduce Mike Fikes. Hello Mike. Hi Ray. Hi Vijay. How you doing? Good. How are you?
00:03:50
Speaker
Really good. Thank you for joining Across the Pond. Oh, no problem. By the way. Yeah. Yeah. So I think, first of all, we'd like to do a quick introduction.
Understanding REPL in Clojure and ClojureScript
00:03:59
Speaker
So can you tell us something about your interest enclosure, and how did you start into building these kind of ripples? And you're contributing a lot, especially for the Mac and iOS platform. So how did you start? Yeah. So I would say that I was probably like someone who wanted to do functional programming maybe about five years ago.
00:04:18
Speaker
And I went down the path of learning about Haskell and Scala. I didn't really get into Closure back then, but later on I was developing iOS apps and I kind of had the freedom to do whatever I wanted to do because I was doing it for myself. And I ultimately decided to try doing it using Closure script. And that's what kind of got me into the Closure ecosystem in the language.
00:04:45
Speaker
And I think that was maybe a couple years ago. And to do that, you kind of want to have a REPL into your device. So that was kind of like always this dream of mine is to be able to have a REPL into my iPhone.
00:05:00
Speaker
Yeah, because I mean, one of the things that I was really surprised about this whole Apple ecosystem is that there was no other language run times where I load onto the App Store before. And then that's true. Yeah. And then later they started allowing, okay, you can use JavaScript. And then I think that kind of paved the way to
00:05:18
Speaker
making this application. Yeah, I was kind of worried about that as well. I had a conventional app even prior to that that had ClosureScript inside of it, running it. You can't even tell that it's in there if you didn't know. But I was kind of wondering, well, Apple might know. But you're right. Later on, I think they actually formally blessed that way of doing apps.
00:05:42
Speaker
Yeah, they had even a session in one of their WWDC conferences where they talked about how to use JavaScript to drive an iOS app. So it's definitely a blessed way of doing it. I guess the only thing that's a bit weird about the JavaScript on iOS though is this whole thing that's going on in the ecosystem about circumventing the update process.
00:06:07
Speaker
Yes, yeah, so reviews take like, well, I guess they're getting quicker now, but they used to take about a week at least to get through a review. So you have this motivation to want to try to avoid that if you can. And I think Apple really just doesn't want you to fundamentally change the behavior of your app without it really going through review.
00:06:30
Speaker
But you're right. If you can just have almost like a backdoor or a new way to put some JavaScript in there, you can update things. That's kind of a...
00:06:43
Speaker
So to set up some sort of an, I don't know, kind of a vague agenda for this episode. So first we'd like to discuss some, the internals of Repel a bit. Of course, Mike will be helping us and we'll be asking questions to Mike. And maybe we are going to interview Mike, then give him a job as a Repel author.
00:07:02
Speaker
or at least, you know, Mac expert. And later we'll get into a bit more into the integration of the REPL and the IDEs. And I think Ray was pointing out some other uses of REPL as well.
00:07:17
Speaker
Like, yeah, so I think we want to look at, there's a different, there's different, various different classes of repls, isn't there? There's repls, which are kind of like stuff that's for specific platforms, stuff that's inside of IDEs, stuff that's like listening on the file system for live coding experiences.
00:07:34
Speaker
and then stuff that's on the web, so you can have embedded closure script in your web pages, and then there's all these kind of fun things that we maybe just come to at the end a little bit, like live repels, live music, repel as a kind of art form. So yeah, okay, maybe as you start, Mike, with your tech job interview day one, where me and you two will just troll the shit out of you about
00:08:05
Speaker
So Mike, what do you know about Closure Script then? I don't know which other you go first. Okay, sure. So we have been checking your GitHub and we noticed. Ah, okay. Anyway, so let's talk about REPL. So Mike, can you tell us a little bit about how REPL works from a tooling point of view and how REPL reads and gets the forms and gives you the output?
00:08:33
Speaker
Yeah, so I guess normally you have to type something into a computer, right? And it has to read your characters. And then at some point, something in that stack gets this stream of bytes or a string, basically. And that's...
00:08:52
Speaker
I suppose if you have a REPL that's written in Java, you're using Java to get that through some sort of input mechanism. Something like Plonk is, or Replete, they're using native ways to get that. But ultimately, I guess, in the end, you're just getting a string that's passed to you. And you can get it whatever way you'd like when you're building that REPL. And then, of course, you have to take that string and pass it to the reader, like your last episode was talking about.
00:09:20
Speaker
And you can convert that into a form. And what I think is kind of interesting is in something like Clojure, you can then have that form be compiled. And what's interesting in Clojure script, you're transpiling it, right? You're turning it into JavaScript.
00:09:42
Speaker
And one thing that's kind of interesting about, if you think about conventional ClosureScript REPLs, the JavaScript engine is actually running off in a browser, in the typical case. That's basically the kind of piggybacking into the browser REPL using the browser REPL. Yeah, in that case, really one fundamental setup is that you have a Java process that is your REPL running on your computer, and then you have your browser sitting there with the JavaScript engine running in it.
00:10:10
Speaker
And effectively, inside the Java process, you're using the closure script compiler, which is written in closure, to compile down to JavaScript forms. And really, it's not that complicated, but what happens is once you have the JavaScript, you send it across the wire or whatever, some way to get it into that remote JavaScript engine, and you evaluate it in there.
00:10:34
Speaker
as JavaScript. And that kind of mutates your JavaScript environment, usually making a new function or maybe defing a new value, something like that. So the fundamental difference between closure REPL and closure script REPL, as you were pointing out, is the way the compilation step, essentially, in case of closure. And there is no compilation step in. Well, there is compilation, but that is basically transpiling into JavaScript. Yes.
00:11:04
Speaker
And apart from that, I guess it's roughly the same model, yeah. Okay, so Mike, what about the kind of traditional ripples that are terminal-based, like Plank, or stuff that's based over the network, like N-Ripple or Socket-Ripples?
Comparing REPL Implementations on Devices
00:11:25
Speaker
What do you think about the differences there, in terms of the implementations?
00:11:32
Speaker
So I guess, one, you mentioned socket REPLs and in REPL. I guess you could draw a distinction between REPLs that have their environment with them. Like plank is an example of that and replete is an example of that. Since they're based on bootstrap closure script, they're kind of closer to closure.
00:11:51
Speaker
And the fact that the underlying host, if you will, that we always talk about, these are hosted languages, the host is there with you in the REPL. And when you have something like Ambly that's talking to a remote iOS device or a traditional REPL that's talking to a web browser, those are the cases where you have something that's remote.
00:12:17
Speaker
But then if you think about socket REPL, that just lets you use even like closure or closure script REPLs, you can use those across the wire. So in that case, you are remote, but the actual, the REPL, if you will, is kind of itself remote from you. You're just basically telnetted into it and sending characters to it across the wire.
00:12:43
Speaker
I think you were also mentioning the kind of – so what is the communication medium? So a normal socket REPL is essentially bytes, right? Yeah, yeah. So socket REPL is remarkably simple. It's basically – you can imagine if you had a normal REPL – and this is exactly the way Flonk works and I'm assuming the closure of socket REPL works.
00:13:02
Speaker
is you basically, inside your REPL, say you have a REPL that's working like Plunk was, and then I said, oh, let me add socket REPL support to it. All you do is you open up a socket and listen. And as those bytes come in, it's almost as if, it's the same as if the user had typed that into the console. You know, you take those bytes and you almost treat them in the same way. And you evaluate them and then you send the, you kind of like print the response back across the REPL, not across that socket.
00:13:32
Speaker
Okay. So in the case of NREPL, I think it's much more structured or there is a protocol or some sort of a schema behind it. Like what kind of data that is flowing on network? I think you're right. Yeah. There's, there is some sort of, I haven't dealt with it, but yeah, there's some, something more to it. Okay. Yeah. So it's based on maps, maps, isn't it? All the data is sent across in maps rather than as in raw bytes.
00:13:56
Speaker
Yeah. Okay. So I was curious about the naming though. So I can, I can, I can understand replete, you know, replete is based on repl. So there is a, there are some sense of, uh, I don't know how, how did you come up with the name? But why did you, why did you pick plank? I mean, is it planks constant, like max planks? Okay.
00:14:13
Speaker
So I was messing around with Replete and I was thinking, you know, Replete is a bootstrapped REPL and I was using it and it was pretty quick to start up even on an iPhone. I'm like, oh, I can actually, you know, start it up and within a second or two, start typing forms into it. So I'm like, oh, what if I took this thing and I put it on the desktop? It'll be even faster, right?
00:14:33
Speaker
So that's what I'm like, oh, I'll put it on there, and I'll see how quick I can get this thing to start up. And I'm like, what is the fastest thing you could think of? And that's the planks. It's that plank time length or whatever. So that's where the name came from. I'm like, ah, maybe I'll just make a play on that. Yeah. Pretty cool. So some days it's going to be super fast that we'll probably start to travel back in time, essentially. Yeah. It'll anticipate what you're going to type in and evaluate the form before you take it. You've got some AI work to do on that one.
00:15:03
Speaker
Okay, so can you give us some idea about the kind of technical underpinnings or technical details about the repels that you have? So I heard from Ray that you were using WebDAV or something to get the repels working on iPhone in the beginning. Yeah, yeah. On iOS essentially. So what is it based on right now? So how does it work?
Exploring Ambly's Architecture
00:15:25
Speaker
Okay, so that's ambly that Ray was referring to. And the technical thing about that one is that if you think about you're using a ClojureScript REPL normally, what it'll do is as it compiles or transpiles your
00:15:44
Speaker
your files or your code to JavaScript, those get written to disk. And the way they really work is then that stuff can be loaded into your JavaScript environment. The real difference with Ambly is that the
00:15:59
Speaker
The JavaScript core engine is remote. It's on a remote device. Actually, David Nolan came up with this architecture, which is to say, hey, instead of having the compiler output be written to disk on your Mac, essentially, what if we redirect it to point it at the device and write to a file system on the device?
00:16:20
Speaker
And that's roughly, if you really summarize what Ambly is doing, is it's basically compiling to the device as a disk. And then there's a little bit of coordination above that to say, hey, after you've compiled this file, go ahead and tell the remote JavaScript engine to load that file in. Load the resulting JavaScript in.
00:16:40
Speaker
Okay, but how do you contrast it with Planck and... Okay, yeah, so Planck and Replete have an easier job because they are kind of co-located with the JavaScript engine. So in that case, it's as simple as basically saying, okay, the user typed in a form, let me compile it, transpile it to JavaScript and evaluate it right there in the same environment. There's no need to deal with
00:17:08
Speaker
you know, tossing it across the wire to a remote entity.
React Native and Functional Programming in App Development
00:17:13
Speaker
Just another thing, following up from that, Mike, actually, does that mean that on Ambly, with Ambly, you don't need React Native?
00:17:24
Speaker
That's true, yep. So I've used Ambly to just develop straight up apps where you have a ClosureScript environment running in the app. And actually Ambly was created before React Native existed, yeah. So you're right, exactly. Interesting.
00:17:39
Speaker
Because obviously React Native is mostly about making the UI more performant anyway, isn't it? Rather than actually having the underlying JavaScript engine itself, because that does come with iOS, like you were saying earlier. So it's just a matter of making the UI nicer and smoother and more responsive on Android and iOS. Yeah, and I think, at least for me, the whole draw of React Native. So I wrote a ClosureScript app in the App Store,
00:18:06
Speaker
I don't know if I would do that again now, now that React Native exists. Because what I did was I basically, like I said, I have this dream of writing stuff in a functional way, pure functions, immutable data. And that previous app was built by having ClosureScript, if you will, drive and poke at the native UI elements. What else are you gonna do? You have to kind of do it somehow. And it's this big bag of mutation, right? And now, for me, the important thing, for me at least, with React Native,
00:18:35
Speaker
is the ability to use things like ohm and reagent and take a more structured approach to things and deal with things in a more functional manner. Your UI is a function of your state kind of argument.
00:18:52
Speaker
So I see that I've been trying out Replete on iOS, obviously. And of course, I miss Emacs, because you know, Replete has this tiny text area. And it's very difficult to type. I apologize. I apologize. How hard it is to type on it. No, no, no. It's already awesome. And we see that the way that you are building features into it, for example, you just introduced the parent for support, I think, pretty recently.
00:19:18
Speaker
What is, what was it, is pattern for completely implemented in ClosureScript in unreplete? Oh, okay, yeah.
00:19:29
Speaker
So par infer was originally implemented in, um, enclosure script. Uh, and then Sean, Sean LeBron, I think you optimized it and he, he took his original implementation and converted it to a pure JavaScript implementation. I think he was really focused on performance for handling cases when you have a lot of texts that you're editing. Yeah. Um,
00:19:54
Speaker
But yeah, I guess you were asking, how does that fit into replete? It's really just a library that it uses. So as you're typing forms, it's actually only using that. It's only using parnfor to decide how to format the text as you're hitting return, if you will, like when you want to go to the next line. It's not really a full.
00:20:16
Speaker
par in for implementation. So it's kind of. I thought when you opened the parenthesis, I thought when you open up a parenthesis, it did pop another one afterwards. Oh, you're right. Yep. Nope. See, I forgotten about that. You're right. It does do that. Yeah. It inferred a parenthesis, perhaps, you know? Yeah. Hence the name. Come on, Mike. Come on. Thank you. If you didn't want to get this job, you know.
00:20:43
Speaker
But do you plan to make it like a full editor eventually? Because I would really love to have that on the device. I know opening files and all the stuff is pretty difficult on my course. I know that. I have some editors installed on that one, but they get the data from Dropbox or some other places.
00:21:02
Speaker
Yeah, so for me, replete was all about, I don't know if this is common amongst people, but when I was learning closure, I would walk around and think about it, right? And I'm like, oh, how does this form, how does that form work? How does binding work? You know, all these little, all these concepts that you're new to, and to be honest, it's kind of geeky. I would like, want to just try it out. You know, you want to, you will think about something, you want to try it on a REPL, and sometimes you don't
00:21:27
Speaker
you're not at a computer. So my dream was really just to have a simple REPL that I had with me in my phone to try little short form things on. So I think it's good for the educational or learning phase.
Replete as an Educational Tool for Clojure
00:21:44
Speaker
But, you know, some people like to actually take their iPad on a train or something like that and try to edit some code and use something like Replete to do that. So I think better editing support in it would be great. Yeah, that's true. I think it will be amazing because you're pointing out people using it on the train, but you're just putting ClosureScript or experimentable Closure implementation on an iPhone essentially means that there is a huge next generation of people
00:22:13
Speaker
sitting in the toilet, actually typing closure forms instead of reading Reddit. Oh, yeah. So there is this. Everybody uses phones. It's a nice image. Yeah, but but it is it is spectacularly useful, I must say. I mean, that's what I use it for. And I just opened it up in the phone and I have a pleat and then I just type in, oh, let me try this protocol thing and I just start typing it in there. So that was really fun. Yeah.
00:22:36
Speaker
I still even use it today like if you're like for example like syntax quote you're like how how does sin I mean my god you really have to type those things out and just try them and and it'll bug you if you don't yeah so and and the main thing I would like to somehow add to replete is perhaps a better keyboard that's like has some parentheses on it or something like that but that you know that's evidently hard to do so
00:22:58
Speaker
Yeah, because I'm using the prompt application by the panic guys, you know, the SSH. Yeah, I've used that one. Yeah, they have pretty amazing keyboard there. Of course, you know, because the whole parenthesis, you can customize it. I was curious how difficult that is. Maybe I should try that out because I did try some Mac OS, sorry, the iOS development some time ago.
00:23:20
Speaker
So maybe I can look into it. If there is a right keyboard, like the Lisp keyboard, I don't know if you're following the planet closure thing because there is one person who is now on the quest for building the best Lisp keyboard ever. And maybe we should just take that layout and then try to get that one in.
00:23:39
Speaker
I'm not trying to push more issues into your GitHub, I'm just floating some ideas around. Well, I think the concept of putting an ID around a REPL is definitely something we'll talk about a bit later, but I think it's like...
00:23:55
Speaker
I think it's a lot of hard work, that's for sure. And it's a different task, as you say, Mike. It's something which the ID has to do a hell of a lot more, like interact with GitHub or various other things. It has to have a whole visual flow, saving files. And there's a lot more stuff around it, making projects, integrating with all kinds of other tools. So I don't know. I think we don't want to put too much on Mike here.
00:24:21
Speaker
Well, like I would also say it's replete and plonk are both open source. So if you want to contribute exactly yeah, how about it? Awesome call. Well, actually we're just waiting for VJs pull request on closure from last week, you know
00:24:39
Speaker
He's going to make all kinds of good things happen. Yeah, just actually before we sort of finish up, there was a little chat going on around, I think it's mostly initially instigated by Colin Fleming and his talk at the conge recently. Not this one. Or was it this one? Was it Closure West? I can't remember. It was the conge, wasn't it? Some conference in America.
00:25:06
Speaker
and he talked about how we could do better with error messages and he's definitely trying to do that with with cursive and then Bruce Hammond is starting to do this stuff with uh configuration files around fig wheel and I know you're interested in it as well could you maybe give us something what's your what's your feeling around that area what you know what kind of stuff could we
00:25:29
Speaker
What do you think about that and where do you think we're heading? If you look at the history of ClosureScript itself, even just going back a year ago, the ClosureScript language itself, the implementation was solid. You could rely on it to work, but the tooling and all the...
00:25:49
Speaker
All the stuff surrounding that was harsh or difficult, you know, and still is in many ways. But I think with enough effort, the community has kind of polished enough of things.
00:26:01
Speaker
And we've gotten to a point now where ClosureScript itself is, it seems like it's turning a corner now, where people are starting to focus on the nice, the developer experience on top of all of it, so that when you do get an exception or whatever, it kind of shows you where in the code the exception occurred or tries to point to you. Like the gravy on top of things is starting to occur now. That's my general high-level take on all of it.
00:26:30
Speaker
But I think that's a really good way of looking at it, but it's one of the biggest complaints about on the closure surveys that people complain about exception messages and stack tracers and error messages. And people, I think one of the things that I heard on the Cognicast last time when Rich was talking about spec was that actually with the macros,
00:26:56
Speaker
you will be able to put some of this spec magic inside of there to improve the transformations and actually understand where the transformations fail and give better messages. So it seems like some of the underpinnings is getting better as well. Some of the underpinnings, because I think Colin is mostly talking about closure, not closure script.
00:27:15
Speaker
So it's just definitely across all of these environments. And one thing I've kind of seen with spec is you can actually, you can spec a macro, if you will, you can you can define what the macro takes. And one way of looking at what you get out of that is that you can detect
00:27:34
Speaker
failure to conform right away like as you know before like during macro or right before macro expansion So instead of instead of like this train wreck occurring later on after macro expansion and you call something way late, you know, and it's yeah Yeah, you kind of get this upfront, you know thing occurring with spec with macros and I think that could help a lot, you know, I
00:27:57
Speaker
I'll be really interested to see whether with 1.9, because actually originally when I heard about spec, I thought, oh, it's just going to be one of these core async things. It's just going to the library, you know, and it sort of feels like it is a library. But then when you start thinking about it a bit further, you think, oh, yeah, OK, maybe it does need to be in the language because obviously they're very conservative with changing the language itself.
00:28:19
Speaker
But if it's in the language, then in theory, they could reverse engineer some of these macros and put specs around them and actually give better messages. I don't know if they're going to do that, but in theory, that's possible. Yeah. So I was messing around. You can try this yourself. Like if you said, I want to write a spec for Deafen, which is the name of this podcast, right? So you can write a spec for that. It's basically valid, also. But that's true. Yes.
00:28:49
Speaker
If you look at that macro and the way it really works, there's like a lot of steps inside that macro where it's looking to see like, okay, is this the doc string? Is this the attribute map? Is this the arguments vector, the parameter vector?
00:29:05
Speaker
And you look at the way all that's done, it's kind of like hand coded look, it's pulling it apart, you know, and figuring out which pieces are which. And with spec, you have like this, this cat abstraction, where you can say like, this thing follows that thing. It's a regular expression idea, right?
00:29:21
Speaker
And you can say, I guess what I'm trying to say is, as a human being, you can quickly write the spec for deafen. And you can say, this occurs before that thing. And what you get is this wonderful machinery underneath it that will take your spec and see if what the user typed in conforms to that.
00:29:41
Speaker
So it makes it humanly possible to actually just write specs for macros. You know, even if you or I were writing a macro, we could actually write a spec for it and produce a better. Oh yeah, definitely. Definitely. I'm just saying that, you know, if, if they were, if they were to, to sort of do the work on the language as well, then you'd get it everywhere. Cause obviously I don't want to write a spec for deafened. Oh yeah. That's, that's a good, I think.
00:30:06
Speaker
I think that there, oh, I hope, I hope that there's a plan for, for Cognitact or the community to write specs for everything in there. Yeah. Yeah. Yeah. That's basically like, um, like the core type thing or, you know, in the racket community, there is this retrofitting the whole contracts onto the existing libraries. So there is a lot, I think that it's, it's a Spartan effort, effort, you know, there is a lot of, a lot of time and effort required to do that for the entire closure code though.
00:30:34
Speaker
But you could do it on, there's probably, you could do it on, you know, the, like deafen. Yeah, yeah, piece by piece, that's true. Some of the most core macros. Yeah. But I guess the question, it'd be interesting question actually about whether, whether spec actually reveals some behavior that is kind of like, would break things. Well, I'm just thinking if you put, if you put the spec in there, suddenly it won't pass. You know, things that have been, things that have passed before suddenly won't pass anymore.
00:31:03
Speaker
So I don't know, I guess there's all these kind of, cause obviously they're, that's the backward compatibility thing as an issue. So, but they're all, they're actually, if I'm not wrong, you could, you could set it up. Don't say this. Okay. A bit like Scala where it's all optional. Okay. Shouldn't forget that. I'll edit that out.
00:31:25
Speaker
Everything is optional. Well, everything is an underscore. Let's not get there. So coming back to the whole plant thing.
00:31:39
Speaker
Can we use Plank to write native scripts or something on Mac? Because this has been one of the biggest complaints from people, or not complaints, but of course there is a lot of complaints on the internet about everything. But the boot up time for closure itself on JVM, it's pretty slow. Obviously you can't make quick scripts with it, but Plank is, as you say, at the Plank speed, so it's super fast.
00:32:06
Speaker
Can you use it to make scripts and how would that work? Yeah, one thing I would make a comment on is I think a lot of us probably think Clojure is slow to start up because of the length of time it takes Lion to start up when you start up the Lion REPL. Of course, I compared the Clojure REPL to Planck's startup speed.
00:32:28
Speaker
Plonk's about twice as fast as a closure repel, but they're both really fast. I think, for example, it of course depends on the machine you're on, but the closure repel would start up and say half a second, whereas Plonk only goes maybe at a quarter of a second. Plonk is playing this trick on you, though, and the way it makes it look faster is when you type Plonk, it immediately shows the prompt.
00:32:52
Speaker
It doesn't actually wait until the entire Closure
Quick Scripting with Plank
00:32:57
Speaker
Script engine is up and running. It's that first prompt that you see, the CLJS user is hard-coded and native code. And that's the trick. So you're faking it till you're making it. Yes, it's all a matter of perception, right? Of course, of course. And in fact, when you start up Plunk, you can actually start typing. And by the time you, as a human, have finished typing your first form, Plunk's going to be finished starting up.
00:33:22
Speaker
But that trick does not work when you're writing a script, right? Because you're going to execute a script, and you're not typing in forms at that point. The script has got to run. So to answer your question, you can use Plonk, and you can make scripts that run in about a quarter of a second. But in the scripts, though, can I use the whole Node.js libraries?
00:33:46
Speaker
We don't get any integration with them. OK, so that's interesting. So Plunk is based on JavaScript core. And so it basically, if you kind of look at what Plunk really is, it's a bunch of native code that interfaces with the operating system for various things. Plunk has a shell capability. So it will use NS task. It's an objective C way to launch a task.
00:34:15
Speaker
So really, Plunk is a bunch of glue to hook you into various things. And people are adding new things to it. Eric Assum is working on adding sockets to it. He recently added HTTP support. So it's just a matter of taking the native stuff that exists and then surfacing it, if you will, as JavaScript functions that can then be exposed as ClosureScript functions in Plunk. But then there is this whole node thing.
00:34:44
Speaker
Plunk is not based on Node. Plunk is based on JavaScript Core. But Ramzi Nasser has been working on a Node-based version, kind of an equivalent. It does more things, but part of it is it can be a REPL. And he does the very same trick where you start it up and it shows you the prompt right away.
00:35:05
Speaker
But with the node one, does that mean you can run it on other platforms as well? Yes, you can. As a matter of fact, one thing that's kind of interesting is a lot of the stuff that it takes to create a bootstrapped ClosureScript REPL, if you can imagine, it's like a lot of common code.
00:35:23
Speaker
you would imagine being written over and over again. So that was all factored out. Andrea Ricciardi and the Replum effort. He basically took a lot of plonk and a lot of the stuff that Joel Martin did initially with making the stuff work in Bootstrap.
00:35:39
Speaker
mode and made a library called Replum that anyone can use to make a bootstrap REPL. So I then turned around and used that to make one that works on Node, and that one is portable and runs in different places. But I haven't put a lot of effort into it to make it nice. And Romsey actually started using the same stuff. So I don't know if that answers your question.
00:36:01
Speaker
Yeah, yeah, of course. And more than that. Actually, I think two, three months ago, I was playing with the LEGO NXT brick. The Mindstorms thing. Yeah, Mindstorms thing with the latest one. And there is a different kind of core that you can use on top of it. And you can install that one. And it comes with a Node.js on top of it. Oh, wow. And I was able to write Closure Script and then
00:36:29
Speaker
getting to hook into the LEGO NXT thing. That was pretty cool, actually. I think I know Anna Polishka, if I'm pronouncing correctly. I think she was also trying the same stuff as well. I see her tweets on NXT. I took her stuff as well, and my son has one of those. I got him to give me permission to reformat it so that we could use Anna's stuff on it.
00:36:55
Speaker
Yeah, I think that's what I was doing as well. I just, well, initially I was using Legos, you know, it was a Java based operating system on top of Lego, but it was super painful to load. Yeah. And I had the NXT 2 break and that was even crappier. Anyway, let's not make it a Lego podcast, but something for the guys who are listening, you know, you can run Closure Script on Node.js on Lego thing and do cool stuff with it.
00:37:20
Speaker
Indeed. Well I think the whole point about ClosureScript at the very beginning was, if I remember rightly, it was Closure Rocks and JavaScript Reaches. So I think that was the tagline of Rich at the beginning. So of course now wherever Node goes, ClosureScript can follow. So yeah, awesome.
00:37:40
Speaker
Okay, so I think... Do you think he's got the job? I think so. Yeah, okay. I'm afraid it's got zero salary though. Oh, okay. But you have amazing fame as in a... But do carry on and also do everything we ask. Okay. Very quickly. Of course.
00:38:01
Speaker
But just for the people who are listening in, if you're using Mac, if you're using iOS, I'd really recommend checking out Replete and Plunk and play with it and hopefully contribute to stuff that is on GitHub. I think Mike has been doing a lot of work and helping us in putting ClosureScript onto these platforms.
00:38:22
Speaker
So thanks, Mike. And of course, you know, you can hang around and let us know if we want to continue with some other topics as well, not just Plunk and Replete in this podcast, because we started with ripples. And the next obvious thing is that you have a ripple and you want to discuss like what what kind of ideas you use in conjunction, so to speak. And I know there is a lot of ideas like a big contention point in the in the in the community. Everybody has their own favorites.
00:38:52
Speaker
And obviously I'm one of those people who uses Emacs. Why is that obvious by the way? Because of the way I keep bringing it up every other time whenever I speak editor and there is only one true editor and that's just basically Emacs.
00:39:09
Speaker
Well, anyway, so I think one of the major, major... Because you're a real programmer. I don't want to, you know, degrade any of the editors though, but they're not real editors, you know. Of course, these days everything is web-based things and that can't even log two megabyte files and it just crashes all the time.
00:39:29
Speaker
But anyway, so IMAX has been one of the editors for the central Lisp development. It's basically Lisp, of course, with a tiny C core. Probably as Mike was pointing out, there is a tiny objective C core in Planck, and the rest of it is closed script, I hope. Something like that.
00:39:46
Speaker
So, Emacs is built in Lisp and initially there were some efforts around bringing closure to Emacs in different ways. There is closure mode and there is a lot of different kind of packages.
00:40:02
Speaker
I hope I'm pronouncing his name correctly, Bozidar Batsov, I think. So he came in and he's the god of Emacs right now, at least for the closure development. He makes great presentations, by the way. I love this guy's presentations. I'm not a user of his code, but I do love his presentations.
00:40:19
Speaker
Exactly. I think he is much more into Emacs than I am though. So I think he brought all the things together and then there is this community effort called CIDR which is basically Closure IDE for Emacs. So that's what I use and CIDR comes with lots of fancy stuff. I mean there is also CLJ refactor so all the refactoring things are also available as a package.
00:40:44
Speaker
And I'm not sure how many of, I mean, I don't know if you have guys seen Magnar's E-Max Rocks Podcast and he also made this zombie game in E-Max. I think zombies versus parents or something. So he made a live recording of building a closed script game.
CIDER Package for Emacs: A Developer's Tool
00:41:02
Speaker
in Emacs and his screen calls are amazing. But anyway, so Emacs is one of the nicest things and of course, Emacs is a CIDR obviously and CIDR has this multiple projects in it, multiple packages. So you have the closure mode that gives you nice syntax highlighting and everything that's standard with every editor.
00:41:20
Speaker
And then you have this REPL connectivity within Emacs, within CIDR, that uses N REPL. And it has, I think, somehow it was before this network REPL put into Closure 1.8. So there was this effort going on already. And there was some discussions about how the same stuff can be used everywhere as well. So it kind of set a standard, so to speak, in terms of the network REPLs, I believe, at least for the Closure and Emacs world.
00:41:50
Speaker
But obviously there are other editors, I think, like cursive. And last time I was making a joke that, hey, Cyro has Cyro in it and cursive has curse in it or something like that. It was a bad joke then. I mean, it doesn't be better. But OK. But yeah, I think what's interesting actually is because, yeah, I'm a cursive user. So is Mike as well. So it's two on to one. Yeah. But
00:42:21
Speaker
I think what's interesting about cursive is that it understands the kind of compiler itself, understand and repel itself, understands the language. That's the big difference, I think, between
00:42:37
Speaker
repels that are running in vim and vi and sorry vi and and emacs and other systems whereas with cursive cursive really understands all of the forms so when you're looking at the ripple like in the ripple you can
00:42:55
Speaker
reformat everything you can you can all the syntax highlighting has been working from day one it's really got a complete understanding of closure itself the syntax and not just a connection to an external REPL that it can poke and see what the error messages are yeah of course i mean there is there is probably an emacs command for that but i'm not gonna say it loud
00:43:20
Speaker
There is all text butterfly or something. But one thing that I think actually, to be perfectly honest, I mean, obviously, everyone can have their way out. That's not a problem. I think the reason why edit is like cursive or interesting and do the edits like atom, which has this ink ripple. Yeah.
00:43:36
Speaker
is that people sometimes want to come to closure and actually just learn closure and stick with a kind of editor they like. And the good thing about things like cursive and atom and stuff like that is that actually that's possible now. You know, if you're coming from Java or JavaScript or whatever, you can pick up an editor and just essentially have had it with, I mean, actually, do you know that the Microsoft
00:44:02
Speaker
version of their editor, what the hell is it called? Visual Studio Code. It's something like that, Visual Code or something. Some sort of cut down version of their Visual Studio that Mike was such a big fan of before apparently. The Visual Studio Community Edition, that's based on Electron, which is this Atom thing. And they support Closure.
00:44:26
Speaker
Yeah, I think when you're talking about cursive, I think one of the most interesting use cases for cursive, for me at least, is mixed code bases, especially when you have Java and then Closure code base. And also, when you're digging through large code base, like Storm, for example, when Storm has
00:44:45
Speaker
plenty of closure code in it and then navigating it becomes pretty easy in cursive. So I do that with intelligent cursive when I'm navigating large code bases because you can click around and see the, you know, hierarchies and all that stuff. So Storm has some Java code and then closure code. Storm the big data processing thingy, the real time stream processing stuff.
00:45:05
Speaker
So that's one of the nicest parts about Curciv and also as you're pointing out, if you're used to Java development and then switching to closure development is essentially just installing a plug-in and you know the editor, you're used to it. And there is no, I remember like three, four years ago, whenever somebody wants to get into closure, the first advice was first learn Emacs.
00:45:25
Speaker
that itself, you know, putting people off. And it's a big, big hill to climb. But these days with the different kinds of packages, like the CIDR's author, Bojidhar, has his own starter package that's very helpful if you want to start with Emacs. And also there is Spacemax and those kind of things help. But still, they're built on a lot of historical craft. So you need to understand a different editor completely.
00:45:53
Speaker
But Mike, so we've been, you know, going about cursive or versus, you know, this one. So what is your preferred editor? Oh, I like cursive. I mean, I think I'm a pretty simple, I'm a pretty simple human being. To me, to me, Emacs was awesome because it was simpler than VI, you know.
00:46:13
Speaker
way back in the day and i don't think so come on oh i think so it was ways away so okay in emacs you can just i don't know i was always a vi guy so i guess it was the modes that you have to be in a vi but anyway yeah i i remember it being that way but yeah i'm i i i'd use like the normal light mode instead of dark mode and i'm just very simple so so i'm i'm at home with cursive
00:46:38
Speaker
Because now i'm using space max a lot so that that's basically vi and then emacs and there is a hybrid mode and holy mode and it's it's a it's a pretty decent community though so it's been serving me pretty okay so but just just a quick question now what why does emacs call cursive uh call uh closure an inferior lisp
00:46:59
Speaker
It doesn't because inferior list is, well it's not closure but initially when there were different kinds of ways to plug in your buffer, buffer is what they call like the editor window and then sending the forms to a different process. So there is a process that is started that is inferior to the main process that you're using.
00:47:21
Speaker
So there used to be an inferior lisp initially and then there was slime and then slime used one protocol and then later I think when I was having a joke actually I mean I just really meant that it looks you cut on the screen all the time inferior lisp inferior lisp this is an okay lisp actually you know but you want a superior lisp exactly exactly you can just rename the buffer you know
00:47:47
Speaker
Good to know, good to know. Actually, I was going to talk to Mike about the stuff, the ripples that are in Xcode, because if you're using Swift, the playgrounds and things, I think those guys have some pretty swish things. Or maybe it's just, and actually, I remember looking at your, I think it was on replete that David Nolan said that there was a scheme raffle that you should imitate.
00:48:09
Speaker
You know, we should, there's all this kind of stuff out there, but there's definitely, there's a lot of, let's say in the editor land, there's a lot of, still a lot of potential to make the whole rebel experience a bit more swish, smooth, delightful, you know.
00:48:26
Speaker
Yeah, one thing I kind of wonder about is that just the idea that it's, you know, if you think about things like basic, right, you could flip on a computer and in the 70s and basic was kind of like amenable to typing into a REPL, right? You could just type in, yeah, type in a little simple statement and hit return and it meant something.
00:48:47
Speaker
And if you think about something like Java, I don't know how the Java REPL is supposed to work. I haven't played with that. But you need to type up enough stuff to mean something in languages like that. So I've only played with the Swift REPL a little bit. And I can't recall what it does with that concept of being able to type in something small enough that actually could be evaluated that is meaningful.
00:49:11
Speaker
No, it is like that. It really is. It's very closure-like actually. So you can just write functions. Actually, Swift is quite functional. You can just write functional forms and just add 2 plus 1 and stuff like that and you'll get a result or you can have a for loop. It's very REPL-like.
00:49:30
Speaker
I'm curious about the Java 9 REPL though. I haven't tried it yet, but I think it is now ready for developer consumption at least. I'll try that out soon. But I remember back in the days there used to be bean shell for Java. So you could just play with a smaller version of Java, so to speak.
00:49:50
Speaker
and in one of the projects I embedded it into the swing application and then Bean Shell and that was something that I don't want to recall but especially moving on to better ripples these days.
00:50:04
Speaker
Okay, let's see what else. So obviously, these repels are, I think, more like development tools and they're taking some forms and then evaluating them and giving
Figwheel and Live Code Reloading
00:50:16
Speaker
it back. But nowadays, there is this better versions. I think the discussion we are moving towards, like you have this swift playgrounds and that shows the real-time evaluation of your form. And I think in the closure side, we have now, obviously, we have to talk about Fig Wheel. Fig Wheel is one of the
00:50:35
Speaker
awesome tools ever, you know, you don't need to refresh. And initially it used to be like, okay, you write code, you compile, wait for this thing and then reload it or redeploy the whole package and then see the results back in the days when I was doing the SIEM development, JVA SIEM and all the other crap. And then, yeah.
00:50:52
Speaker
There is this heart reloading and some sort of a Java agent to load the classes and all the crap and then This whole web development like okay I change the code and then I refresh manually and then I see the changes and even that became a big a big time-consuming thing apparently and then the fig wheel came in and live reloading this has been ridiculously
00:51:16
Speaker
different or even productivity tool, right? I mean, you just plug in. For sure, yeah. You start it and then every time your code is compiled on the fly and then you see the results. And even the better thing is, as I was pointing out earlier, before the podcast, obviously, that we have this, I'm not building a line electron application that comes up with a fig wheel support automatically. And then I'm typing the code in and I see the results immediately. And I also see the error
00:51:45
Speaker
things and it shows that okay I can't load this namespace because there is an error in it and Figmeel I think was it Bruce Howman and I'm very bad with pronouncing names though I think that works okay so I think therefore there is is really really helpful in terms of if you're building code and then you're writing code you don't need to wait for things to load
00:52:09
Speaker
But the main thing about that is that you can be 15 pages in and some fuck up happens and then you just make a change to your code and bam, you can just reload that bit of the application. That's the wonderful thing about it, isn't it? So you don't have to go all the way back to the beginning again. That's the really nice thing.
00:52:31
Speaker
But there's a whole class of these things that are hanging around, listening for stuff, changing. Figreal is obviously the poster chart of that. But in my favorite hoplon world, we also have that with the hoplon and boot. So you have a live coding application as well. So if you make changes to your
00:52:54
Speaker
to your h-list or whatever as you're going along, you're changing some CSS on the page or some HTML, bam, it just refreshes it live, you don't need to make any changes. So I think it's worth saying that other tool chains, what are they saying the adverts? Other tool chains do exist or other tool chains are available?
00:53:18
Speaker
So kudos to Bruce, but also kudos to Alan and to Mischa on the boot and Hoplon side because they're doing great work over there as well. And it's very, very reactive.
00:53:29
Speaker
Yeah. And also on the server side, so, Mike, you're using a lot of ClosureScript. Do you also build Closure server-side applications or do you use Closure? Yeah, I do. Yeah. Okay. So what kind of tooling did you use there? Did you use, I don't know, line, sorry, any ring middleware, like ring refresh or?
00:53:50
Speaker
What is your workflow there? I think I'm more of a, I take more of a basic approach for myself where I would just, I go to the REPL and I type require this namespace with the reload flag. But the idea of, like Stewart Sierra's component I think is pretty compelling. I've started using that recently. That's kind of nice in the idea of it taking care of tearing down your state and bringing it all back up again.
00:54:20
Speaker
Yeah, but to bring up the whole refresh thing, obviously you need to structure an application in such a way that you can reload the state easily, right? Otherwise it's going to be fairly painful to load. I don't know, maybe you should compare with the way that you store the state in own based applications or Hoplon, for example. Well, I think, yeah, I mean, definitely the big difference is this, whether you have a,
00:54:50
Speaker
a single state or multiple states, how fine-grained your states are. Obviously, it's more fine-grained in Hoplon than traditionally in React. Yeah. And the model is very different, actually, I think, between the two things. So one of these days, we've since we've had a cursive versus cider chat one of these days, we should have a Hoplon versus React chat. Yeah. Because I see a few things doing the rounds there.
00:55:16
Speaker
But I think that the whole concept of hop on boot is basically to say, you know, we're going all the way on lisp. We're not we're not going to stop halfway. Yeah. Whereas I think I think the React guys are very practical in saying, well, actually, we get a lot of reach out of the arm and the reagent guys are saying, you know, we get a lot of mileage and a lot of reach out of React. We don't get that from just from just from just from just from JavaScript.
00:55:46
Speaker
Okay, so let's see what other REPLs are available. So right now there is lots of stuff on the web, obviously. I think the first one was triclosure.com or something that was running probably end REPL on the server, and then you're typing forms, and that was the first one. That brings back good news. Was that FOGUS or was that someone else? Oh, FOGUS did Hymira, right? Oh yeah, Hymira, yeah, that's right. But this was even before that, I think triclosure. Maybe it was...
00:56:12
Speaker
probably Ryan or somebody. I don't remember. I apologize. I'll look it up next time and we'll give you the proper attribution. But I think the latest amazing thing that we have seen is clips, right? In my opinion, it is possible because of ClosureScript and ClosureScript. That's true, yeah. So now you have the whole ClosureScript environment available in the browser. So that's
00:56:39
Speaker
Yeah, if you look at the way Hymera works, it is a ClosureScript REPL in a web page, but it operates by sending forms to a backend server that has Closure available to compile it. Yeah, but yeah, this whole bootstrapping thing allows you to basically have the compiler in the web page with you. Yeah.
00:57:02
Speaker
So we could put, you know, all the quad core machines that people have these days and then just use their browser. Yes, yeah, farm it out to them. Exactly. But what I like about that is the fact that it's just, yeah, you can, like I've written some blogs in the, we've all written blogs about closure and stuff like that. And the clips guys are basically saying, ah, yeah, that's all fine. You cut and paste these bits of, you know, these jists.
00:57:28
Speaker
or these little snippets of closure code, but no one can try them. And we're going back to the Brett Victor thing we were talking about before. Brett Victor is all about live code, all about experimenting in the place where you read the thing. If you see some of his documentary, his talks about, or his long essays about
00:57:49
Speaker
Data being live on the page. This brings us really close to this possibility I think what not only brings us close to it. It makes it a real possibility real option Yeah, so you can you know when you're putting your closure code out on the web you can embed it and you can people can play with it people can change it and Experiment with it, which is just just bloody brilliant. Yeah
00:58:11
Speaker
Yeah, of course, I mean, there was some sort of what I'd like to call kind of a prior art, so to speak, I think. So there was CLJS Fiddle, and that was based on JS Fiddle, and you could type in CLJS Fiddle. That just shows you what the JavaScript is, which is nice. Yeah, yeah. So there was experiments, but I think the nice thing about Clips is that the whole embeddable concept, you can just put the whole thing
00:58:37
Speaker
in the page and then just make it run immediately without having any other dependencies.
00:58:43
Speaker
And we also have this notebook kind of stuff, like Gorilla REPL, and so you can, I think notebooks are like a big rage in the big data world these days, and everybody builds a notebook these days. There is IPython, and there is a Spark notebook, and Jupyter, and all sorts of stuff. Zeppelin, of course, yeah. I think Zeppelin is my favorite thing, though. But there is a closure back-end for Zeppelin, so I think Zeppelin is pretty cool. But I think
00:59:10
Speaker
Gorilla repl was the first one in the closure world, right? For, for doing the stuff on the web. Yeah. And that's also embeddable as well. I mean, you know, you can, you can also put that into, um, you know, into your CMS system or whatever. Yeah. So you can publish the fire, you know, what are the documentum or what's the Al fresco, that kind of stuff. Yeah. Yeah. Yeah. Which is amazing.
00:59:35
Speaker
Yeah. And speaking of the Bruce Herman stuff, I think dev cards is one of the ways you can have your application state and then keep modifying it. I never used it though. Mike, did you have any experience with dev cards?
00:59:51
Speaker
No, not directly. One of my co-workers uses it. Let's see, if you try to characterize what is dev cards. Bruce had a podcast recently where he did a good job of explaining it, but it's this idea that you're working on some piece of UI, a piece of UI component, right?
01:00:10
Speaker
And you want to just work on it in isolation. You don't want to have it tangled in with the rest of your application that you're going to be using it in. You just want to have it off to the side and have some container to host it in. And you also want to perhaps see simultaneously different variants on that UI component, maybe different, if it's different sizes or different whatever. And you want to change things and see dynamically or immediately
01:00:38
Speaker
the feedback of what it does to that component.
Devcards: Isolating UI Components
01:00:41
Speaker
That's my high-level understanding of it.
01:00:44
Speaker
Yeah, I think the main point is that you can, so that's right from your perspective, but also I think the idea is that you can then transfer that to other developers. So it's like a literate programming model as well. So it's very, you know, it's great documentation because it's the kind of stuff that, you know, we can't be satisfied with Swagger, you know, it's good. Swagger is a hell of a lot better than Word, you know.
01:01:13
Speaker
We can all agree on that, you know, but this takes that to the next level, doesn't it? All of these kinds of things, which I think are really fascinating, all these embeddable ripples, you know, because we move from like the most fundamental primitive things to now we're really talking about transferable code all over the internet, which is really using the ripple, not only to please ourselves, but also to communicate to other people. I think that's really fantastic.
01:01:41
Speaker
Yeah. Of course, there was other kinds of fun stuff. We must start doing it one of these days. All three of us are just daily tantas. Obviously, we just never do anything like that. We just don't all have to please ourselves. Anyway, right.
Engaging with REPLs for Creativity
01:01:55
Speaker
OK, so.
01:01:57
Speaker
I think we're running a bit late, actually, by the way, guys. We're just passing our time here. So it's just been a great conversation, by the way. So I just want to ask maybe a few final questions, Mike. Any final thoughts or tips or anything about ripples that we haven't covered yet? One thing I would point out is I think, to me, the whole idea of a ripple is kind of like that, the basic thing that I mentioned earlier.
01:02:26
Speaker
It reminds me of being a kid again. Back in the day, you could type something into a computer and make it do something for you immediately. I have a 13-year-old and an 11-year-old, and I hope that the existence of repels will help them more readily just hop into programming. Because if you think about it, like if you say, here's a Java IDE, Go program, that's a lot of stuff for a kid to ... You know what I mean?
01:02:51
Speaker
And even like a real closure program. It's a lot for me to be honest. I mean, I really do. I don't know. I think probably all three of us, we probably all do programming ripples all day. Yeah. So that's the thought I have is that it makes it kind of, it's an entry point for younger kids to say like, I just want to try to evaluate a form.
01:03:12
Speaker
So like my 11-year-old daughter, she knows how to add numbers using Closure now, you know, because it's so simple. And she can actually type it into a REPL and get the instant gratification. Obviously, replit, I suppose. Say that again? Obviously, she's using replit, I suppose, on her phone. Yeah, yeah. Yeah, yeah.
01:03:33
Speaker
I'm pretty sure that's like an amazing thing you know she can just go to the go to the school and then tell you know yeah this is what my dad built I can show you how to define a protocol like wow yeah I don't think she thinks it's special she just kind of it's normal to her
01:03:49
Speaker
She's living in the future, that's for sure. Obviously. If she has gone through the pain of building a spring application, then she would appreciate these things better. Of course, the future generation shouldn't go through the pain. What kids these days are getting into is Scratch. Scratch is the meme.
01:04:09
Speaker
there's also Minecraft and the ability to make mods. And that's a whole nother draw for kids. But what I would like is if there was some kind of bridge from something like Scratch to Closure, that'd be kind of cool. You could almost imagine a REPL being inside of Scratch. If Scratch were written in Common Lisp or whatever, it'd be nice if they would just expose something like that to get kids accustomed to the idea that you can use text to represent code.
01:04:37
Speaker
Yeah, I think Timothy Hall or somebody, he had a presentation at Euroclosure Berlin about making kids programming using closure script. I need to look it up. I'll send the link somewhere to you. Tommy Hall. That Tommy Hall. That Tommy Hall. Exactly. Actually, I was there that day. Yes. And his point was quite interesting. His point was you teach these kids
01:05:04
Speaker
like stuff at school and you teach them in these these languages I can't remember what language it was now but some language about how to make knitting patterns or how to make you know these kind of asia patterns or whatever yeah and then you have specialist languages that you teach the kids how to do it in and it's all very friendly and it's very easy to use and it's all based on
01:05:24
Speaker
Guys having one arm or two arms and maybe you can compose them together and do all the for loops and this kind of crap That's all great But then the problem is once you've got to the point where you've done your crochet pattern or you've done your Asia drawing Then where do you go next? You kind of don't go anywhere. You're screwed because those are just all like educational languages. They're not actually general-purpose languages and
01:05:49
Speaker
Anyway, maybe we can come on to what, because that leads us on to the fun part, because of course you're right, we want to get kids involved and I know Sam Aaron for instance, his whole thing is to try and make closure acceptable to children via music.
01:06:05
Speaker
you know, with this whole overtone stuff, and then the, on the Raspberry Pi as well, and Sonic Pi, yes, exactly. And I was actually, he did a presentation at that same Euroclosure, actually, and he's often at the conferences putting, using the REPL to play music, you know? And he was actually, he was telling me that he was, oh, he was telling me, he was telling everyone.
01:06:32
Speaker
So I felt like he was talking just to me.
01:06:37
Speaker
But he was telling everyone that he was doing a party or something. And he was coding it all in. And of course, the people see his text that he's typing and then listen to the music. And some guy comes up to him and says, oh, yeah, that's a really great special effect. You've got all those like the matrix type coding up there. He says, no, I'm coding it. That's how it's making the music. That's what's happening.
01:07:05
Speaker
I mean, that stuff is great. That's the sort of thing that I think you can give to kids and let them just have fun with, you know? Yeah. Anyway, I think we're running through, yeah, I think we're running out of time. So I'd like to wrap up. And thanks a lot, Mike, for joining us. And so where can people find you and open pull requests to you for Plank and other stuff? Oh.
01:07:34
Speaker
I think M Fikes or Mike Fikes. I don't have any special avatar or name. So if you're looking for me, just type in my name and you're crazy. Yeah, I'm that kind of a guy. Yeah, yeah. Because for me, it's always been, you know, especially if you hang out on IRC back in the days, and you remember by their IRC names, and then there were never real names. And I still don't remember the Lightning and Guy's name. I keep calling him Technomancy because that's what I know. Yeah, yeah.
01:08:01
Speaker
I'm just stuck with it. And as you can see that Timothy Hall, that Tommy Hall, I remember his Twitter avatar and that's weird looking, uh, O'Reilly creature. So it's, it's very difficult to put faces there. So, but yeah, so we can find you on, on Slack. Obviously I think you, you hang out on Clujerians on Slack. Yes, I do. Yeah. Yep. And I'm on Twitter as well. And I don't remember my IDs, but it's always Mike Fikes or whatever, you know, the same was possible. Yeah. You get on there first. To your projects.
01:08:32
Speaker
Yeah. So what is going to come up next time? So next time, I think we are planning to discuss one of the famous features of Closure, which is essentially the data types or the persistence collections. So we'll discuss, dig deeper into the core data structures that we have in Closure and then how they're built and what their features are and
01:08:54
Speaker
which one you need to pick when and obviously a bit of discussion about maps and records and structs etc. So I think we'll get into a bit more into the domain modeling as well. So that's I think the topic for the next time. Is there anything that I missed right?
01:09:11
Speaker
No, I think that's really good. Overwell, the only one thing we're going to talk about with the collections is the laziness aspect, because I think that's a very interesting aspect of functional programming. Anyway, like you say, we're pretty much done here now, so let's wrap up. We've got all the show notes, or we'll put all the show notes. By the time you listen to this, they'll all be there on the website, deafen.audio.
01:09:42
Speaker
We also have the MP3 on SoundCloud and that pushes the RSS feed through to iTunes, so that's all good. We haven't done all the credits properly in the past, so I want to do that now quickly. First of all, thanks to you, Mike. It's been a pleasure talking to you and how proud it is.
01:10:05
Speaker
Well, this is quite good for us, and we're three shows in, we're getting special guests already, so we feel honored to have you, actually, let's be honest. Of course. Thank you very much. It's been a real pleasure to talk to you. Yeah, thanks a lot. Thanks a lot, Mike, for joining us. And, of course, I think we should do some other episode as well, hopefully in the future when you release newer versions of it and you take it further with light speed. Oh, yeah. Sounds like a plan. That would be awesome.
01:10:32
Speaker
Alright, so one final credit is we should credit Pizzeri for the intro and outro music which is on his soundcloud. It's called Melon Hamburger. Thank you very much. Okay, so that's it. Goodbye everyone. Thanks very much. Goodbye.
01:11:18
Speaker
Bye!