Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
#34 - Mike Thompson aka @wazound
49 Plays7 years ago
Mike tells us how ClojureScript has finally steered him towards a decent replacement for Flash.
There are many pearls of wisdom from the reframe supremo including his insights on documentation and we could listen forever to his views on finite state machines.
More info and links over on https://defn.audio
Recommended
Transcript
00:00:15
Speaker
Welcome
Episode Introduction and Live Recording Attempt
00:00:16
Speaker
to Deaf and episode number 34. And this is the, I think this is the third episode that we're trying to do live. And this time we have Mike Thompson all the way from Australia and future on the show. Welcome to the, welcome to the podcast, Mike. Thank you very much. And there is also the other guy on the podcast. Can you please introduce yourself, sir?
00:00:44
Speaker
What, who, who, who's that? Well, yeah, it's a Ray Mondo here. And I've got my I've got my son in the background is the kind of usual distractions for the for the video people who, you know, rather than looking at our horrible faces is kind of, you know, they can watch the gaming guy in the background. Yeah. So
00:01:10
Speaker
Right. Anywhere. Let's get started.
Overcoming Technical Challenges in Australia
00:01:13
Speaker
So, Mike, finally, we figured out some of the technical stuff that you're using. Somehow things work differently in Australia than here. But at least we are live now and we are recording. We're live.
00:01:26
Speaker
Let's talk about stuff now.
The 'Holy Trinity' of Web Development
00:01:29
Speaker
First of all, Ray, you're talking about the Holy Trinity, right? Well, I figured it was Sunday, so let's start like that. Yeah, the Holy Trinity, yeah. Yeah, I don't know if I've kind of lost my motivation to speak about it now, but what the hell? We'll give it a try. So I was going to say that the Holy Trinity is like HTML, CSS, and JavaScript.
00:01:54
Speaker
And a lot of the stuff we're doing in kind of ClosureScript server side things is obviously mixing all of these things together because that's what React does and we're sitting on top of that. But there's a lot of charge, you know, blah, blah, blah in the community about whether or not all of these things belong together, whether we should be doing these spas. And I was trying to frame some of the discussion around whether or not, you know, we should think about spas or we should just like forget it and just say, okay, we're doing spas.
00:02:25
Speaker
single page applications. So let's just move on. So I think we can just edit all of this out, to be honest, because I don't think anyone really gives a shit. So I don't want to talk about it anymore. Sorry. We can talk. Let's talk. I use reframe. So let's talk about that instead. I use reframe, and I think it's pretty good. So that's why we've got mic on. So let's just dive into that instead.
Mike's Work with Reframe in Complex Applications
00:02:54
Speaker
Good. I know about that stuff. I'm not sure about the other stuff. No strong opinions really. How did you get into Reframe or how did you make that one? Maybe we need some historical context because there is a lot of good stuff coming out of Australia. Especially from you guys, you and Dan and everything.
00:03:18
Speaker
Before we get that, I mean, I saw a comment on Reddit. Somebody said, Dan and Mike are the nicest MFRs. I mean, I can't say that, but I think he meant in a nicest way. So they were very excited that you're going to be on this episode. Very nice of them. We do our best. So just give us some introduction. How did you get into closure? And then we'll get deeper into reframe.
00:03:47
Speaker
Yeah, OK, so I guess we got into closure. We've really got into closure script. We're really a closure script, sort of a shop more than a closure shop. And we do slightly unusual software. We're a company of about sort of six. And we do optimization work. And our software tends to sit on the side of another
00:04:17
Speaker
main reference system at our clients. And we do a bit of premium optimization work, and then we send some information back. So we don't do a lot of traditional web server related stuff. What we do is we have to gather a lot of complicated information from our users. Then we send it off to a back end cluster of machines, which do a whole lot of number crunching on it.
00:04:45
Speaker
And then we get an answer back and we need to display a pretty, a pretty sort of result, sometimes a complicated result for the user to have a bit of a look at. So we're not your traditional shop where we're kind of doing a relatively thin veneer at the front over a database at the backend. So we're slightly different in that sort of regard. So we were using probably starting in about 2004, 2005, we were using flex or flash sort of to do our front ends. And of course.
00:05:15
Speaker
That was a really sophisticated environment. You know, I still curse the day that sort of, you know, that, you know, that's died, really. But sort of that was a very sophisticated environment at a time when everybody else was using IE6. You know, we're in this absolutely marvelous world of flash where we had full animations and we had, you know, beautifully rendered fonts and sort of, you know, we're in this lovely in those days, they call them rich Internet applications.
Flash's Historical Context and Decline
00:05:43
Speaker
That was Adobe's point.
00:05:44
Speaker
So and incredibly sophisticated stuff. So I really cursed the day that it became apparent that Flash was sort of like just not going anywhere further. So I then started looking around for what are we going to do next? And there weren't that many possibilities at that time. At that time, there was JavaScript. And, you know, this is that horrible version of JavaScript which existed at one time. I know these days it's got lots of new features in it which make it much better. But
00:06:13
Speaker
Uh, it was, uh, we, we looked around, there was coffee script was actually a genuine alternative at that time. And the other alternative was dart. You know, I had a good long look at dart at one stage, um, because that had, um, a gila brasher in it. And that's someone that kind of was familiar with from the small talk days. So sort of had a good look and look at all of that. And in the end probably came around quite like the idea of closure script.
Transition to ClosureScript with React and Reagent
00:06:41
Speaker
That was kind of a really unusual left of field sort of choice. But, you know, we're holding off, holding off, holding off, and then suddenly React hit. And I saw Reagent and I went, oh, okay, that's it. We're going to go that way. So it was, I remember looking at ClosureScript and somebody was using ClosureScript to program Angular, for example. And I was just there. God, that just looks like the worst of all worlds to me. Here you are off in this small side technology called sort of ClosureScript at that time.
00:07:11
Speaker
And you're trying to use a JavaScript framework and it just looked an absolute mess. And then suddenly React was there and suddenly there was reagent over the top of it. And yeah, we were we were good to go. We kind of pulled the trigger and that was early 2014, I think. And after a bit of a search to try and find kind of what we wanted to do. Now, of course, there's lots of options. There's TypeScript and there's
00:07:37
Speaker
the rest. But back then there weren't really that many options and I just didn't want to do JavaScript and it just looked too painful.
00:07:45
Speaker
But it seems like, I remember some of the stuff from Flash and Flex a long time ago, and it seems like a bit of an apples to oranges comparison with ClosureScript, isn't it? Because Flash was more, what was it called again? ActionScript. ActionScript. Yeah, exactly. So it was ActionScript and Flex came later as a UI toolkit and everything. And we used Flex.
00:08:09
Speaker
So, I mean, the brilliant thing about Flex was you just got instantly good looking applications, like there was no styling concerns at a time, again, at a time when this is before Bootstrap came along. Right. So Bootstrap is given a generation of people and a program is an easy sort of look and feel. Right. Well, with Flex, you've got an instantly, you know, really very good look and feel. And we did a lot of complicated stuff in Flash and, you know,
00:08:37
Speaker
It worked very well for us. We've still got some systems running in Flash and soon they'll stop working because Chrome is going to withdraw support and all of that, but they're still pretty nice looking applications and they were possible to do in Flash. They were just impossible to do in the other web technologies at that time.
00:09:00
Speaker
I think it's it was obviously Apple that killed it, wasn't it? With the with the iPhone and the iPad and stuff like that. So, yeah, yes, it was a very nice portable desktop environment, like you say. Exactly. It commodified. Yeah. The reason why Jobs didn't like it, you know, he wrote a 3000 word essay ranting against Flash. And, you know, Steve Jobs never wrote 3000 word essays for any reason. He didn't have to write a 3000 word essay when he got rid of the
00:09:28
Speaker
You know, the floppy disk, for example, everyone just nodded, right? So he did that for his own reasons because Flash represented a commoditizing type of a platform that meant that he couldn't really have an Apple Store. So you can totally understand why he did it. There's an awful lot of people around who, you know,
00:09:48
Speaker
We'll sort of say he was doing it for altruistic purposes and all the rest of it. But anyway, yeah, he successfully killed it. But, you know, there was a lot of it had lots of security problems and, you know, because it was really developed pre security awareness, really. So, you know, in those early days, and I think it was all just too much to to get fixed.
00:10:11
Speaker
I mean, the other complaint was that it was a CPU hog. That was his big complaint. That's what he crucified it on, wasn't it? Whether that's actually true or not is open to debate, but that was the kind of central thesis that it just killed the computer, especially the mobile computer batteries and stuff like this. Yeah. Well, I must admit, I find Chrome kills my extremely powerful laptop.
00:10:36
Speaker
The next laptop I'm getting is going to have 32 gigs of RAM. I've currently got 16 and it isn't enough. That seems like a very interesting comment that he made that he's going to kill CPU and then we run Slack and that's going to take, I don't know, fucking 20 gigabytes of RAM and then it needs a cloud to run, you know, cluster to run. Just to have a chat application. Yeah. Yeah.
00:11:05
Speaker
Yeah, obviously CSS Grid is going to save us all. Yeah. Yeah. But compared to ActionScript, because ActionScript, if I remember correctly, it's so long ago, and I used to do that crap on macromedia days as well a bit before Adobe acquired them. ActionScript is much more object oriented, right? And then you see the rest of the things as there is a fundamental shift in the languages these days. So how do you feel the difference between ActionScript days and now ClosureScript?
00:11:34
Speaker
Oh, it's well, it's just a completely different paradigm. Yeah. Like, yeah, it's a completely different way of of of developing applications. I mean, with ActionScript, we would have an event backbone. And so everything was sort of subscribed to the events and and your produce events. And then there are all of these things listening for for effectively what was state changes or, you know, and everything you had a
Insights on Reframe Development and Signal Graphs
00:12:02
Speaker
know what it's like, object oriented systems, they're state everywhere. And it's all, it's all got to, it's all got to stay connected in some way. So everything's got to be listening to events. And then sort of knowing how to update themselves was kind of, you know, dividing up the behavior and the responsibility. But sort of, you know, I love what we've got these days. I really do. You know, I feel like I've been developing UIs for 35 years. And, and really, I feel like what we've got at the moment is, is, is as good as it's ever been. And I've, I've developed in
00:12:31
Speaker
small talk, albeit for not a huge amount of time, but, you know, I've seen all the best of the systems and it really does feel, at the moment, the combination of FigWheel and, you know, and, and CLJ DevTools and ClosureScript and React and, you know, Reagent and Reframe also, it just, it feels, it feels very good. But we do do slightly unusual applications, you know, in the sense that ours are very SPA-ish, you know, we don't talk to a server very often.
00:13:01
Speaker
you know, we might talk to a server once and then 15 minutes later, we might talk to the server again. And in the meantime, the application has done an awful lot just, you know, in its head without talking to the server. So I'm very aware that our applications are quite different to a lot of common applications where, you know, the application is very, the client is a thin layer, a thin veneer over the top of a remote database. So
00:13:30
Speaker
I'm very mindful we're different. I think that's why I developed Reframe the way that I did because of our bias in that way. Maybe we should just like, because we sometimes get like complaints about not introducing the tools properly that we're talking about. So like you say, you know, Reframe is the thing that you're famous for. So we should talk, we're definitely going to talk about that. But famous, yeah.
00:13:57
Speaker
You're extremely famous. For some measure of fame. You're extremely famous on this hemisphere. I mean, you should come here. I mean, people have this huge statues of you everywhere. No, no. I stay down here because no one knows me. I just would hate all that fame up there. You can walk on the streets without being mocked. Yeah, without being... Exactly.
00:14:18
Speaker
Exactly. And we genuflect towards birth every morning and evening and say our prayers and everything. But yeah, please, please tell us, how did Reframe come into the picture? What's the 10,000 foot view of Reframe? What's its purpose and what are we trying to achieve with Reframe? Okay. Well, I was saying before, first of all, we decided on ClosureScript.
00:14:46
Speaker
but couldn't quite commit because, you know, we saw ClojureScript being used by people who were using Angular, for example. And then all of a sudden there was reagent. And at the same time, at almost coincident time, there was om. And the two of those suddenly hit as layers over the top of reagent, over the top of React. And so I like reagent. And at the time,
00:15:12
Speaker
Uh, we knew that we just needed more, right? Uh, like we could see that what reagent was, but we also knew, you know, in a traditional SPA, you'd need a proper, proper MVC type of framework in an object-oriented world. Right. So we knew that it was just a view side of things. So we needed all the rest of the, where does the control logic go? Where does the, um, how to, you know, uh, all the wiring in the backend behind all the views. So.
00:15:41
Speaker
That's really what Reframe does. It just provides architecture, all the architecture that happens behind the views. We needed it for ourselves. We needed it for rather complicated applications. We've got full pivot tables that we've written and we've got scatter plots where you can scoop up
00:16:06
Speaker
scoop up points and put them in buckets and all that sort of stuff. So we write complicated front-end stuff and we needed a proper framework to handle all of that. And like I said, going back to the server very infrequently. And that's what Reframe was.
00:16:26
Speaker
So just a quickie on that one, I mean, cause all those kinds of kind of plots and all those visualizations traditionally in JavaScript have been done using D three. So what's your, do you use that or is that, we have swapped across to using Vega. We use Vega light or Vega and it's excellent. Like I really would recommend it to anyone that there's good reagent bindings for it. There's good bindings for like rum as well.
00:16:53
Speaker
Um, as far as I, yeah. And so, so what is Vega? Is it just a complete rewrite of that visualization? No, D3 is underneath Vega, but it's, uh, it's out of the interactive data labs IDL. I think it is same place. Have you ever heard of Tableau? Uh, yeah. Yeah. Yeah. So sort of, I think the, I'm going to get some of this detail wrong, but this is approximately right. Uh, the interactive data labs or whatever used to be at somewhere like Berkeley or Stanford or something. And.
00:17:23
Speaker
And a group spun out of there and formed Tableau and they retained strong relationships to this day, as I understand it. They've moved universities now though, to another university, but they've come up with this grammar of visualizations and it's, it's, it's terrific. You can do all of your basic, you know, plots and scatter plots and all the rest of it. But like one or two of the things that we've done recently are really sophisticated.
00:17:51
Speaker
And like, honestly, that'd just be a huge amount of work. And you've got to spend a good two or three days learning Vega. Vega especially is what it can be as complicated as you like, really. But once you've learned it, it's one of those Swiss Army knives that I reckon we'll be using for a long time to come. Always look for Swiss Army knife technologies.
00:18:12
Speaker
They do a lot of stuff for you. For the reframe, why specifically reagent? Because I remember first, I think the first one was OM, right? That linked React or that used React. And then we had ROM, we have Quizcent or something, and then we have many different types of things. So what is the reason why you picked reagent to build a framework around? Well, 2004, I think, I hope I get my dates right here,
00:18:42
Speaker
About mid 2003, I think, React came out and then suddenly at the beginning of 2004, like December, January, around Christmas of that swap over between 2003, 2004, we suddenly got three frameworks which were on-quiescent and reagent. They all came out.
00:19:02
Speaker
very close to one another in terms of time. And 2013 and 14, I think. Yeah. Just on that cusp, I think. Right. Okay. I hope I'm remembering. 2003. Oh, sorry. Sorry. Sorry. Yeah. 2013, 2014. You got those three all at once. And so that was the choice. You know, that was the choice I was faced with. So, um, I,
00:19:29
Speaker
I didn't like on and it was a very difficult time because like here I was a swapping across into the functional world and and I was feeling quite unsure about what was good and what was what wasn't and everyone was into on. And so it was a slightly harrowing time, actually, for me, because I was sitting there going, I don't like this cursor approach. You know, I can't organize my data in a tree the way that wants to me to do it.
00:19:55
Speaker
And I felt, you know, I, whereas I looked at reagent and I went, no, no, no, that's the way I want to do things. And yet everybody else who seemed to know what they were talking about was a cross on arm. And initially reagent got very, very little traction. Um, and yeah, like I said, I would keep on running back to arm and going, okay, I'm missing something. I haven't got this. Um, you know, I'm missing something. And, and in the end, I slowly convinced myself that I wasn't. And so we, we, we went with.
00:20:22
Speaker
Um, yeah, it was mostly the curses. I didn't like that concept at all because I felt that in a more complicated application, um, the actions that like curses are good for crud type of activity, you know, updates and, but the moment you get more sophisticated kind of intent from the user, um, you just, it's not a simple data update. Most of the time there's, there's logic that normally hangs him. Every time a user clicks a button, there's more than just the data up there. There's complicated logic that normally has to happen. So.
00:20:52
Speaker
It just never felt quite right for us. So anyway, so we got stuck into reagent, but realized we didn't have the framework that we needed. So started working on that. And so I think by the end of about 2014, just at the end of 2014, I started writing up what reframe would be. And like I said, it was real. I think my brain at the time felt like a washing machine because there was so many new concepts. There's so many new concepts that sort of, I felt like I was getting hit with.
00:21:19
Speaker
Um, you know, I looked into pedestal, um, pedestal app, um, yeah, the front end, which was, uh, kind of, that was all new.
Functional Reactive Programming and Reframe
00:21:27
Speaker
Um, there was also hop on, um, and, and, you know, I was pretty intrigued by the whole, um, uh, FRP side of that and, uh, uh, yeah. Um, and, and, and there was also Elm, which was happening, like there were these.
00:21:46
Speaker
The moment I saw Hoplon, it started talking about FRP. I followed through FRP, ended up looking at some games, because Elm at that time was mostly about games. And later on, the Elm architecture came along at pretty much the same time as Reframe came out. The two of them sort of came out coincidentally with each other. But there were a lot of good ideas in what I saw. So Hoplon and Elm were quite influential.
00:22:15
Speaker
Some of, I think, David Nolan's more advanced tutorial, I remember reading that and a penny dropped for me about the way that I kind of wanted reframe to be. So I don't know. There was lots and lots of influences and it's all just a washing machine, really. I was just hanging on to a log and trying to stay afloat there for a little while. Well, what do you think the fundamentals of FRP, you remember as we go into what FRP is and what you liked about it?
00:22:46
Speaker
Oh, okay. It's like functional reactive programming. Yeah, yeah. It appealed to me because that concept that the whole React concept that the user interface is simply a rendering of your state, your application state, and the transfer
00:23:15
Speaker
the successive derived views of the data in AppState all the way through to a UI getting rendered. That's obviously fundamental to React, but it just seemed like that whole dominoes effect and FRP seemed to fit into that. I don't have a neat explanation for why it appealed, but it was just part of the washing machine that was going on at that time. And it seemed there's something very right about it.
00:23:44
Speaker
And, and also reagent had built into it this notion of reactions, um, and, and kind of contexts in which if, if something changed, the context would reevaluate and which was very FRP ish. So suddenly we had the right tool, we had the right, uh, tool to use, um, uh, sorry, the right technology to implement FRP. It was right there in reagent. So it was just the right.
00:24:12
Speaker
a few ideas coming together with some existing technology. I wouldn't do it the same way if I was doing it again now, but at the time that felt pretty good and it's worked pretty well.
00:24:25
Speaker
Yeah. I mean, the thing about FRP to me is it's a little bit like these, like some of the functional technology in general, you know, that it all seemed a little bit impractical, you know, 20 years ago. But suddenly with all these like advances where React has this sort of DOM diff thing, these algorithms that make all of that kind of stuff very efficient.
00:24:51
Speaker
you can certainly focus on the kind of expressivity of your application rather than the mechanics of this update. It seems like they were giving us a real gift there, you know? A bit like the, yeah, I know. Yeah. Look, if you look at Reframe, there's really two parts to it, right? There's the
00:25:16
Speaker
How do we make stuff happen? The user's just clicked a button and we now need to figure out what's happening. And then there's all of this infrastructure that once we've figured out how the world should change as a result of that button getting pressed, there's the infrastructure associated with re-rendering the changed world for the user to have a look at. And it's just that boom, boom, boom, that lovely sort of one thing leads to another.
00:25:46
Speaker
There's something about that. I still can't put my finger on it. It's actually why it's just so pleasing. But having done UIs for like three and a half decades, there's something deeply, deeply pleasing about it that just brings a smile to my face. It just works really well. And I'd love one of these days to understand why exactly that is, but it's just so perfect.
00:26:13
Speaker
So the data flow stuff, because you're talking about there are two parts to reframe. One is the rendering thing and the other one. So I remember this whole one-directional data flow stuff, a one-directional thing, was coming from Ohm, I think, or at least the React kind of thinking. So can you give us some idea about how does this thing work? What exactly is unidirectional flow? Because there were some concepts of these things
00:26:39
Speaker
I remember reading from Pedestal as well. They had also similar kind of concepts. So what exactly we mean by unidirectional dataflow? Okay. Well, I guess unidirectional dataflow means that, well, actually during the Flex days, I had some experience with bindings, you know, because Flex allows you to have two-way bindings.
00:27:06
Speaker
uh, between a piece of state and something on screen. And so, you know, if, if the, uh, if the tick box is ticked, then suddenly the piece of state, which are the Boolean, which represents whether the state is ticked or not suddenly flicks on. And if equally, if you programmatically change that Boolean to a different value, then the tick box on the screen suddenly stops. Um, now that's a classic case of two-way binding, right? Because you've got.
00:27:35
Speaker
the state affecting the UI, and if somebody changes the UI, then suddenly the state changes. So that's a classic case of two-way binding. And for the small demo apps, that look really good. I still remember the Flex demo apps. That looked fantastic. The number of lines of code you didn't need to write, because all of that was just given to you. The moment you got out of nappies with that sort of stuff and started to build slightly bigger systems,
00:28:04
Speaker
Oh, that was a catastrophe. Right. And that's because, you know, the way that all the state got updated was non-deterministic. You know, this could happen this time. It might happen. This tick button might happen before or this tick box state might change before this other thing over here. And it was just it was horrible. You know, very quickly it got horrible. And so I knew that two-way binding, which is why it was anti-cursors. Right. Because that felt like two-way binding because of the flash sort of experience.
00:28:34
Speaker
Um, so the uni-directional, uh, sort of the uni-directional flow that, that was really flux, uh, which was one of the precursors to, um, or the, the Facebook guys talked a lot about uni-directional. I think that's where I picked it up from. And you're right. Also Pedestal had, had that in it as well, but it's like, um, you, you want a, you want a clear path, um,
00:29:03
Speaker
You want to make your interactions, you want to know what's going to happen one thing after the other. That's why the entire reframe tutorial is all framed as being, you know, a set of dominoes. One thing leading to the other and then to the next, leading to the next. It's very deterministic. You know exactly how every event is going to get handled. They're always done in the same boring way.
00:29:26
Speaker
in the same boring fashion. So you know exactly how it will happen this time and how it will happen at the time after. So you kind of take away the you know, any any any take away any any sense of of difference each time round. So it's always predictable. It's yeah, that's it. That's all right. That's what I'm trying to say. Yeah, it's exactly predictable. So
00:29:53
Speaker
Whereas the two-way binding, it was very non-deterministic. You never knew quite how one thing was going to cause an update to something else. So that's very definitely what we wanted. We wanted sort of like a set of dominoes, one hitting the other so you always knew what was going to happen next and what had happened before this to even cause this domino. And so you could break your system up into little parts and you know kind of where within the dominant set of dominoes they were.
00:30:21
Speaker
I think there's two parts to that flow as well. It's like the whole like talking back to servers and having the UI stuff. And then there's, cause I think that's more complicated, but then like what you're talking about at the moment is mostly just on the UI side, isn't it? Mostly like, you know, somebody makes a change to the UI.
00:30:41
Speaker
And now what happens is someone clicks that box. And like you said, you trigger a function, that function gets called. That may result in some new data in the database, which in Reframes case is some set of atoms or an atom. And then you have listeners, if I'm not wrong, you have listeners on that or subscribers on that atom.
00:31:07
Speaker
And all the subscribers are kind of automatically updated. And this is where it starts to get fun, I think, because you have a kind of like broadcast effect of all of these changes. So how does it stay predictable with that kind of broadcast?
00:31:26
Speaker
The, the, well, the broadcast, uh, I mean, reframe apps are 75% derived data, you know, so, uh, so because you have to view the user interface itself as derived data of the state. Um, so you've got your, what we call app DB, which is really application state. And then there, uh, that's the root of a tree.
00:31:48
Speaker
And then the, uh, the leaves of that tree are actually the, uh, the view functions that actually render HTML. So again, that sort of data is produced, um, right on the leaves and between the, uh, the root of the tree, which is app app DB and the views, there is, uh, this, uh, kind of, uh, signal graph. Um, and the signal graph basically takes data, which is stored within app DB.
00:32:16
Speaker
and progressively transforms it possibly through a few steps, sometimes just one step, from raw data stored in AppDB, which is kind of WeView as something of an in-memory database, is the kind of the view that we have of it. It's a series of material views, materialized views are made. And then finally, the UI itself is the ultimate materialized view. That's the ultimate expression of what data we currently have in AppDB.
00:32:46
Speaker
So all of that is just derived data. So, and, and, and that data flows through a signal graph and each node in the signal graph has a chance to modify it in some way. So we may take some items out of app DB. We may then sort them. We may then take particular elements out of, out of the maps in each of the items, um, to form our materialized view. And then ultimately there are view functions, which will turn those sorted items into.
00:33:14
Speaker
Uh, you know, nodes that appear on the, um, in the Dom. So 75% of a reframe app is really derived data. Um, if you include all the UI, which you should, because the UI is just more data that's hiccup. Um, yeah, so there's this, uh, flow of data through the signal graph and that's of course.
00:33:34
Speaker
I'm pretty deterministic. It sort of happens pretty much the same way every time. I think isn't it the basis that, I mean, we kind of forget it sometimes with Clojure and ClojureScript is that the reality is that in these other apps like Flex and JavaScript, we don't have immutability. Whereas with ClojureScript and we have this atoms and we do transactions on the data. So it's that immutability, that foundational stuff that gives us this predictability.
00:34:02
Speaker
Yeah, there's other aspects of reframe which help with that as well. So for example, when an event occurs, so if a button gets pressed, an event gets emitted. The handling of that event may cause some complicated changes to AppDB, the state of the application. But that state of the application is committed like in one transaction at the end. So we might change five different parts of AppDB.
00:34:28
Speaker
But almost like a commit with a database, the the the commit, the complete transaction happens in one step, because that's always what you hate in applications. And what happens in the object-oriented world, albeit, is that you start updating stuff throughout memory. And of course, you know, you get halfway through that process and you're in an intermediate state in some form, like I've done half of the changes, but not all of them yet.
00:34:54
Speaker
And so, that's what would happen a little bit with the two-way binding I was talking about before in something like Flex. Whereas luckily in our state, in our case, we make all the changes to AppDB, and it's only then that it gets committed, if you like, and it's only then that all the derived data actually gets calculated from that one-off, that transactional commit, if you like. So that tends to make things subtly easier as well.
00:35:22
Speaker
It's only a small thing, but if ever you've been bitten by systems that get into intermediate, kind of inconsistent states, it's just a small thing that's nice. Just removes one type of problem.
00:35:36
Speaker
This is, if you see the two-way binding thing, especially, because I think we skipped at least 20, 30 generations of JavaScript frameworks jumping from Flex to, I don't know, all the way until React. Because I remember, I used to follow this shit a lot, and it's Backbone, and before that, EXTJS, and then that became Sencha. And then there was SproutCore. I don't know if you have ever heard about that one. It's a name I remember, but I don't know anything about it. No.
00:36:05
Speaker
I remember looking at Backbone, I remember looking at Backbone at one time trying to maybe make the jump across to JavaScript at one point. Yeah, yeah. So I think there was like, first there was Yahoo UI XJS stuff, which looked like really Windows like components, like a grid component and stuff like that. And then later we had this Dojo, Dojo toolkit and then required JS and AMD modules and... UB tools.
00:36:31
Speaker
Yeah, exactly. And then there was so many things that moved along because especially that the 2A binding, I remember from, I think it was in Dojo and later Ember and Sprout Core as well because Sprout Core was, I think, one of the frameworks that Apple adopted for iCloud web stuff. And yeah, I mean, they first made the
00:36:52
Speaker
presentation software online. And then it was like, wow, amazing. I'm going to use sprout code now. And as you said, the applications, when the scale becomes bigger and bigger, it becomes completely unmanageable. It becomes so painful to see which shit is modifying what. Yeah. That's something.
00:37:13
Speaker
But it looks, it looks fantastic at small scale, like in your small demo. Exactly. Like there's so little code. Like where, where even is the code? Like there is no code. It's all just magic happening through all these bindings. It's magic. And then you try and scale it up and it's a disaster. Exactly. But what would you change if you're, if you're going to redo the reframe, so re-reframe. Oh, okay. What would be different? Uh, okay. So this is a little hard to describe, but it's like,
00:37:43
Speaker
You know how I sort of said that reframe is 75% derived data.
Reframe's Initial Implementation and Future Improvements
00:37:50
Speaker
At the moment, we have a signal graph that I was just talking about before. So data flows through the signal graph and we use reagents reactions underneath that. One of the things that I would change if I was doing it again, and it would be a change
00:38:07
Speaker
just in how we implement that, not the concepts. So to the program of the concepts would be the same, but just the way that I implemented that would be different. I just wouldn't use Java's reagents reactions anymore because that's actually a classic case of distributing your state all over the place. You get these little nodes, you end up with a graph with all these little nodes. I just wouldn't do it that way. Again, I'd do it in, I'd just do it in one place. I'd store it all in one place.
00:38:36
Speaker
and not distribute it with a number of little nodes all talking to each other. Because that's a classic little object-oriented system, right? That was a mistake. But it's just an implementation mistake. I can change that if ever I get round to it so that I don't make that one again. There's not a lot I would change. There are definitely things I would like to do better. I think in the do better area,
00:39:06
Speaker
I, one of the areas I don't think reframe does a good enough job is in, well, I'll probably call it higher order behaviors. You know, that's just there. What happens is a user clicks the button and then there's this, there's this, there's a whole lot of, there's a whole lot of behavior that has to occur that's often async, right? So you've got to go off and you've got to talk to the server and you've got to wait and you've got to put a twirly up and.
00:39:31
Speaker
You know, and maybe you might time out and then you've got to explain to the user that a timed out and ask them to, you know, do you want to hit another button and try again? Or do you want to abort this whole thing? And there's all of this sort of like stuff that has to happen. That's really very state machine-ish, you know, there's a little, you hit the button and you, and you just off into this little state machine. And like in Redux, they do it with Redux sagas. They try and do it with something called Redux sagas, which is they use, um,
00:39:58
Speaker
Now, my JavaScript is not that strong, but they use the generator of what in Python would have been generator functions and async and all of that sort of stuff. So they kind of write little state machines in JavaScript rather than representing the state machine in data, which is, I think, what we'd prefer to do. So as far as I can tell, well, anyway, I would like to have a better solution for that. That's for sure.
00:40:28
Speaker
It's you enter a little like everything in reframe is about events. Nothing happens without an event. But in these sort of cases, the user clicks on a button. That's an event. But then there's all these downstream events like, you know, we're OK. We've sent something to the server. The server's responded with a failure. Now we've got to handle that failure. There's a little.
00:40:51
Speaker
Um, yeah, there's a little state machine that you need to implement to actually do that. And I don't think reframe does a good enough job of that at the moment. So that's certainly something I'd like to improve on. The interesting thing is how to do it. Um, and, uh, I've kind of been looking, the state machine stuff really fascinates me a little bit. Uh, and there's something called behavior trees. I don't know if you've ever heard with them, but that's something that the gaming community uses to implement. Um, now I'm not a big gamer, so I don't, uh,
00:41:20
Speaker
NPEs, what are they called? Non-playing entities or something? Little bits of AI that run around the inside of the game, shooting you and trying to kill you and make your life difficult. Well, that's all done with state machines and that's done with behavior trees. Behavior trees are a very composable form of state machine. So I'm kind of intrigued by them. I don't know if they'll... I'm kind of intrigued by all the good stuff that the gaming community does.
00:41:47
Speaker
Like, I feel as if we're the poor cousins across in our world somehow. They've figured out this retain my graphic stuff years ago, and we've only just got React just a little while ago. They do so much good stuff over there. I feel like we should be stealing more of it. What are we doing? You know? Yeah. So you want to gameplay everything? Well, I want to take the best of the ideas. Yeah. No, I was pretty intrigued. They're very mutable, aren't they? They're into very mutable state, the gamers.
00:42:16
Speaker
Yeah, they certainly have been doing the retained mode graphics stuff, which is kind of like what React is sort of for the longest time. That's my understanding. I'm not a gaming developer, but sort of I get the impression that they're always about two steps ahead of us.
00:42:33
Speaker
Yeah. So the most important questions, I mean, we have two important questions, first of all. Before we move on to the important questions, I mean, you mentioned the, because there was a thing in Closure, in the ClosureScript community, maybe it's about a year ago.
00:42:51
Speaker
But some guy did, what do you call it? A state machine on top of reframe, actually. Yeah. From Cognitect. Yeah. I can't remember. I think it was just called Restate or something. There's been a couple of attempts at that. Okay. So here's the thing. I think that if you're going to go the state machine road,
00:43:14
Speaker
You have to go all in on, you have to come up with a very good and flexible state machine model. Like Harel, like I read all the background behind what he's done. And when you, like he was doing a lot of work in Israel with Defence Force, sort of in Defence Force contracting, as far as I can tell, working with, and they were trying to make an aeroplane. And they needed a way to represent, to model,
00:43:42
Speaker
the specifications for all of the avionics systems and they were struggling horribly. And so they got Harel to come in and he created, you know, the hierarchical, the hierarchical sort of state machines. You've got to do, and I think we just got to learn from here, all the state machine stuff that I've done, all that I've seen is kind of a fairly impoverished version of state machines. What he found is that you've got to have quite a rich
00:44:11
Speaker
model. So you've got to have history states. You've got to have you've got to have it hierarchical. Otherwise, you state machine stuff is not expressive enough. And, you know, the UIs very quickly, you want to end up with a UI where where you're using a state machine, but it's just not expressive enough. And and so you're out, you know, you're just busted at that point because you can't do what you need to do. You've got to somehow break out of the mold and, you know, you're gone at that point. So I think that
00:44:39
Speaker
If anyone does it, they've got to do they've got to be all in, you know, with all the features that Harel's already identified that you need to properly specify interesting behavior. So most of the attempts that I've seen so far have been limited, you know. So yeah, I've seen that stuff come past. I'm pretty interested in it.
00:45:01
Speaker
We did something called Reframe Async Flow, which was we had a problem which was when our application started up. When our app started, you go through this little state machine at the beginning of your app.
00:45:16
Speaker
where you, you know, you, you connect with the backend and, and you get something and then you're off to an S3 bucket and on the basis of that and you, you know, you load something else. So there's this boom, boom, boom, boom process that, and of course you could get failure at any point and you want to fire off these two things. Once this, this thing is completed, it's all the async stuff. And that's a little state machine as well. So I'm kind of fascinated by the whole, um, how do we, it feels like the next layer of reframe should be something about,
00:45:45
Speaker
properly
State Machines in UI Development
00:45:46
Speaker
doing state machines. And I've seen a couple of people try. And that's why I've looked at behavior trees. If anyone wants to do something with behavior trees, I reckon they look pretty good to me. That's very composable. Represent them in data. Part of the problem with state machines is they're not very composable. That's what I mean. It feels like there's something good there, but I don't know yet quite what it is. I'd love to have a good solution for that.
00:46:11
Speaker
That's not really what I do differently with Reframe. It's what I do next, I think, whenever I get time. We spend all of our time on Reframe 10x. It will make you a 10x programmer. Oh, wow. That's our claim. The ugly secret, though, is, of course, that the 10x programmer then becomes 100x.
00:46:34
Speaker
So, you know, you don't catch up, but... So the most important question, you know, the question of every episode. So do you use Emacs or some other shit? This is kind of a strange thing to ask, you know, like people from Australia. Look, I spend most of my time writing PowerPoint slides or responding to emails.
00:46:59
Speaker
Or... You can do that in Emacs, by the way. So, no, we use cursive.
00:47:07
Speaker
Yeah, I'm sorry. I think it's, I'm pretty sure Colin is bribing you. He's in Australia. Well, no, don't say that. He's in New Zealand. He'll hate you forever. He'll hate you forever for that. Even more. It's too far for us, so it's all extracted away. Yeah, I know. We're just an abstract blob on the opposite side of the world, aren't we? An undifferentiated set of islands.
00:47:34
Speaker
No, Daniel, by the way, is also in New Zealand. Yeah, we spoke to him as well. So the other question is, so which came first, the documentation or the code for reframe? Because this is the biggest thing ever. They both came along together. I kind of realized, like I said, my brain is a bit of a washing machine at one time. I kind of, there are all these ideas floating around and banging into each other. So I had to get them down onto paper.
00:48:02
Speaker
And I had to explain them what I was thinking to the guys in the team as well. So I just, you know, it started off as kind of bullet points. And then it, you know, you know, this paragraph got a bit fleshed out, and that paragraph got more fleshed out and, you know, asked some questions. And I thought, Oh, yeah, that's a good point. I better, I should explain that. So
00:48:23
Speaker
But because it was it was all intended really to be internal, so I could be as cheeky as I liked in it. So and also like I was having a good time, like I really was having a good time, like I'm talking about it being a bit of a washing machine, but it was it was a very stimulating, fun time sort of trying to pull all this stuff together. So that kind of came through in the way that I was talking about it. You know, I was just having fun with it all. And it just slowly, it just got bigger and
00:48:51
Speaker
bigger and ended up way too many words. And I think Eric, Eric Norman called it eccentric. So, yeah, I felt like an English gent who wore sort of purple, purple, purple suits who had a fascination with Amazonian sort of butterflies or something. But anyway, yeah, we calmed it down after that. But yeah, it was look,
00:49:20
Speaker
I'm doing it at the moment. I'm writing down stuff that I want to change with Reframe. I find that I have to get stuff out of my head and down onto paper so I can think of other thoughts, you know, get it out of my head down there right now. I got that down there. Now I can have other thoughts. So and the clearer I can write it, the clearer I understand it. And so it's very much a selfish exercise for myself as much as anything else. So, yeah.
00:49:46
Speaker
It all happened at the same time. One didn't come before the other. Well, I think people really like your informal style, you know? My eccentric style. Like you said, it's a bit cheeky, but yeah, but I think it's really, yeah, I think it really engages people. So, yeah, I think you've done a great job there. You know, trying to have a sense of humor with technical documentation is risky, I think. Scott Adams, the guy who does Dilbert, right?
00:50:13
Speaker
He I read a piece of his once where he said that at least 25 percent of the population don't have a sense of humor. And I genuinely mean that that they can see other people laughing. But for them, it's it's not funny. And like the reframe docs, there's all this stuff in there that they would experience as just annoying roadblocks. You know, now what's he doing? You know, and so, you know, what's he crapping on about with now? You know,
00:50:42
Speaker
So there's at least 25 percent of the population for whom that serves. It's it's an nuisance. Right. And then there's probably another 40 percent of the population who who kind of do have a sense of humor, but it's mostly about awkward social moments. You know, and then to the Venn diagram. Yeah. Yeah. So this is this is Scott Adams theory and I tend to agree with that.
00:51:07
Speaker
And so your audience, if you're trying to do any smart ass humor, is sort of like sort of, you know, at best about 40 percent of the population who will actually appreciate it. But you get survivor bias. So with something like Reframe, you know, 40 percent of the population didn't mind it. And as a result, they hung around and told me it was great. What I didn't see was the other 60 percent of the population that just went, this is a load of crap and I'm not reading anymore. I never saw them and I never heard from them again.
00:51:36
Speaker
I don't think anybody got to the point until they're going to ask for a t-shirt, you know, when people get up. And I was wondering, maybe there should be like, you know, on GitHub, there's this raw and then the diff mode and this kind of stuff. So there should be like a switch on the top that should say, you know, with humor and then maybe a slider, like how much amount of humor do you want? And the documentation has.
00:51:59
Speaker
Yeah, you see exactly 40 percent. Actually, I sit in the 40 percent generally. I quite enjoy the smart alec humor because it gives me a bit of novelty and I kind of like that in my technical documentation. But I totally get that people like there's there's just other people for him. It's nothing but a pain in the neck and I'm sorry. But but I'm not going to change. I do it for my own enjoyment. So yeah, exactly. Yeah.
00:52:25
Speaker
Anyway, so reframe 10x, you said reframe 10x will make me a 10 times programmer, but I'm at zero. So probably, you know, regardless of what multiplier is going to be, I'll still be at zero. What is reframe 10x? Yeah. Okay. So we've been working around this for a while, probably about 18 months actually, but it stalled for a long time. And then
Introduction to Reframe 10x
00:52:45
Speaker
last year, Daniel organized
00:52:49
Speaker
Uh, well, Daniel, I'm not sure exactly how it worked, but sort of, we had Ruby girl, two Ruby girls who were sponsored and they chose to work on, um, a, on reframe 10 X. They put up a proposal that got accepted. Um, yeah. Uh, Christian Saskia worked on it for two, uh, for about three months. Uh, they had a bunch of, uh, they're in Berlin. There's a, it's a hot bed of reframe activity in Berlin. I've decided.
00:53:18
Speaker
It always seems to be reframing things going on over there. I'm going to go there one day and maybe I will be famous over there. Not here, but over there maybe. So there's, yeah, they did that and that kind of, they solved a problem which had sort of been hanging around, which we hadn't solved, which was how to use, you know, CLJS DevTools.
00:53:42
Speaker
Absolutely wonderful tool. Like we should thank Darwin every single day for creating that tool. They found a way of taking his, they and their mentors in Berlin, how to just get that into reagent, basically, so that we could use all the work that Darwin had done. And my goodness, he's done a lot of work on
00:54:08
Speaker
how to show data structures. So that was a real breakthrough because we kind of wanted that for a little while and they managed to make that happen. So we then sort of put our foot on the accelerator and did a bunch of other things. And we probably spent way too much time in the last six months doing it. You know, programmers will spend way too much time on tools for themselves. Like they just like that. So.
00:54:32
Speaker
Uh, there's something pleasurable about knowing your target market and, and, uh, and Daniel's done a lot of, I think great. Well, I keep on telling him, he's doing the most interesting job enclosure at the moment. Um, he doesn't believe me, but, uh, uh, it just, we we're doing form by form tracing of closure script work. And, uh, so.
00:55:01
Speaker
When an event handler runs, you can use a macro that Daniel's written and it will give you form by form tracing of that. Like, and I went back and had a look at light table, probably about, uh, probably about three months, uh, two months ago, just to have a look at how it did things. You know, we're looking for inspiration and, um, and we realized that we're doing.
00:55:25
Speaker
a much better job than light table. You know, what we were showing light table, my memory of light table was that it was absolutely breathtaking. And kind of when I went back to it and had a look at Instareples, which by the way, they've now removed. So I had to find how Instareples worked, you know, with old YouTube videos. But like you really only got let bindings and you got ARGs and you got final values.
00:55:48
Speaker
And yet what Daniel's managed to do is he's actually managed to get formed by form tracing and we kind of show it with indentation in a particular way. I don't know. I love it. You know, like when you, it's certainly got some sharp edges still. Like don't give it a big loop. That could blow it up, but sort of, it feels like it's just a good basis for some good stuff. Mind you, we run out of.
00:56:11
Speaker
time now to work on it. Really got to go and do some work that we get paid for. But it's been it's been fun. And I think it's a I feel it feels like something really useful.
00:56:21
Speaker
So, um, yeah, I think it is because we had, um, we wanted to close your D in Berlin. As you said, Berlin is probably the, you know, probably conclave of a reagent now inside Germany, Australia, probably on New Zealand. So, uh, I think, um, it was a Saskia or somebody she gave a quick talk about, uh, about that one. Saskia was, uh, one of the Ruby girls, one of the two Ruby girls I said before Chris and Saskia, they both worked on it in, in, in Berlin. And, uh, yeah, yeah, they cracked this little problem.
00:56:51
Speaker
and we've run with it since then and done a lot of work, a lot of styling. Greg, who also works at DayAt, he's done a lot of work on the styling, so it looks pretty and it does quite an interesting job. We're gonna sit back and actually use our own tool now for a while and just sort of see what we learn from it because you have all these good ideas, right? Oh, we need this, oh, we need that, but it's only really use, which will knock the edges off it and produce a better tool.
00:57:20
Speaker
But we think it's something people should try. Yeah, I think it's one of the nicest tools. I mean, I haven't tried it yet, but I saw the demos and everything and I saw the talk by Saskia as well. It was super fun. So what is the, so you work at day eight. I mean, is it like a consulting company? No, no, it's my little company. We've got about six people in it, six developers and
00:57:46
Speaker
We've, uh, I've probably been in the advertising industry in the, uh, for 20 years. And, uh, what like madman off Australia. No, no, no. I sorry. It's not me. That's in our software is in the advertising industry, but in particular into how do you place ads on TV? So we do the optimization sort of stuff around that. So we've got a very, very particular niche that we work in with TV networks and with advertising agencies. Yeah.
00:58:14
Speaker
But one of the one of the things is that especially because it's your own company, how did you how did you feel when you're picking up a language like Closure where you're probably the only guy in Australia at that time who is doing Closure or maybe two other people? There's actually a pretty good Closure meetup actually in Sydney and there's one down in Melbourne and Daniel used to run the one in Auckland in New Zealand. So
00:58:42
Speaker
There's a bit going on with closure and it's not huge, but there's a bit. There's always about 20 along to the meetup in Sydney. It's growing. It's very slightly, but sort of it's definitely bigger than what it was a couple of years ago. So yeah, like I said, it was, we had to make a change because we had to get out of flash and it was just the best option. I mean, and I, I, I, I,
00:59:10
Speaker
I'm convinced I haven't seen anything that looks better. Let me put it that way. I like I would I would change in a flash on. I'm too old to get too connected to too many technologies and too attached to them. I've seen them all come and go. So I would change in a flash if I thought there was something better. And I feel like closure script for a front end work is is a really good solution at the moment. It's in a good place. We feel very productive.
00:59:35
Speaker
So there has been some discussions recently, of course, on the podcast and also on the internet about the whole error messages stuff and specs and, you know, closure being extremely painful for the beginners and, you know, all that stuff. So, so what is your experience has been on this one? Well, remember that I care more about PowerPoint presentation error messages than closure messages, but sort of, uh, no, uh, yeah, look, it's, it's, it's, um,
Challenges for New Clojure Developers
01:00:06
Speaker
It'll be good if it was better. Um, it'll be good if there was more focus on it. Uh, but look, there'll be reasons for it. I, you know, I'm unaware of them. It's a funny thing, isn't it? There's, there's a, um, there's, there's, there's, there's definitely a split between where if, if you're doing a lot of development enclosure, you're effectively betting your career to some degree on closure.
01:00:35
Speaker
And as a result, you care about the community growing. You know, and I've got a company, you know, we've, you know, we'd like to, if we needed more closure people, we'd like to be able to find them. So it matters to us whether there's a strong closure community. And I think that anything that we can do to improve that is a good thing and getting people like, so
01:01:04
Speaker
I'm not sure that's Cognitex point of view, though. I mean, I don't know anyone from Cognitex, so I am speculating wildly, but they certainly have an agenda and I'm sure that it makes utter sense to them. You know, it'll be around Atomic and, you know, all of that. So that makes perfect sense. But I'm not sure it's that well aligned to the rest of the community in terms of
01:01:29
Speaker
Everybody else just wants closure to work. You know, we want it bigger. You know, we want more smart people in it doing more interesting things. Thanks very much. Because that's generally a good thing. You know, generally, that's a good thing. And it really matters how difficult it is. It really matters your initial experiences of anything.
01:01:47
Speaker
really matters, right? Always. I remember I got into Python at one time because, you know, one afternoon I thought I'd try Python and then like within two hours I was coding away and I've never looked back. You know, Python is one of the best languages I've ever used, but it's like that was because the onboarding process with Python was just so delightful. You know, the documentation was extraordinarily good. I could start off at a very simple level and in no time I was up and running and it was like a
01:02:17
Speaker
You know, it was like heroin. You know, I was into it and I was away. Are you recovering, Mike? So my parents kept on telling me anyway. They kept on warning me about these things and Python was it for me. Kids, don't do it anyway. I did Python instead and look where I am now.
01:02:44
Speaker
No, the it was. Yeah, so it was very easy to get going. There was no road bumps. And suddenly I was producing perfectly good program. So, yeah, and we'd all like that sort of for closure as well, really. And yeah, what can you say? It's it's it keeps on coming up, doesn't it, as an issue? Yeah, yeah.
01:03:06
Speaker
I mean, the thing that Vijay mentioned there was spec. I was wondering if you have a place for spec in reframe, Mike. Oh, I think so. It's going to be something I think that as far as you want something. Yeah. Yeah, definitely. We already use spec. I think if you're using reframe, you should have a spec for what's in AppDB because the instant that something that an event handler changes AppDB in a way that doesn't match the spec,
01:03:34
Speaker
You should know immediately when you're doing your development work. So yeah, spec specking app DB is absolute. We do that. We've got specs for app DB. There's a thought that maybe you might want to spec also what's in an event, you know, but I've wondered about that on occasions, but sort of, I don't know. I never been too motivated down that path. Events tend to be very simple things. So, you know, I'm always cautious.
01:04:03
Speaker
about adding a lot of code, like I don't, for example, unit test any, any view code. I sort of, I say that in the doc somewhere that sort of, I don't, I don't unit test view code because they're an unlikely source of bugs in my experience, right? Whereas event handlers, that's where your bugs are going to happen, right? So you want to, you want, they'd like you to screw up app DB in some way that you never thought of, right? So good idea to have a spec to check app DB.
01:04:33
Speaker
But, you know, do you really need specs for events? I dunno, probably maybe I've thought about that, but maybe not. You can also spec the output of subscription nodes, you know, possibly that's probably more sensible in my opinion. Cause that can, you're doing some, you know, some, sometimes you're doing complicated transformations on what's coming out of app DB. You can get that wrong, but, uh, yeah, I think right now you can use spec.
01:05:01
Speaker
So coming from coming from Python, you said, you know, Python, you really like that language. So what do you miss in enclosure compared to triple, triple quoted strings? OK, just so you're going to write a macro for that one now. No, no, no, no, because we're triple quoted, quoted strings from Python. You don't need to backslash, you know, double quotes everywhere, which means that suddenly you're
01:05:27
Speaker
Your doc strings are so much more readable. They haven't got all of this, you know, meta black backstash stuff in them. And that drives me bananas. That just feels like, I understand the reason. The reason is that there's a potential for a, for a, a backwards compatibility problem, because if two strings had been put one right next, no double. Oh, I can't remember. There's some obscure situation where introducing triple-quoted screen strings now might cause a problem.
01:05:56
Speaker
I'd do it in a flash. If I was Mr. Hickey, I would do it in a flash. But this is all coming from Pearl here, Doc stuff, right? I mean, this is a long time ago, but probably Python carried it over, and it was never Lisp, sort of. Isn't there a Java proposal now to do something exactly like that? I think only string interpolation, as I remember, not triple-coded stuff. To have the same effect where you embed quotes inside of your quotes.
01:06:25
Speaker
inside of your strings. Anyway, it doesn't matter. But yeah, you're right. That's interesting. That is the only thing you miss from Python. It's the first thing that comes to mind. What else do I miss? The thing you notice about Python is just the size of the library, there's so much available to you. Anything you want to do, there's a library for it. And it's normally a top-quality library that's just fantastic.
01:06:55
Speaker
You know, you look at it and go, wow, you know, there's man years of effort that's gone into this. And I just, it's well-documented. It's, you know, I just pick it up and I use it and it's, um, and we're away. That's was my experience with Python. It's,
Python's Success and Usability
01:07:08
Speaker
um, anything I ever wanted to do, there was a library for it. So, um, yeah, I think it's also, it's a very pragmatic language, Python. I mean, so, so I think that closure is too, by the way, but sort of, uh, it's a very pragmatic language. It's kind of object oriented. It's a bit, you know,
01:07:23
Speaker
It's certainly got plenty of functional to it. It's it's a it's a very pragmatic language. I am very easy to do good things in it. You know, I know what you sometimes find is you see people bagging out PHP or something like that, right?
01:07:42
Speaker
But if you've done good work in a language like let's say you'd put out a nice system based upon PHP, you won't have a bar of it like this book. I'm a bit like that with C++. Like I did a decade of C++ and I hate it when people criticize C++ because I go, I think I did some of my finest work in C++, you know, doing really, you know, the browser that we're attempting to use is written in C++. So once you've done good work in a language, you kind of you don't want to hear any.
01:08:12
Speaker
You don't brook much criticism of it because you've seen it work well for you.
01:08:18
Speaker
Anyway, so apart from reframe, so there are other efforts like this going on to make like a kind of a framework around these things, like full-flow, for example. Did you take a look at them? What do you think of them? I haven't. I should. I should go over, have a look and steal all the good bits that I can find. No doubt. It's actually slack on my part that I haven't gone across there and seen what they're doing really well.
01:08:47
Speaker
I get the impression Forecrow is much more of a front-end connected to back-end thing. Like, you know. Yeah, it's a whole stack of stuff, yeah. So, which is, you know, which will be perfect for some people, you know. No, I don't know too much about it, though, sadly. But the back-end stuff, what kind of things that you use for the back-end, is it usually something that is under your design control? Yes, yeah.
01:09:16
Speaker
We use a sort of, our intention is to use, because we're getting into this a lot more, is CQRS-ish type of approach, which is very reframish, right? You send a command. It's not restful. You send a command, you interpret the command on the server, and then you kind of effectively have subscriptions as well, sort of, really, to get data out.
01:09:43
Speaker
We were using Rethink DB at one stage. Unfortunately, that fell over. Yeah. Yeah, that's gone. Yeah. Yeah. Well, not fully though, I think. No, not joint. They have their own organization. Yeah. That's right. Yeah. Yeah. No, we kind of really liked that idea of being able to get real time updates out of the backend into the front end. It kind of, because we're writing distributed systems, right? And you know, the clients have to be connected to the backend and
01:10:11
Speaker
You know, they're all part of this one great big system and that real-time flow of information, we abused that. That was great. I love that. Our design sort of like, it just, there is just some problems that just get so nicely solved with having that capability. But unfortunately, I think that's really, I mean, we're still using it, you know, in the backend, but, you know, it'll be
01:10:36
Speaker
And it's actually completely functional as it is right now, RethinkDB. But there's no further development really that's ever going to happen on it. So, you know, come five years from now, it'll be really showing its age. Yeah. But, you know, much more, you know, Postgres-y these days and CQRS and Postgres and yeah. Nice.
01:11:00
Speaker
But aren't there things like CouchDB which would give you those kind of things, Mike? I seem to remember looking at CouchDB at one stage. Wouldn't there are some problems with data integrity on CouchDB or am I getting mixed up with Mongo? No, it's Mongo. It's Mongo, isn't it? Yeah. It's always Mongo. Yeah. I'm sorry. Well, I think the poor guys who did RethinkDB, they cared a lot about data integrity.
01:11:29
Speaker
There was Mongo just screaming along and getting 10 million dollars worth of funding and screwing up databases. I mean, I'm probably being too harsh on Mongo, but you know what I mean? It's like actually, that's another very good example of people just got into Mongo and it seemed easy and they just got going.
01:11:46
Speaker
You know, this is the Python story I was talking about before. And then before you know it, they're kind of invested and they're committed. And it doesn't matter about data integrity anymore. And and off they go. So, yeah, that's what happens when you give people, you know, a fast path in that they.
01:12:03
Speaker
I think this is the worst is better sort of situation, I think. Once you get in, you know, you have to... That's true heroin, that is. That is. That's the path in heroin path, yeah. Yeah, I think the thing about Mongo, I think, I mean, I probably, I haven't used it for a little while and it's probably, probably like you say, it's probably better now. But I remember the early days of Mongo, when they didn't used to use F-Sync, you know, so...
01:12:28
Speaker
They used to, used to take a commit from you, but they didn't actually commit it to the file system. Yeah. Why? Well, because fsync makes it a lot slower. So I know they fixed that now. So, you know, yeah, I know that we're being far too harsh on MongoDB, too. So, oh, yeah.
01:12:49
Speaker
There'll be people out there. And so to say, you know what you were saying about PHP before? Well, guess what? I've written. I've written good systems using MongoDB and I don't need to hear you criticize it. Yeah. Yeah. No, I've used it myself. Yeah. And it's fine. Yeah. So maybe it was just fun at the beginning. Instead of rethink DB, there's Firebase. There's a new Google Firebase database out because the original one was a very limited sort of hierarchical model that
01:13:19
Speaker
You know, it was limited, right? Whereas the new one looks much more fully featured. You can query, do better queries and indexes and all that sort of stuff. That could be an interesting path too.
01:13:31
Speaker
Yeah, yeah. And you're probably more, probably gonna last a bit longer if it's under Google's supervision. Yeah, that's, of course, like, I know, like Google Plus, like, you know. Yeah, Google Wave. Do you remember the days, do you remember the days not that long ago when there was Google IO would happen?
01:13:50
Speaker
And it's like you were sitting on the edge of your seat waiting to hear what came out. This is maybe seven years ago now. Who can remember the last Google IO? I don't know. I didn't see it. I didn't watch it. And even the Apple, you know, the Apple events, you know, sitting on the edge of your seat waiting. We don't have those events anymore.
01:14:09
Speaker
No. I mean, we do, but people, I think... We have the conge now. Well, I was about to say, we have Rich Hickey's keynote to look forward to. Yeah, exactly. No, it's all Rich Hickey. Yeah, I put my, like, I have to tell you, the last conge, the videos came up and I saw that the Rich Hickey
01:14:30
Speaker
Um, uh, his keynote was up and I went, right. It's, it's pointless to resist not procrastinating and watching that. Right. So I will, I now must watch that. I went and got myself a cup of tea, came back, sat down. And I remember just noticing my sense of.
01:14:45
Speaker
satisfaction and enjoyment for what was about to happen. I didn't know what he was talking about. Yeah. But I just knew it was going to be good. And of course it was. But sort of. Yeah. Yeah. That's you're right. That's the new Google IO for us. Yeah. Yeah. I mean, I'm wondering next time Richiki comes on and says it's completely mundane stuff like, you know what, you're all sitting. I was like, oh, my God, my mind is blown out. I am. I am. I am sitting now. Oh, this is amazing.
01:15:15
Speaker
But anyway, there were some interesting things, but I think the last talk that I saw was about the music and other stuff. And then he was like, he started it like, I know you guys are expecting, I'm going to reveal something magical, but I'm going to talk about music. The last conch one was the one where he gave all the layers of what's actually hard. And that was such a good talk. As an older programmer,
01:15:40
Speaker
I loved what he said there. That was, you know, solving that intricate solving of puzzles that you see in Scala and Haskell or whatever. It's so true.
01:15:49
Speaker
Yeah, yeah. Well, I liked about that, though, was the fact that he or it seemed like the people were concerned about that, that it's all these old guys that are doing closure now. And it's all you know, that was quite I mean, the funny thing is that I think there's something to that. But, you know, because we're all kind of let's say, you know, mature gentlemen on the podcast here. But the but when we went to the Berlin closure D,
01:16:15
Speaker
It was very, very young, very youthful. You know, it was nice to see that there's actually there's a lot of generations interested in closure.
Journey Through Programming Languages
01:16:23
Speaker
This is not just for, you know, wizened sort of like skeptical, hardened old kind of programmers as well. Did what can I ask? Well, actually, I'll tell you my, my, my process of actually becoming interested in this was really, I mean, I did it all the way back in uni. I remember we did a
01:16:42
Speaker
a course on snowball list and comparative comparative it was one semester and it was kind of comparative languages or something we did snowball this and.
01:16:55
Speaker
Oh, there was some other language. Can't remember. And so that was my introduction. And back in, back in, no, Fortran was a staple back then, you know, these were the weird languages, right? Snowball and. And, uh, and then I don't think I really, I, that next time I heard about lists was really with Celos. I went to, uh, an object oriented conference in, you know, uh, one of the, uh, conferences years ago.
01:17:18
Speaker
And there was somebody up the front talking about sea loss. And I remember like trying it. And then, um, and really the next time I heard about lists, seriously, other than just whispers here and there was, uh, probably the Paul Graham stuff. You know, Harry wrote all of those, uh, essays and they were very influential. I've spoken to lots of people really. And I get the feeling a lot of people came, became quite interested in closure because, well, this been general because of those particular.
01:17:45
Speaker
Essays, does that match your experience at all? I'm not sure because there was, I saw Lisp almost 10 years ago now, I think. Because when I started programming, obviously I'm not as experienced as you guys are. But I started with C and then I did all the 3D stuff and macro media crap and that kind of stuff and then C++. And then later I got into Java.
01:18:13
Speaker
I think the Lisp stuff because of practical common list book that I started reading by SIBO a long time ago. And then during that time because I was heavily invested in Java and then I was wondering, okay, is there something on Java? At that time, I think there was also Shen on Java and then there were a couple of other experiments running on JVM.
01:18:33
Speaker
to write lisp and then I saw in 2008 or something I saw closure as well then I did completely weird shit like writing wicket you know Apache wicket like a web framework plugins in closure for some weird reason don't don't ask you survived
01:18:54
Speaker
Yeah, yeah. And then I moved on, and then I started continuing pursuing Closure a bit. But yeah, I think one of the influential things was also the programs, things about on Lisp and why Lisp is a better programming language and that kind of stuff. Yeah. Yeah. I don't know how Ray got into it. Well, I mean, for me, it was more like I didn't know Lisp at all, and I didn't. I actually ended up getting into Lisp because, bizarrely, because of Scala.
01:19:22
Speaker
because I went to a conference. I saw the Scarlet guy talk at some conference and I thought, yeah, that looks like the FP. This looks like the way, you know. There's a lot of magic going on in Scarlet and he was talking about the compiler, how you can have one part of a compiler if I be written the other part.
01:19:43
Speaker
It all seemed quite tricky, but then he was explaining some nice things about how they can handle collections and stuff like this. So actually, I tried with Scala first, and then I realized that Scala was too complicated. And I ended up looking, I ended up watching, bizarrely, I ended up watching some sort of YouTube stuff around Scheme and following the MIT course on Scheme. And then I eventually found this, the other one, the SICP YouTube course.
01:20:12
Speaker
And the whole Paul Graham stuff, it just passed me by, to be honest. I was into Java and Scala, all the VM stuff. And then eventually, after Scala, I realized that I was listening to some podcasts. And actually, it was an Australian podcast. I can't remember what it was now, but they were talking about how much easier closure was than Scala.
01:20:33
Speaker
So I thought, oh, what's this about then? So it was all very tangential. It's not a straight road, unfortunately. Yeah, I was learning Scala just because I felt that whole learning new language every second year thing. I was learning Scala and I was about a month into it and I just sort of went, oh, I'm just not interested in this. This is too hard. Like my problems are hard. I don't want my language to be hard.
01:20:57
Speaker
So which is exactly what Rich Hickey was talking about before I had that direct experience where it's just sort of they're going, no, I'm just I'm just not going to devote this much of my brain to my language. You know, I have to devote it to my problem. So, yeah. And then at the same time, I read something that a scholar person was saying, yeah, I love Scarlett. You know, I spend three days coming up with a perfect solution.
01:21:19
Speaker
And then towards the end, he, the person, this person who was a scholar programmer said, mind you, the closure programmer, they got out of there in just under an hour and their solution was just fine. And I went, now that language sounds like me. I wonder what that is. I mean intrinsically a bit lazy. So I want that one hour job, you know, not the three days of intricate beauty.
01:21:39
Speaker
So yeah, that's how I ended up. Fair enough. OK, I think we have almost one and a half hour, eight minutes to go. So Mike, anything else you want to talk about other than whatever the stuff that we spoke for almost one and a half hour now?
Supporting Closure Initiatives
01:21:59
Speaker
Probably we were talking before about community before, so Daniel's been doing a lot of work with closure us together. And I think that closure us together, that feels like an important thing. And in particular, I think they've got some companies involved, but.
01:22:17
Speaker
Really for anyone listening, I think that you've got to get, it's all very good for you to be involved, but really you've got to get the companies involved because the companies have the deeper pockets, you know, $500 a month or whatever sort of a fee it is, you know, for a company who's doing a lot of closure work, that's cheap because, you know, they're getting the tooling improved documentation, whatever else they do. That feels like a very good initiative and something for people to, you know, something very concrete that you can do to improve closure. So.
01:22:47
Speaker
Yeah, so convince your company that they should be, you know, trying to give to closure us together. They're going to do good stuff from what I can say. Great point. Yeah, I agree. So closure is together. Yeah. Get your company to join. Exactly.
Evolving Reframe Documentation
01:23:06
Speaker
Nothing else, I don't think. I mean, Reframe will continue to evolve.
01:23:10
Speaker
Step by step, there's a secret folder underneath Docs called EP, which is where I do documentation on new features that no one ever knows about. But don't tell anyone. Yeah, don't look there. And it's actually non eccentric too.
01:23:28
Speaker
So there's no jokes. So some people people who find those jokes are hurdle. They'll like that. Yeah, give give reframe reframe 10 X ago. That's you know, give that a go. And and then become 10 X program. That's right. Become a 10. Become the 10 X programmer you always wanted to be. Yeah, that's what we guarantee when you start using it.
01:23:56
Speaker
start even not even finish you know that's the moment your fingers hit the keyboard and tight yeah as soon as you include that dependency you're done basically bang yeah super batteries yeah um on that bombshell
01:24:13
Speaker
Nice. Okay. So I think that's it from us for today. Thanks a lot, Mike. You know, I've taken time today on Sunday evening and there's been a bit of a difficult thing to arrange all the things with stuff working upside down in
Humorous Confessions and Event Announcements
01:24:30
Speaker
Australia. And me using Windows. There I said it. Yeah, I admitted it. Not only do I use cursive, but I use Windows. It's like...
01:24:41
Speaker
It's OK. I mean, your documentation is your, you know, way of cleansing. So that's OK. So we well, I don't I don't take any offense in using Windows anymore. I think this doesn't this confirm everything that you know about people who don't use Emacs.
01:25:03
Speaker
No, I think that the thing is that once you use emacs, I think you will start with the reframe thousand. I actually did. This will probably be the worst thing, but I did used to use emacs a gazillion years ago. Oh, yeah. VI then then emacs. So, you know.
01:25:21
Speaker
I think otherwise you would not gain this much of wisdom on that. You can stop. I'll give you 24 hours. Stop that flattery. Yeah. All right. So that's it from us for today. This is episode number 34 and this is Vijay from Holland.
01:25:40
Speaker
And Ray from Belgium. And just a quick shout outs to people who are helping us. Wouter, who is doing all sorts of audio stuff for us. Thanks a lot, Wouter. And then Luba, our designer, and Pizzuri, whose music we are abusing and basically copying and then not paying him. And one more thing is that Dutch closure day is going to happen on 21st of April.
01:26:08
Speaker
I'll be there and Ray will be there and unfortunately all the tickets are sold out. So if you can bribe me, I can get you some tickets. But it's a free event. We have a very fantastic schedule. A lot of nice speakers coming over for spending a day in Amsterdam. I think we'll talk about it after the event. That's it from
Acknowledgements and Invitations
01:26:31
Speaker
us. Ray, anything else that I missed?
01:26:33
Speaker
One, well, two more things. One is thanks again to all the people that put a few quid in there in our Patreon pot. You know, it helps to keep the cost of the show all managed, which is fantastic. And also just a small shout out to our apropos thing that we're doing on the video. Yeah, that other thing. That other thing. People actually, there's quite a lot of people joining in and enjoying that rebel experience. And
01:27:01
Speaker
So, you know, if you're listening to this and you'd like to watch a few Closure programmers fail live on YouTube, then we're doing that on a regular basis. So please join us. So this is a Twitter Aproposcast. Aproposcast, yes. Yeah. So follow that one. Of course, we'll put the links in the show notes. So that's it for today. Thanks a lot, Mike. Thank you. And goodbye. Bye now.
01:28:02
Speaker
I'm here.