Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
#92 defn.no with Magnar Sveen and Christian Johansen
124 Plays1 year ago
We catchup with norsemen emacsen Magnar and Christian to talk about their Clojure adventures, how they sneaked in Clojure through unconventional techniques.
Some highlights from Christian and Magnar's portfolios:
- Parens of the Dead https://www.parens-of-the-dead.com/ : how to survive Zombie apocalypse with Clojure and ClojureScript.
- If you are into Norwegian and want a taste of adventure https://www.adventur.no
- Level up your Emacs skills with https://www.emacsrocks.com
- Efficiently render and re-render immutable data with dumdom https://github.com/cjohansen/dumdom
- storybook.js but in ClojureScript https://github.com/cjohansen/portfolio
- Decomplect your i18n with https://github.com/cjohansen/m1p
- And for the Emacs folks out there, some super cool packages from Magnar (which you probably are using anyway) :
https://github.com/magnars/multiple-cursors.el
https://github.com/magnars/expand-region.el
https://github.com/magnars/emacsd-reboot
https://github.com/magnars/stasis
Recommended
Transcript
Podcast Introduction and Setup
00:00:16
Speaker
guys it's uh i think it's sort of 92 something i think but this time it's um what do you call this they're like a double bill no that's double guest double the fun
00:00:30
Speaker
Double trouble. Yeah. Yeah. So four microphones. So we were able to start all the technology crap already. Maybe a quick introduction round so people will know who you are and where you are from. And I mean, probably they know from the title of the podcast. But yeah, that's like spoiler alert.
00:00:52
Speaker
Well, I'd like to know for a start, you know.
Guest Introductions
00:00:56
Speaker
Who are you? Why are you in this meeting? Sorry. Yeah. Go ahead, Magner. Yeah. Hello. My name is Magner Sven. And if you have heard my voice before, it's probably on E-Max Rocks or Parens of the Dead. And I'm here probably because someone asked me to join.
00:01:22
Speaker
I've been programming culture since 2013 and started using Emacs two years before that. Thanks, Christian. Is Emacs rocks, by the way, just quick, is that like the rocks from which Emacs is made out of? What is this Emacs rocks? It's the rocks that is followed by an exclamation mark. Oh, okay. Okay.
00:01:48
Speaker
we'll come to it later. He makes rocks. They are the ones that we use as weapons towards people who don't use it max. So you skip throwing at them like using Max, using working for you. Okay. Sorry, Christian.
00:02:04
Speaker
Yeah, so my name is Christel Nihonsen and I don't know if people probably don't know my voice, but I do the Parents of the Dead screencast with Mungnad and I've done some open source stuff with Closure and I've been working with Closure now for, I don't know,
00:02:24
Speaker
I started the same time as Monat, but he was a bit more fortunate than me. So I had to do some more years of JavaScript. So I don't know, like seven years or something full time now.
Why Switch to Emacs?
00:02:36
Speaker
Yeah. And I've been using Emacs since university and I forced it on Monat the first time we worked together.
00:02:43
Speaker
I was using TextMate at the time and I really liked the extensibility of TextMate, which of course is majorly trumped by Emacs. But we sat down to pair program, maybe the first or second day together at work and I had TextMate up and I think maybe Christian lasted half an hour before I said, yeah, no, I'm not going to do this.
00:03:14
Speaker
Let's get the emacs going and it didn't take very long before I started making the emacs rocks. You got the rocks out and started throwing them at you. I think it's funny because like Morgan I was using
00:03:31
Speaker
Like what I would say is a pretty mainstream, uh, editor, like you could use normal keybites to get things done. And I just said like, I don't want to do this. And then he had to learn this very strange monster of a editor, but, uh, yeah. Yeah. And, uh, had hearts in my eyes the entire time. Back in the day, was that when you were like sat next to each other? Did you do it remotely at that time?
00:03:55
Speaker
No, it was just 2011. So it was into the office every day. Right. Yeah. Cause I always think like pair programming, like obviously it started in person. So like when, when he was using like Textimate and you were using Emacs, can I, I can sort of see when you're sharing a screen or something, but it would bother you. Or is it because of what bothered you actually other than the sort of like.
00:04:20
Speaker
the feeling that somebody else might not be using Emacs. What was the problem?
Pair Programming Adventures
00:04:24
Speaker
Let me clear up one thing. I did not have like a moral objection with him using his own tools. It was for when we were pair programming, right? So when I was to type on his computer, I had to type it into this shitty. Oh, there is no moral judgment, except that it's a shitty editor.
00:04:46
Speaker
For my taste, for my taste. That's true. So this is because you weren't using a shared drive with the computing stuff on it. It was just like, you know, just one... No, we were like... Just one computer base. Yeah, pair programming. Yeah. As God intended. So one person on the shoulder, other person typing and... No, I know, but in the remote setting, you don't do it like that anymore, do you? You tend to like commit it and then, you know...
00:05:13
Speaker
Do that. No, we do. We still do that. Oh, you do it even remotely. Oh, you do it with Teambox or something, I suppose. No, we use, I'm not sure, am I allowed to mention commercial products? Oh, sure. We use an app called Tuple, Tuple app. And it works really well. So you have screen sharing, and then you can use the keyboard, even with like control sequences and everything works.
00:05:42
Speaker
Oh, nice. So you have a few tools and it's not specific to any app. It's just in the operating system. And you can just use the keyboard on the other person's machine as if it were your own. It feels like a terrible security breach to me, but okay, fair enough. Yeah, I guess you would not invite people you don't trust.
Functional Programming Journey
00:06:09
Speaker
Yeah, I've seen all the movies, so you know, it's the people that you do trust that are the problem. All the wives getting killed by the husbands, not by strangers, you know, it's the same with the keyboards. I don't trust my, I keep my enemies close. Anyway, yeah, joking aside, yeah, but so it was like, it was, so you were doing like sitting next to each other and then you swapped computers, you just passed the computer to you and you
00:06:36
Speaker
sort of essentially threw it in a bin and, you know, fish out of the bin. Installing mags. God damn it. Yeah. Something like that. And then, uh, he took it and ran with this to say, to put it very lightly. Okay. Well, that's, that's very nice. It's very nice. I must say, um, I'm not sure if I'm pronouncing your name correctly. Is it G silent or is it
00:07:02
Speaker
I would say you have a very good pronunciation. Okay, I'm not going to say it again, then I'm just going to leave it at that. But you know, I used to watch your Emacs rocks, you know, small episodes and like super quick things. And there are so many ton of things that that Emacs can do that I didn't know. And like, especially the way that you do the multiple cursor stuff.
00:07:25
Speaker
Within seconds, you show something super magical stuff. It's really, really amazing. And I was hoping it will keep continuing for years and years. But yeah, but it's really, I think it's, as you mentioned, like 10 years ago or seven years ago or something. Yeah, it's crazy. It's 11 years since I started. And the thing that happened is quite simple. I got used to it.
00:07:50
Speaker
In the beginning, everything was amazing. The first episode is sort of like...
00:07:56
Speaker
Wow, it's amazing how you can do work with regions. Those things don't feel amazing anymore. But we have recently, sort of like the last month, done an Emacs reboot and discovered some pretty cool things. So I'm hoping to do a couple Emacs Rocks episodes based on that. Ooh, nice. Nice. But which came first? Is it Emacs or Closure for you? Both.
00:08:24
Speaker
We started working together in JavaScript. We were trying to do functional programming in JavaScript. For a long while, we created our own DOM rendering library to do
00:08:48
Speaker
rendered the entire DOM from data idea that was in React. Prior to React, we just didn't have the key there, which was the shadow DOM for the speed. So we were very primed for the ideas that Closure came with, because we had frustratingly tried to work functional in JavaScript for a while.
00:09:12
Speaker
So I remember like the tipping point for me was watching Simple Made Easy by, of course, our very own Rich Hickey. And I remember every couple of minutes watching that talk in my own living room, I had to press the pause button and walk around in my living room shouting, yes, exactly. That's it. And then continue watching. Like this guy gets it.
00:09:41
Speaker
Yeah. I mean, we were so primed for it. And another aspect was that, uh, cause we'd also been like really infatuated with, uh, e-max lisp. So it's really charmed by, by the whole lisp thing. So we had, we'd kind of started working on the functional programming side and we started working on the lisp, which interestingly, like e-max lisp is, is as unfunctional as you can get it.
00:10:06
Speaker
But anyway, then comes this language that solved all our problems and combine those two things into one tool that would be best worked on in Emacs. It's just the perfect package. So going back a little bit further then,
Why Choose Clojure?
00:10:21
Speaker
why did you kind of want to do functional programming in JavaScript? Because obviously that's, well, that's not the obvious thing to do in JavaScript. So where does that idea come from?
00:10:34
Speaker
I think it started sort of with seeing how immensely, how much failure was to be found in using jQuery. Because there you would sort of just manipulate the DOM piecemeal using invocations that were
00:10:53
Speaker
Yeah, we don't have to go into all that, but it was a mess and was a buggy mess. And it was, um, we're trying to find solutions to that basically. So where'd you come across like that idea? Was it that, was that rich or was that before rich that you kind of like, uh, hit upon this, this Damaskian kind of, uh, concept that functional programming could help you out there?
00:11:19
Speaker
I think it was a little bit before, before. I don't remember what.
00:11:25
Speaker
you know, how we fell into it. But I do remember I gave a talk, which I remember well, which was called Step Away from the For Loop. And the main idea in that talk was that I discovered like map filter. And I kind of discovered that this thing that we're using all the time, this loop, is being used for very different kinds of tasks.
00:11:52
Speaker
And using these functions, you can separate those kinds of tasks and then you can puzzle them back together. And this will give you more composable code or whatever. You could like separate the things. Instead of doing filter and map at the same time in a for loop, make one filtering function and one mapping function.
00:12:10
Speaker
I remember that very vividly, but I don't remember how we came upon it. I think I maybe know where I first stumbled upon it. I think separately, but probably from the same source. And that was when we started using Ruby. Yeah. Yeah. When you mentioned Textmet, I was kind of thinking.
00:12:32
Speaker
you must be doing Ruby because that seems to be the editor for Ruby shit back in the day. Yeah. And the only reason I wasn't using TextMate is I didn't use a Mac at the time. I was using Linux. So I just kept on to Emacs, which I learned in university. But yeah, we both came from Ruby in some way, I think. I mean, TextMate was, I mean, of course, I use Emacs, but
00:12:59
Speaker
It was a very high quality editor and the way it was built and there is a reason why it took over Mac editing pretty much right. I mean there is a super native and behaves like a Mac application and then has amazing text rendering stuff and everything and yeah fast.
00:13:16
Speaker
Anyway, um, but it's an open source thing right now. So maybe people still hack on that stuff. I don't know. I think like also many, uh, Monartic created a whole lot of packages when he was picking up Emacs and a lot of them were inspired by things in textmates.
00:13:33
Speaker
Oh, yeah. And I think, isn't that right? Yes. Multiple cursors, which I created for Emacs, is inspired by TextMate. And my other most popular user-facing package is Expand Region. And that was inspired by IntelliJ. OK, cool. Pour one out.
00:13:57
Speaker
Hey, but that's the beauty of it, right? You can, you can, you can build these things without someone else, you know, uh, building this, this stuff for you inside the proprietary editor, or you need to wait for this. They even just immediately hack it and then put it into that one. Um, that's, I think we'll, we'll, we'll talk more
Clojure's Impact Over Time
00:14:15
Speaker
about e-max and pretty much we'll only talk about e-max today anyway. But just as a little bit of a digression into other things.
00:14:24
Speaker
Yeah, tiny digression into some other world. So you mentioned you started with JavaScript, right? Ruby. Yeah, Ruby, but then doing JavaScript and then moving into Closure. But I didn't hear any JVM-related stuff that you did or what we're using for the server side or whatever, because Closure, at least initially, maybe pre-2013, I would say, was predominantly JVM anyway, right?
00:14:53
Speaker
Yeah. Yeah, I didn't have a lot of experience with the JVM at all. I mean, I learned Java in university.
00:15:05
Speaker
I worked with Android for a year or so. But that's about it. So I'm still learning about the JVM. So we all. I actually made my own editor in Java. Oh, wow. This is like the opposite ends of the spectrum. This is why we need the intervention, actually. Yeah.
00:15:29
Speaker
Yeah, I wanted to create an editor for my text game and the only program language that I knew on the PC because I had a program mainly on the Amiga for 10 years.
00:15:46
Speaker
was Java, so I had to use that. And so I remember drawing my own cursor using the graphics, 2D graphics library, draw, rect. So I created my own cursor and wrote my own font symmetrics and everything. So that was fun. So you're much more closer to JVM closure than Christian was.
00:16:12
Speaker
Possibly, but I, I, there was, there was, this was the time when it wasn't cool to do front end development. Yeah, it was the thing that people.
00:16:24
Speaker
thought about when they thought about frontend development was bad popups and marquee text. And so since I always wanted to do, I just wanted to build shit, you know, so I had to actually also do the frontend stuff. So when I came into like a workplace,
00:16:46
Speaker
I was pretty much the only person there that wanted to touch HTML and CSS and I sort of became an expert in Internet Explorer 6 at some point. No one wants to be the expert on Internet Explorer 6, but it was just, you had to do that stuff.
00:17:04
Speaker
It's like being the printer guy or something, you know. Yeah, exactly. I think actually being the printer guy is much worse. Yeah. Postscript. Yeah, true. Printers are a work of the devil. But actually, this is just a funny anecdote. At some point, every consultant at the place that I was working at the time got thrown out.
00:17:29
Speaker
And one month later, I was the first consultant they brought back in because of my Internet Explorer 6 experience. Hey, there you go, kids. If you want job guarantee. Learn Cobalt. Go and learn. Yes, like Cobalt. Learn Internet Explorer 6.
00:17:46
Speaker
They had created an entirely new page that was going to be used by mainly every adult Norwegian. And watched in Internet Explorer 6, it was just a white blank page.
Web Technology Evolution
00:18:01
Speaker
And they had no idea what was going on. Let's get Monet back.
00:18:06
Speaker
But I mean, so there's a lot of useless stuff that I know about IE6, but at the same time, a lot of the things that I learned at that time is still useful to me, right? There hasn't been that many changes to the fundamentals. There's some new stuff you can pick up. And it seems to me that's a pretty big shift. People today don't necessarily start with the basics. They start with React or whatever.
00:18:36
Speaker
and then slowly work their way down to whatever is actually happening. But we worked for many years just moving basics around. And that has been tremendously useful to me in all the years after. I'm curious if people these days actually know that X in Ajax came from IE.
00:18:58
Speaker
being XML HTTP request. It's like the floppy disk icon or something. Things have become forward. But at some point IE5 and IE6 were the chromes of the day, or braves of the day, or whatever the new web kit of the day. They really pushed shit forward with IE. Otherwise, we wouldn't have... We might have better technologies than what they had, but
00:19:25
Speaker
plugin mechanisms and all that crap, I think it was IE thing back then. And then later, maybe they decided to fuck everyone up. I mean, the main problem with IE6 is that they declared that they won the browser wars and they stopped working on it. Exactly. Yeah. Like for close to 10 years or something, because they had whatever 95% market share or something, they didn't need to work on it. Yeah.
00:19:54
Speaker
the complacency. So what was the first, I'm not sure how much you can talk about your closure projects themselves, but it'd be nice to know that the stack and where did you start and what kind of closure projects that you initially you worked on and then you thought, well, this is great and this is shit and we should go back to writing JavaScript. Was there a moment or?
00:20:22
Speaker
at the moment where this shit has not occurred yet. The very first project that I used Closure for was my text game, because I almost all the technologies that I've been
00:20:39
Speaker
I tried it first there, which is a fun way to experiment with the stuff. But yeah, I've been working professionally with Closure since 2013 and quite a lot of different customers, but all from a sort of corporate event planning to tech docs to
00:21:08
Speaker
mobile apps and all sorts of stuff. Yeah. We could mention like the first project we did though, because that's quite fun. We were hired to do, to write technical documentation is why we were hired. So there was this, yeah. We did all this nightmare.
00:21:31
Speaker
We went into this with a great plan because it's like a payment and SSO provider in Norway, pretty big one, and they needed proper API docs. And they needed someone to work full-time writing them and they pitched a project to us and we said, yeah, sure. They wanted us to write it in confluence.
00:21:56
Speaker
And so we said like, okay, so you want to hire us for three months to write a documentation in Confluence? Fine, we'll do it. And then we whispered like, we're not going to do it in Confluence. There was a small asterisk in the contract and then they said, not really.
00:22:15
Speaker
So then what we did, so I remember the first demo we did for them was very cool because we presented exactly what they had asked for, like pairs, a bunch of documentation inside Confluence. But that had been produced by a Clojure program that exported everything and used the Confluence APIs.
00:22:42
Speaker
to stuff the docs in there. So we wrote the system instead to build the documentation site as a standalone site, and then with the option of exporting everything into Confluence.
Technical Documentation with Clojure
00:22:54
Speaker
And then we said something along the lines like, so this is what we have. You can use this standalone site that we built for you. Or if you want the documentation to die, you can export it into Confluence.
00:23:08
Speaker
Yeah, the cool thing there was that we integrated it with the real API. So you can, well, this is more normal these days, but you could watch example requests in many different languages and look at the example response and so on. And all of those things were tested against the sandbox API. So it was real results there and so on.
00:23:34
Speaker
So that wouldn't be possible in confluence, but we did export it to confluence so they always had an out. The thing I find the thing I found by the way, I used to do some like programming with Atlassian tools and I don't know if you found this but.
00:23:50
Speaker
Their APIs were just constantly evolving, by which I mean breaking all the time. Every minor version, they would just change some parameters or some API. Then they'd tell you, in the release notes at the bottom, 40 pages down, oh yeah, this API changes. Meanwhile, your build breaks. It's like, ah, what? Yeah. We didn't actually work a lot with those APIs because they wanted to use the standalone tool that we built.
00:24:17
Speaker
So we built that just to have kind of done what we're told. But I mean, because it wasn't originally like a programming project, which allows us to just pick a tool that we wanted to use. And so we picked Closure and we did everything with Closure.
00:24:35
Speaker
That's a really perfect, perfect way of doing things. Yeah. And that site is still running today, I think. Yeah. Oh, yeah. But I'm not sure if I'm remembering it correctly, but I thought at least, you know, at some point was using closure script.
00:24:50
Speaker
Maybe, maybe I'm wrong. Maybe for the editor or some shit, they were definitely using closure on the backend. Cause they've had various blogs from closure people. Um, uh, over the years, I think, I don't know if it's still the case, but yeah. Yeah. We never know now that, uh, they're on a quieting spree at this, at this point, they probably use every language on the planet. Yeah. I was going to say like, they're so big that it's probably some team using whatever tool. Yeah. Yeah. But this is a, this is a completely different.
00:25:20
Speaker
story of sneaking closure in because usually The way closure gets in is like, oh they're using a java java shop and then we're just putting a jar somewhere So without people noticing that is written closure, but this is this seems to be a bit more um ocean level type Sneaking sneaking closure into the thing into a documentation project. Yeah, it's it's just It is crazy nice um
00:25:48
Speaker
But what was the, so you build this tool and is this something that like a commercial product or it's only for them to be used or the documentation generated thingy? No, it's built specifically for that project. Okay. But I don't remember. Did we use Stasis for that? Yes. Yeah. Okay. What's that?
00:26:15
Speaker
Stasis is a library of tools for building static web pages that I created. I think that maybe was my first closure, the very first thing I made a closure, even before my adventure game, when I think about it.
00:26:32
Speaker
I created Stasis, which was basically a ring middleware so that you could work locally, sort of like just a normal web server and an export function to print all the HTML files that you wanted. And I used that to create a website for the consultancy that I was working in at the time.
00:27:02
Speaker
the confluence stuff, but they do have an editor. And again, you can knock that editor because it is terrible. But did you have an editor as well, or were you just like writing markdown and or ASCII doc or whatever, and then just like pushing it out to HTML or then the confluence? Yeah. Markdown to HTML. And then we built this.
00:27:27
Speaker
Oh, yeah. Yeah. And then it's like a system that pulls together code examples. Right. Yeah. But they were in source files because they could also be run as tests. Yeah. So we had a system that like when you deployed the site, it would actually check that all the code examples worked. Okay. It's like a book publishing system, really, you know, all these people that write closure books should use your tools.
00:27:54
Speaker
Yeah, it's too bad it's owned by a commercial. Well, they can always rewrite it. I mean, it wasn't that hard. Yeah, but we wrote most of this stuff in three months.
00:28:10
Speaker
But is it Closure JVM thing then? So Closure then, not Closure Script. Okay. Yeah, yeah, yeah. Nice. So what about the game stuff that you built, Magnow? Is it? I think that's a podcast on its own. It's going to be next episode.
00:28:30
Speaker
It's a Norwegian text adventure game that I have been writing and working on the last 25 years. The amount of text in the game is two times the Harry Potter series.
Text Adventure Game Development
00:28:48
Speaker
Okay. So it's about 2.4 million words. Wow. And it's the current incarnation. The first one was written on the Amiga, and I've written several engines for the game up through the years. But the current incarnation, and I think, and I hope the final, is written with Clojure and ClojureScript and Datomic. So it's a very nice place to spend some free time in building new features.
00:29:19
Speaker
That's, that's a pretty, you know, uh, jump from Amiga to data. There's a lot of history in this in between. Yeah. So how do you distribute it? How is it? So the idea is that you have some package that you distribute and it all fires up locally or is it a multiplayer game? It's a web game. It's a web game. So, uh, people go to, uh, which is the, uh,
00:29:46
Speaker
URL and then they play there. It's, um, it's, uh, quite, quite a weird thing. Uh, but it's a lot of fun to make. Yeah. But it's a, it's a lot of fun to play as a single player game or a massive player game. No, it's just give us the pitch game, game trial, you know, I already called it like the game advertisement.
00:30:09
Speaker
So once you go to the web page and you press start game, you are presented with some text and then you read the text and then you're presented with some alternatives and you choose an alternative and that's basically how it goes. And there are several examples of this on the internet, but those examples have maybe
00:30:32
Speaker
five to 10 minutes gameplay. And you can play this game for hundreds of hours. Is it like Rick and Morty? Oh, now you're in a forest. Now you're at an airport. Your mom is leaving the airport now. It used to be like that when I started writing it as an 18-year-old or something like that. But no, it's now pretty much a fantasy, a silly fantasy game.
00:30:59
Speaker
Yeah. And I would add that one of those severely underselling his game at this point. As Norwegians do. Yeah. There's a lot of, well, the overall form is like explained, but there's a lot of complexity in the rotation. Yeah. Lots of layers. And you can, you can become a good person or a bad person that will shape the story you see. And it's like, yeah.
00:31:27
Speaker
There are 5000 commits of features in the engine. I don't want to make you spoil the game for anybody. We can just read the entire 2.5 million words here.
00:31:49
Speaker
Get it. But I'm curious, where is the data stored? So the whole thing is stored in Datomic? Or is it, you know, why Datomic for this? Because it doesn't seem like you need a database here. It's a good question. First of all, since I wrote the game on the Amiga, it could easily have been lost.
00:32:12
Speaker
And luckily, it didn't because my first adventure that I wrote, I wrote in the code with print lines and go to the read string. And that game quickly turned impossible to expand. So the next thing I did, and this was when I created the engine.
00:32:36
Speaker
I started writing to files. So each page has text and alternatives and I got a page number and that page was then stored on disk as a text file. And this is the reason that I actually have the game today because I could take those files and move it to the PC and I could parse them with other languages.
00:32:59
Speaker
and so on and so on. So there are still text files, and I have, of course, an Emacs mode to edit them with IntelliSense sort of features and so on. That is connected on the Datomic running version because text files must be read and parsed and so on. So all of the content in the game is also in Datomic, sort of like a quick lookup so I can find IntelliSense information while writing and stuff like that.
00:33:28
Speaker
But the reason that I need Datomic, other than it's freaking cool, which I think maybe it started as, is that your main protagonist that you're playing has a superpower. And that superpower is time travel. And I had implemented time travel in PHP and in Java.
00:33:55
Speaker
And that was horrible. That was a mess. I have two PHP implementations on my time travel. And okay, I'm going to have to do this one because it's too cool. I had not been able to fully or correctly implement time travel in PHP.
00:34:15
Speaker
It was pretty good. It was 98, 99% there, but there were some cases that I hadn't been able to handle properly. And that was explained in the game as time travel is magical. You can't explain it, so if something weird goes on, it's the magical nature of time travel.
00:34:40
Speaker
That's one way to roll your bugs into features. Yes, exactly. This is part of the grand design. Another way of looking at it is it's time you'll never get back. That's true. But with Datomic, I can always know whatever state you were in at whatever point. So all the magical thinking around time travel disappeared with the closure version of the game.
00:35:06
Speaker
So what you're saying is closure, remove the magic from your game. Oh, there's other magic. Not the flukey flaky time travel magic. So there's more intentional magic now. Yes. Nice, nice. But it must be like powerful magic.
00:35:24
Speaker
Yeah, but it seems like I don't usually have people who have been working on the same project for 25 years. It's very rare these days. As you know, in your consulting world as well, people come and work on something, move on to the next one. But if you look back and if you look into the future using time travel techniques, would you think there is going to be another rewrite
00:35:59
Speaker
You know, I wouldn't call it difficulties, but whatever the tiny kinks that you have in closure, that needs to be fixed. I think that's a very good question. And before I answer it, I just have to say one thing. You started rewriting it in brass? Okay, moving on. And that is 25 years ago when I started writing this game, E-Max was already 25 years old. Yeah, that's right.
00:36:19
Speaker
in a different language with whatever the
00:36:27
Speaker
Isn't that crazy? Yeah, that's mental. Anyway, come back to your stuff now. So the question. I used to learn a new programming language every year because I had read the pragmatic programmer's book and it told me to do that. And it stopped.
00:36:49
Speaker
when I learn Clojure. I am no longer learning a programming language each year because I'm home. And the last 10 years have told me that I have chosen right.
00:37:05
Speaker
There's so much cool stuff going on just in the Closure community. And I'm learning, so I'm just sort of pining for another Rich Hickey talk where he can blow my mind again. He's done that quite a few times, but I want more.
Data-Driven UI in Clojure
00:37:29
Speaker
But yeah, Closure, especially with ClosureScript, especially with Datomic,
00:37:34
Speaker
It's such a beautiful language and such a beautiful environment and everything. So I do not think I will rewrite my game the next 25 years. Yeah. And yeah, go ahead, Christine. No, I just wanted like one thing I've been thinking about, because I did the same, like was jumping technologies and whatever. But
00:37:58
Speaker
I think it's interesting now to have worked mostly on this language for 10 years. And the language hasn't changed a lot. It gained a few minor features, but it's roughly more or less stayed the same. And this has allowed me to hold my skills with it in a completely different way that I've never experienced in any other technology.
00:38:22
Speaker
Like I'm not spending time relearning how to route requests in the web framework or like not relearning things I already knew. Instead I'm just like very slowly honing my coding skills. And the code that I write now is, I don't know if I would say very different, but it's different from seven or 10 years ago. It's more refined in a way.
00:38:52
Speaker
I worked on my 10-year-old elementary lyrics code today, Christian, and I can say for sure that we have come away. Because that code is still pretty good, but I would not in a million years write it like that today. No. And it's been like, we've been working together now for many years and it's like,
00:39:16
Speaker
In the past few years, we've been churning out a few smaller libraries for things that have kind of come to us after dancing around for some time. And some of those are tools that I don't think we would have discovered in more of an ever-changing ecosystem. Because you need some time to work on a stable set of tools to see some patterns emerge. Yeah, that's a good point.
00:39:42
Speaker
So can you give us some examples from your experience and from your OSS work, the things that we should know and then the listener should know as well?
00:39:52
Speaker
Yeah. So like the overarching theme has been, uh, making shit data driven. Yeah. Yeah. And, uh, and really, cause that's, I closer did that already 10 years ago or whatever, but it took us working with it for some time to see like all the amazing places you can do more of that. Hmm.
00:40:15
Speaker
So like we had, okay, so for instance, we had hiccup for a long time, right? Because you can represent the DOM or the HTML template or whatever as data, which is cool. You can use walk to walk around it. You can use treesake to find things in it. It's malleable, right?
00:40:36
Speaker
And then so we did the same thing with on the UI. We originally used a library called quiescent, which is like one of the many React wrappers. And then we wanted to get off React at some point because we've worked like in quiescent, you don't have any component local state. So you're only using it as a rendering a library.
00:41:02
Speaker
And as React was changing, we had to keep fixing our wrapper to run after the API changes. And we got tired of that because we were not using any of those features that they were adding. So we decided to just drop it. So then we made our own. This is like a small library called DoomDome, which instead uses another JavaScript virtual DOM library. And when we did that, we found more places to use data.
00:41:32
Speaker
So we like it got hiccup support and then we found that like events that you trigger or like event handlers functions like those functions were a thorn because that was the only thing in our data structure that wasn't data and then we found a way to express them as data as well.
00:41:56
Speaker
So we built that into the library. So the library now has like a global event handler, and then you can use data for, you can say on click and just a bunch of data, and then those data will be sent along with the event to your global event handler. And boom, everything is data.
00:42:13
Speaker
And then the app we were working on had multiple languages. We built an IATNN library. Again, just use data. Cause we had like this translate function TR that was like all over our code. Everywhere we want to text, we call this function.
00:42:30
Speaker
And then we figured out that we don't want to have this dependency on this library everywhere. So how can we get rid of it? Well, we could put a placeholder here instead, like a vector with a keyword that says i18n. And then we can translate the whole structure another place.
00:42:49
Speaker
More data. And these are just some examples, but ideas that have taken some time to develop. Yeah. Just on a small point there, like a little nitty point, but are you starting to use these, or have you been using these tag literal stuff? Like you mentioned I18n there, is it a special keyword, or is it a hash I18n, or is it just a call on I18n?
Criticizing Frontend Frameworks
00:43:17
Speaker
Yeah, we just used the namespace keyword, but actually the way we built the library, uh, you choose the keyword, right? Yeah. Yeah. Yeah. So, um, yeah, you just tell the, the library that you, here's the dictionary for this keyword and then it finds things that matches. So you've got data for the definitions as well.
00:43:41
Speaker
Yeah, in a way. Metadata on the data that you define. That's good. That's nice. Let me do sort of one example. That's pretty cool. Because when you write Hiccup,
00:43:57
Speaker
you have this beautiful data structure that you can walk, that you can tree-seek, except for the functions, right? Because they're totally opaque. And even worse, every time you make a new function, it's different, right? It's a different object reference.
00:44:13
Speaker
So since it can know about the event handler, know what the event handler includes, since it's just data, it can even optimize the way of updating that every time. But the coolest part is since the function is now data,
00:44:33
Speaker
Let's say I have a button that I press on and it alerts something. It's just a JS alert. And that text would be inside the function literal, right? So it's hidden inside the function literal. But now that it's data, you can use the i18n library to walk the entire structure and including updating the language snippet that's inside the function. And this is something that you would
00:45:03
Speaker
Well, first of all, it's not even possible to do it without everything being data. But it's not even something that you would think about doing prior to working with this for a while. So going back to Christian's point, that the calmness in the closure ecosystem, let's use find new gems hidden there.
00:45:30
Speaker
It's not constantly changing and evolving and new shit is coming that you need to adapt to. There is no stress of that chasing the next version of the language like Swift does usually. Every fucking release. Yeah. And another thing like also related to this is that while we've been working on these like Closure and Closure scripts and the tools, it is the toolset has been quite stable over the past 10 years.
00:45:56
Speaker
And then let's take a look at the other ecosystems. What are they doing? Like in JavaScript, their tools change all the time. So they must have much better capabilities than we do, right? No, they don't. It's just the same stuff over and over again. Very rarely do you get new actual capabilities.
00:46:18
Speaker
If you take a look at the JavaScript framework situation today, most of them are just talking about performance. That's the main different ways to do things to get more performance. I can count on this one hand how many times I had to performance optimize anything the past 10 years on the front end. If you have immutable data, you have good enough performance for almost anything, at least for the kinds of app stuff we've been working on.
00:46:46
Speaker
Yeah, I mean, not every app needs like, you know, globally distributed CD and spewing and everywhere. And then I think 80, 90 percent of the applications are with the computers that we have, with the browsers that we have, optimize the hell out of everything. It doesn't make much sense. Yeah. And that's true. And like we like to say also, because we work in Norway, right? And in Norway, almost no one is web scale.
00:47:14
Speaker
At least if you're targeting the Norwegian market, it's not web scale, right? The entire population is less than like a medium-sized city in the US. But don't you have latency problems then? People all the way there, in the North, all the way here.
00:47:33
Speaker
I mean, most people are used to browsing American servers, so I guess they're used to a little bit of latency. Yeah, that's true. That's true. Nice. But, you know, when you started JavaScript, when you were doing these things, I remember having this, because I used to do JavaScript back in the day as well, you know, kind of a little bit of front-end. Probably, you know better that there is this underscore and
00:47:59
Speaker
the backbone time. And there have been a couple of things that were kick-starting this whole functional slash reactive slash heavy frontend thingies. But if you see current ecosystem in JavaScript, and pretty much everything has settled down to reframe. And how do you see that compared to relative to ClosureScript? Because there has been so many iterations on
00:48:26
Speaker
in JavaScript, and the enclosure script, for me, it feels like we're kind of settled on React, and that's pretty much it.
00:48:35
Speaker
So this is time for a rant. This entire podcast is ranting. Yeah, but a small rant incoming. Yes, yes. I'm actually a little bit disappointed with the ClodrScript community in this sense, like not in terms of I don't want to point fingers at anyone, but
00:48:58
Speaker
I think it's a little bit of a shame that we've just landed on being a lisp for the JavaScript ecosystem as opposed to building a better alternative, which I think we could have done.
00:49:14
Speaker
And can still do, I guess, like we are building our stuff, but nobody is listening to us. Not this podcast, but yeah. Yeah, but I mean like, so because like the whole front end ecosystem is pretty much just a front to whatever is going on in the JavaScript world. And I don't mean to say that we should have gone the route that Elm took, that like you have to have everything needs to be built into the language where you can't use it. Yeah.
00:49:42
Speaker
That's not what I want, but it would have been nice. Like at this point, I would have thought that we had a native closure script response to react, for instance, that did not include lots of mutable state everywhere. Have you seen even modern closure script frontends have like atoms everywhere?
00:50:05
Speaker
Yeah. And that's like, we have better tools than that. We don't have to do that shit. So why? I think it's a bit of a missed opportunity. Closure is a lot more than a Lisp. And the closure script, at least my impression is that people are mainly using it as a Lisp on top of the JavaScript ecosystem.
00:50:28
Speaker
And I don't think they're getting all the happiness out of that that they think they are because the ideas in closure are radically different. And I think you can take those ideas and I feel like we have done that into the closure world as well. And the only
00:50:47
Speaker
argument against it that I've ever heard is that it won't perform, but it has performed and it continues to perform. So it's really, I would really
00:51:02
Speaker
hope that people also working on the frontend in ClosureScript will start seeing sort of the immutable data, the pure functions, that way you're working with code is also the forward in frontend development. Maybe you will get an opportunity for this because I don't know about you, but I perceive that reframe and reframe, oh, damn it.
00:51:30
Speaker
react is kind of i wouldn't say jumping the shark but feels a little bit like that it feels like this is all coming into it.
00:51:39
Speaker
There's a sort of, yeah, the kitchen sink is coming in now, you know? It started off as very much like a view over the function, over a DOM, and now it's getting all kinds of stuff. And you see other projects like Vue and Next and stuff like this, and they're trying to focus on performance, but they're also trying to focus on
00:52:01
Speaker
feedback loops and stuff like this. They're trying to differentiate themselves from React. They essentially say, okay, yeah, we get it. We get you to the immutable DOM. But now they're saying, actually, it's immutable DOM. This shadow DOM doesn't matter anymore. Some of them are not even using that. So they're saying, actually, we can do it fast enough without this shadow DOM, which is what I think you started with.
00:52:28
Speaker
No so i think i think i would say that maybe maybe the javascript world is changing a little bit. To give opportunities for that kind of thinking because it feels like they're doing that thinking as well that they see the,
00:52:43
Speaker
but they're going in a wrong way in my opinion. They're going like the, I was, I was going to say like, so they're making the change, taking the entirely wrong direction because, um, so, and so I'll stop my run. I'll stop my run to let you have yours. Please. I've just teamed you up here. Yeah. Yeah. But I don't mean to like, uh, be a nit picky, but it's, it's the virtual Dom. The shadow dome is my back. Yeah. Yeah. Sorry. So the virtual DOM, but the virtual DOM is the good idea.
00:53:13
Speaker
Because the virtual dome allows you to have the programming model where every change leads to a full re-render, like the conceptual model. That's the good idea. And now they're ditching that idea for whatever performance, blah, blah, blah.
00:53:29
Speaker
And they have, so they're like, okay, so you can have surgical updates because you have lots of mutable states combining the view with state, blah, blah, blah. That's terrible. I don't want that. I'm done with that. I was done with that 10 years ago.
00:53:49
Speaker
And that's also what is my impression that you do in tools like Reframe. You can put subscriptions anywhere, right? And then you have a more targeted update, which is more performant. But I think a lot of people use those tools and they don't really know whether or not they need that extra performance.
00:54:12
Speaker
And you're exchanging a worse programming model, in my opinion, for that performance. Optimizing prematurely, and I'm thinking you need that without actually measuring anything. Yeah.
00:54:26
Speaker
And I mean, I just had like, there was recently a long discussion on this on the closure in Slack as well.
Performance Optimization in Development
00:54:34
Speaker
And the follower started the discussion. It was a very interesting discussion, but he was under the impression that he needed to do this stuff in order for things to perform. Yeah. Because that's what things told him.
00:54:49
Speaker
And he had no reason to challenge that. He was like new to UI development and all the signs posted to you need to optimize, else it will be slow. But it's not true. But don't you think that like every 10 years, everyone forgets everything?
00:55:07
Speaker
That's why we don't forget things. I think to your point earlier on, we can find the gems hidden on the floor because like you said, there's nothing covering them, smearing them. It's like going to an old house and finding you've got some linoleum from the 1970s. You pick it up and you realize you've got tiles from the 1920s, absolutely gorgeous.
00:55:34
Speaker
Some idiot, like, you know, sort of put some shit over them in the 1970s because they thought it was all hippy dippy.
00:55:41
Speaker
And then you get back and say, Oh my God, this is absolutely gorgeous. This is beautiful. This is the good stuff. I mean, I feel like we're putting lino on all of our code every 10 years. And that's the same with like the HTM X stuff, right? That's, uh, that's curious about your, uh, your opinion on that. And I was about to ask because that seems to be something that, I mean, not, not with closure, but.
00:56:05
Speaker
other languages that I dabble with that, you know, that feels to me like a lightweight ship than me making complex applications and for my limited one-person work. Yeah.
00:56:18
Speaker
I mean, I haven't used it. I haven't checked it out thoroughly, but it's definitely, I know what it is because it's what we did 15 years ago. And I would not be surprised if it becomes very popular because I think it's probably a better tool for many, many people than the hugely complicated single page applications that people are building now.
00:56:45
Speaker
I think that is the problem that I see, or not a problem, but kind of an attitude with every time I deal with the front-end folks who are building this stuff.
00:56:55
Speaker
They immediately start with, that gives me PTSD from all the Java EE shit that I made back in the day, knowing nothing better, obviously, before Spring told us everything is much better, and then Spring became bloated later. Because every time I open this front-end projects, I get like, the fuck, there are so many redirections, so many classes, so many this, so many that.
00:57:22
Speaker
Why is this so complicated? And as you mentioned, maybe there is no, nobody who is telling them there is an easier way. Like you don't need for a fucking 20 page application, which can render super fast. When you click from page to page, you don't need to have this huge as build process, huge as package Jason.
00:57:42
Speaker
I mean, like the thing that we're working on at work now, that's a static HTML page. That's it. Those are fast. They're accessible. They're easy to make. Like what's not to like. I think what's not to like is the fact that it's not an application, you know, uh, documentation on the internet is should be simple. Like you say, and that's fine, but don't you think we should have applications?
00:58:09
Speaker
Like, and we should have good support for those. And that seems to me like, that seems to me like where we're going wrong, because I, this idea of a document thing being an application thing seems to have been the problem. And now we're getting like back to everyone saying, Oh, we'll just make documents. It's like, Oh, okay, fine. But what about the applications? You know, don't we need that as well?
00:58:33
Speaker
Yeah, we need, but I think we need dramatically fewer applications than we have today. Well, fair enough. Yeah. I think looking at everything like a React application is the fucking problem. That's what I feel like. Not every application need to have like
00:58:48
Speaker
20 different toast notifications and shit and popovers and this crap and that. No, it's okay because I can click and then go to the next page and there is information density and it's okay for a, I don't know, imperceptible delay if I click a button and then it just going to render a table again. That's fucking okay.
00:59:08
Speaker
Yeah. It's not, it's like most of the time those navigations will even be faster than. Yeah, exactly. Yeah. It's, it's yeah. Anyway, but, um, for me, no, no, it's my turn to rant, I guess. I'll stop, but I wanted to go, you know, in a bit different direction in the discussion, like, because we're, we're,
00:59:31
Speaker
more and more I see when I'm talking to the startups or the new applications, I see JavaScript being converted to TypeScript and then also the back end written in TypeScript these days. I mean, if you see most of the new, well, new in the last five years or so, when I try to see some open source software that is whatever web hostable, suddenly even the back end is now TypeScript, not just the front end stuff. And what is your view on
01:00:02
Speaker
in general TypeScript, I mean, I guess, you know, types probably not a, not something that, you know, uh, you would say types are better in being in a Closure community. But how do you feel that, how do you feel about TypeScript compilation and the guarantees that you get from, from this and also going into the backend? Yeah. Um, I feel like the safety net that types give me is not a safety net that is very useful.
01:00:33
Speaker
It will sometimes catch mistakes. But the main reason I hear that people really like types is that it enables them to do massive refactorings using their IDE. And I think the massive refactorings are caused by the type systems.
01:01:00
Speaker
Because when I write closure code, I very rarely have massive refactorings, very rarely. I don't think that's because I can't do them because I don't have types, because I don't need to do them. I'm working with data, I'm working with pure functions, and there is just not big changes needed.
01:01:23
Speaker
Also, there are not enough big tightly interwoven structures that would cost you to make a huge refactoring. Exactly. But do you use anything for the... Because one of the other things that types bring in is if I can call it validation, making sure that the data that you're dealing with conforms to some sort of a structure.
01:01:48
Speaker
But do you use any tools for that, like specs or Mali? Let me start by saying that, luckily, nobody who's using a typed language has ever had a runtime exception. Because that's not possible, right? Okay, moving on.
01:02:15
Speaker
I don't use Spec or Mali or anything that inside my application, but I have been known to use it on the edges because integrations are difficult. But I'm sort of thinking that inside my program, if there are some extra keys there, I don't care.
01:02:39
Speaker
And I do write lots of tests. So I sort of feel like the tests are the place where I go to get the cache regressions and so on.
01:02:53
Speaker
including some integration tests, at least the happy days tests that I call it. And yeah, it's sort of, I feel like the way I work with code is a lot different in Clojure because you have the REPL there and you have the sort of
01:03:14
Speaker
direct access to the raw power of the data flowing through the system. I guess if you've been working with Closure for a while, you sort of know this feeling. All the data is just right there. So if I wonder, what's the signature of this function? What sort of data is being sent to this function?
01:03:36
Speaker
I am usually able to answer that in a matter of seconds because I can just turn on some scope capture stuff and just look at what's being sent. But isn't this putting, I'm just being obviously devil's advocate or just being for a.
01:03:55
Speaker
as a contrived example. Isn't this putting the responsibility into the design, the responsibility into the programmer? Because for me, it feels like when I'm writing in anger, like playing with Haskell or playing with Rust, that the compiler or the language is forcing me to do some things.
01:04:16
Speaker
and here you're free but at the same time we are saying make sure that your data is inspectable, make sure that your data you have pure functions but the language is not forcing me right and a couple of closure projects that I've been involved with have been to be honest like very fucking painful because
01:04:34
Speaker
the lack of the discipline. I'm not saying, you know, there are a lot of contextual issues, right? Maybe this is the first closure program that people are writing or whatever. But it seems like the guardrails that Richiki was talking about are not there in closure for me. On the other hand, I get all this freedom and the ripple and, you know, inspectability and
01:04:58
Speaker
all this raw power, as you mentioned, but at the same time, the other side of the, you know, a lot of power is a lot of responsibility. And it seems like the responsibility is on the design, is on the, you know, programmer themselves. Do you agree or do you see?
01:05:15
Speaker
I think you have a very good point. And I think this sort of boils down to how many developers are involved. Because if you have lots of developers, let's say, I know NewBank is doing pretty well, but I feel like if you have a small team, like now it's just me and Cristian working together, then you can rely more on people doing shit the way they're supposed to do them.
01:05:46
Speaker
Unless if you have like sort of 30 people running everywhere. But I would like to say just one thing about how Closure doesn't force this structure upon you. I think it actually does. It's just on a different abstraction level. It forces immutable data. And you can, and I have seen Closure code bases where you have sort of worked around that using
01:06:13
Speaker
And everything is sort of still in a mess of objects and the mutable data and luck. But if you sort of work with the grains of the language, I think you have sort of, you sort of naturally fall into the imperative shell functional core pattern.
01:06:35
Speaker
which is a beautiful way to work in my opinion. Is it like a good test for a new call basis to check how many atoms do you find? Then you can have you get one penalty point for each after the first.
01:06:51
Speaker
Yeah. From what I heard, Datomic has one atom. And if Datomic can do with one item, you can as well. Yeah, for sure. So I think like for if you're getting acquainted with a new code base, I definitely see the benefit of some typing at like the
01:07:15
Speaker
documentation at least yeah yeah it's just a quick quickly orient your way around yeah yeah but another thing so this is another case of the that i talked about before things that we have refined over time is i think we've gotten more uh precise with our naming for instance spend more time on naming now than i did some years ago
01:07:39
Speaker
And being very careful not to use the same name for different things. I've done that a lot. At least to use the same name for two almost same things. That's one thing we're actively working on avoiding now. I think using more namespace keys, use the tools you have.
01:08:04
Speaker
to impose some structure on your code base. And if you do these things right, of course, there's nobody helping you. You have to figure it out for yourself. But if you do that right, then I think navigating the code base also gets easier. Because whenever you see that, you know, here are some
01:08:24
Speaker
Whatever. I can't think of a single noun, uh, podcasts. Here are some pens and you know, Oh, it's pens. I know what pens are. Yeah. It's not those kinds of pens or those, it's just pens. Like if you can build a strong vocabulary in your code base, that will also aid in, in, in navigating it.
01:08:45
Speaker
Yeah, it does seem like some sound like a little bit like domain driven design, like you need to make sure that you have the right entities and bounds and contexts. Yeah, fair enough. You mentioned, Magna, that you use the raffle. Is that something that is still...
01:09:02
Speaker
It's funny how people evolve with the raffle so i'm interested in your sort of stories like when you're pairing or when you're working alone or whatever. Well how do you feel at the raffle like if you did stay are you still using it how much what part is it play in your soul of like a development process these days.
01:09:20
Speaker
I would say the REPL as sort of this buffer where I'm looking at the REPL and typing into the REPL that I haven't done for many years. Now the REPL is just, well, I'm using CIDR in Emacs. Actually, now we're using both LSP mode and CIDR together. And it's beautiful. But CIDR is sort of the purveyor of the REPL.
01:09:46
Speaker
and it's sort of the lifeblood of the editor. It's in the background. I don't look at it, but I can evaluate code everywhere. I can turn on my scope capture to get an example value wherever I'm
01:10:04
Speaker
constantly typing code into a common block at the end of every namespace, trying out stuff, just working with the code with very fast feedback all the time. And it's just, it feels like part of the editor more than a separate REPL for me at this point. It's interesting. What about yourself, Christian? Is it very similar or do you have a different sort of take?
01:10:34
Speaker
No, like you ask, have you left the rebel behind? I made big eyes because that's, uh,
01:10:43
Speaker
The REPL has become one of my favorite things about this language. A long time ago, I was a huge fan of test-driven development. When I discovered test-driven development, my excitement was about the same thing. I could write a small function and have it executed immediately in several different ways. This is amazing.
01:11:09
Speaker
And then when I discovered the repl, it's like, what do I want this test for? Let me just shoot in. When Christian said that he was a big fan of test-driven development, he actually wrote a book on it. Yeah, it was about us. Was it on JavaScript, or was it only on enclosure stuff as well? No, it was a test-driven development with JavaScript. Oh, pure. OK. Yeah. Nice.
01:11:34
Speaker
but now you only tell people just use code. No, I mean, I, we still have tests of course. And occasionally we also work in a test driven way. Uh, sometimes that, uh, is, uh, okay. But for the most part, like the repl took over that feedback loop for me.
01:11:55
Speaker
But I imagine like the advice in the book still stands for the JavaScript folks because they don't have that same feedback loop. So it makes sense. Yeah. Yeah, probably. But that's why I'm not so interested. But we, if you watch this prepare program on parents of the dead, you can see us writing plenty of tests. So it's, we haven't stopped doing that and we're still writing the tests. Uh,
01:12:21
Speaker
before we write the production code. But maybe in a lesser degree that it's driving the design, sort of test first instead of TDD. Yeah. And now we also, it's like sometimes writing your tests first is not as easy and then we still have the repl to lean on. So you have like good options either way.
01:12:42
Speaker
And also, again, from the screencast, you can see the way that we write the test. We're still using the REPL as for typing the test out. Okay, I want to call this function. What does it do? Okay, so I want to then pick up this thing. What do I get then?
01:12:58
Speaker
So the REPL is like part of the experience all the time, even when we're writing tests before the code. Maybe it's just a good moment for you to pitch parens of the dead, I think. Yeah, exactly. Yeah. Because we keep saying as if, as if, you know, it's many, maybe everybody knows about it, but there might be one or two people who are still doing JavaScript, you know, they probably need to know what this is.
01:13:22
Speaker
Let me start by saying we have been trying to sort of preach closure without preaching it because you can't sort of hit people over the head with you should be using this and that and they also get tired of hearing
01:13:40
Speaker
Oh, wow, this is so amazing. You have to try it. That doesn't work either. So how do we get more people into this amazing language and sort of the place that I feel like, at least currently, I won't hold Magna Nari in 10 years to this, but I feel like this is my place now. Closure in this community is my place. I want more people to discover what I have discovered, and I want to do it without
01:14:09
Speaker
Well, without preaching.
Clojure Screencast Series
01:14:12
Speaker
And the way that we are trying to do this here is just build something cool and let people be part of it. Come watch us code something. And we have done a couple of talks on conferences that are not Closure conferences, where we just start using Closure and typing out Closure without even making a big deal of it.
01:14:39
Speaker
Look, let's build something. Let's type the parents in the wrong place. Who cares? So Parents of the Dead is sort of the latest chapter in the story, where we're building a game from scratch. The entire screencast starts in episode zero, where we do MKDeer and create an empty depth seeding file.
01:15:01
Speaker
And you can watch this struggle all the way to a finished game. At least it's not finished yet, but we have, I think, 26 episodes so far. And also, I can guarantee that it will be finished because this season is like we already did this in Norwegian. And we finished the game. Then we figure out, wow, that's not a lot of audience. Should we have done this in English?
01:15:31
Speaker
You're like, well, we've only reached all the four Norwegians who are into closure. Not in closure, maybe. And also just because we did, I don't remember.
01:15:50
Speaker
Was it part of the screencast or not? We did like a parental live session at the conference last year. And then we had some colleagues come in. So it was the last talk of the day, I think, or next to last or something. So they had started serving beer. So people came in with beers and then a colleague of us handed out like small bags of candy to everyone who came in the room.
01:16:14
Speaker
So it's like pair programming and we're making actual things that work, but it's done in a light tone and it's supposed to be like mildly entertaining somehow. Let me pitch one more thing about Provence of the Dead, which is topical on top of it. The server-client architecture in Provence of the Dead is hilariously cool.
01:16:42
Speaker
It's not something that you can use for very many things, but it is sort of an idea boiled down to its very essence. And I would watch that screencast just for that architecture. Nice. It's of course based on data. Yes. So that's the teaser. That's the teaser. The teaser is come and see the data-driven architecture. Yeah.
01:17:13
Speaker
I think the client has, it has a one file with components and then it has about, I don't know, 20 lines of code. Yeah. And it's a fully like interactive client driven web game. It's pretty cool. Sweet.
01:17:31
Speaker
I'll make sure that I'll put the links in the notes. Just one more question regarding your Closure projects and the consulting work that you've been doing. Obviously, you both are well-versed in Closure and you know what you're doing and you design the applications.
01:17:49
Speaker
What happens when you hand it over to other mortals? What is going to happen to the code base? How do you educate them? How do you see the maintainability and the longevity given a few problems that we discussed so far?
01:18:06
Speaker
So far, I think we have left behind Closure teams. The common story almost is, wow, I can work with Closure there?
01:18:22
Speaker
And then they come and they work with Closure there and we leave. Pretty much. Except for maybe one place where no one wanted to maintain it. And that's still running. It's just the same old thing that's going strong. Because there's no breaking. There's no breaking changes. So it just keeps running.
01:18:45
Speaker
And, uh, yeah, but it should also mention that we're not actually consultants anymore. Yeah. We just, uh, just month and a half ago, we both took a job in the Norwegian government. So we now work there in the like, um, what's it called? Norwegian food safety authorities.
01:19:04
Speaker
Yeah, where we're hoping to build something of a what you call it some sort of a sort of a closure group or yeah. Yeah. So you're gonna you're gonna expand the beach has closure.
01:19:21
Speaker
Yeah what they have so they have like really understood product teams and and. Oh my god what's it called when the team can do what it wants. Yeah yeah and. Except talking about what what it is called.
01:19:40
Speaker
Autonomous teams and they have like free choice technology. So we said like, okay, so if we come here, we'll be doing closures. That's still cool. And they said, that's cool. And then we said, okay, we're coming. And so now we're building our stuff this way. Other people are interested and we're hoping that over time, you know, we can spread the joy.
01:20:03
Speaker
get other teams interested and ideally create more jobs for other people who want to work with Clojure to come and join us. Yeah. So you'll do more slurping than barfing. That's right. And also hoping to basically not leave our projects behind, like we want to stay with our projects and work on them long time. Yeah.
01:20:27
Speaker
Are there any other projects that you want to highlight or people should know about their OSS or some other things that you're working on? We have so many open source projects. They should go and check your GitHub profile.
01:20:44
Speaker
I think the most important open source project that the two of us have made, and Crystal mainly, is Hiccup.
Exploring Hiccup for Frontends
01:20:54
Speaker
I think that's sort of the way to do data-driven frontends with Clue for Script. Hiccup is very, very good, especially now that it has support for the data events. It's excellent.
01:21:11
Speaker
Super cool. Yeah. I'll mention. Let me just mention one more thing then. Yes. Yes. Because I also have a project called Portfolio. Yeah. Which was recently funded by Clojus together. OK. Yeah. Which I'm very grateful for. And so that's cool. You can check that out. That's it's like dev cards or a storybook or whatever. Yeah.
01:21:39
Speaker
Except it has more features. We've been using Dev Course since forever. It's like a great idea. And then I discovered that the JavaScript community had taken this idea and ran with it and created a storybook. It's like, what the fuck? Yeah, they can have better tools than we do.
01:22:00
Speaker
And then I tried like to be a good citizen and use it from like just use a storybook. Yeah. And to do that from ClojusKit was I just, after having written all the configuration files, I immediately realized that I'm not going to have the patience for this stuff. Nice. And then so I created my own thing. Super. And what state is it right now? Is it beta or is it already being used and people can start using it?
01:22:26
Speaker
Yeah, it's very fit for use. Uh, yeah, basically it does pretty much all the things that I wanted it to do. Uh, and then, yeah, but some work is happening on it, but like the main effort for my side, at least I think is, is done. So it's the idea is just to sort of, cause in my mind is in a storybook, basically as you write the kind of views and the pages and the, you know, essentially all the flow goes into the storybook.
01:22:56
Speaker
and then you plug in like the ClosureScript components afterwards. So how are you kind of like separating those two things yourself in your tool or aren't you? It's basically it's just a tool for you to render examples of your UI components. Oh, okay.
01:23:17
Speaker
That's it. You just, you take your components and you feed them with different data sets and you give the examples names and then the tool displays them for you. And it provides you with some tooling to look at basically. So you can change the viewport size to see how it works on mobile versus desktop. You can run split views and check it with light background, dark background.
01:23:44
Speaker
Yeah. So if you're working with a designer, that's the sort of thing that you would use. Yeah. And we even use it like it's a ClosureScript app that runs in your browser, but we use it also for our statically rendered Closure backends. Then we just create functions that return hiccup and put them in CLJC files. And then we use a portfolio to work on the components. And then we run them from the backend to render HTML strings, basically.
01:24:13
Speaker
Right. Right. Nice. Yeah. Yeah. Cool. Um, well, we're almost, uh, I think we have a little bit over time, but that's not the problem, I hope. And, um, yeah, big thank you for, for joining us, uh, all the way from, uh, from Norway. Thanks for inviting us. Yeah. It's been, it's been amazing. And I know there is a super vibrant community in, in, in Norway, especially for closure. And, you know, uh, Eric has been,
01:24:42
Speaker
doing some closure meetups there. And I should thank him for asking me to ask you to know more about more about this stuff. And I was very impressed by especially the humility and people who are so fucking smart and
01:25:01
Speaker
Although it's a tiny country and then you're doing, well, tiny as in number of people, obviously. It is tiny, yeah. It's tiny but long. Exactly. Yes. But hey, it's amazing to see and Magna obviously, thanks a lot for all the Emacs stuff and I've been a fan forever from the Emacs rock stuff and all the packages that you've been putting out.
01:25:28
Speaker
I'm not, I'm not an e-list packer in on any sense of the word, but I'm a copy pasting shit from people like you has been, uh, has been amazing for me. So nice to hear it's been amazing for me as well. Are you just admitting to each other that you're an e-list script kitty? I can, I can say I'm just a kitty there. I'm not, uh, I'm not a pro or anything when there are.
01:25:53
Speaker
vj.el in my thingy with a bunch of deaf advice, deaf hooks, and all that crap. But as you know, everybody's Emacs looks like going into somebody else's home and then somebody else's bathroom. You should check out the, like I mentioned earlier, when we started a new job, we decided that it's time to take some care with our Emacs config. So we rebooted it and it's on MongoDB's GitHub.
01:26:20
Speaker
And it's turned out really nice actually. We used some newer features in Emacs and you can actually read it and it's at least still at this point, one month in, is still quite tidy and nice. So you can check it out. I think one of the beautiful things that I noticed with all these Emacs, if I can call them distributions, is that
01:26:43
Speaker
I can just pick the parts. Oh, this is how they are doing it. This is super awesome. This is how I want the whole use package thing has been done in a different way here. So I can just copy paste it here. It's much nicer. I don't need to wholesale switch to the whole thing, but it makes it very easy to learn from all the Emacs gurus like you.
01:27:04
Speaker
You're building your own lightsaber. Mm-hmm. Yeah, exactly Yeah Anyway, thanks a lot my ground. Thanks a lot Christian for joining us and it's been it's been fun I'm sorry. I missed you guys when when you're in when I was in Norway Yeah, but I was very disappointed that celebrity like me appearing in Norway I feel insulted No
01:27:31
Speaker
that you're enjoying your life when I'm in Norway? No, that's not right. You'll have to come back and then we'll join you for lunch. Certainly, certainly. I'd love to come back. And again, thanks a lot for Eric. And especially I want to mention Frederick, I think. There is this young chap who works with Eric.
01:27:51
Speaker
It's one of the guys and then he, he met me and then he was like, Oh, this is amazing. I've been listening to your podcast when I was studying in London and there is still younger generation listening to this. So Frederick, if you are still listening, I apologize for the shit, but, but he's working in closure with Eric and, um, you know, um, it's, it's been an amazing community and, and, and I love the way that you are, you're, you're bringing closure.
01:28:16
Speaker
way I documentation and then even more stuff, even more stuff, and then letting people know that there are better ways to do things. And, uh, yeah, so it's an inspiration and I hope you're gonna make the entire Norwegian food even safer with closure. Safer and more functional. Sweet. That's it from us. Thanks a lot. Thank you guys. Thanks guys.
01:28:46
Speaker
Take care.
01:29:07
Speaker
If you'd like to support us, please do check out our Patreon page and you can show your appreciation to all the hard work or the lack of hard work that we're doing. And you can also catch up with either Ray with me for some unexplainable reason you want to interact with us, then do check us out on Slack, Closureion Slack or Closureverse or on Zulip or just at us at Deafened Podcast on Twitter. Enjoy your day.
01:29:36
Speaker
and see you in the next episode.
01:30:03
Speaker
you