Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
#26 with David Nolen aka @swannodette
53 Plays8 years ago
We talk with David about the mind blowing possibilities that have emerged with ClojureScript over the past few years and how it is set to rocket into the future.
Please check the web site for more detailed show notes
https://defn.audio
If you wish to support the show you can use Patreon
https://www.patreon.com/defn
Recommended
Transcript
Introduction and Guest Welcome
00:00:15
Speaker
So welcome to Defend, episode number 26. So we have been a bit slow in producing the episodes. These days we've been busy. I changed my jobs and Ray is also busy with his new job. But finally, we got the speaker or the guest that we were waiting for for a long time. We have David Nolan.
00:00:39
Speaker
Hi. Hello David. How's it going? It's going pretty good. Welcome to Devon. Really good. Thanks for having me. Thanks a lot for joining us because we did speak with you at Euroclosure in
Tool Preferences in Clojure
00:00:53
Speaker
Bratislava. That was just a quick 15-minute chat. I don't think you were speaking at that conference at that time, right? No, I did speak at Bratislava. I did. Oh.
00:01:04
Speaker
Maybe I see you in so many places and I'm getting confused. First of all, the most important question, do you use Emacs? I do use Emacs.
00:01:16
Speaker
I don't use it that much for closure programming but I use IntelliJ and cursive now but I still use Emacs for org mode and then of course a lot of people in the sort of closure like community use Emacs and so I often will if I have some tooling thing that I think is cool
00:01:40
Speaker
I'll figure out how to do it in Emacs. So a lot of the things that I do work in either Emacs or cursive and intentionally so.
00:01:49
Speaker
Well, you bridge the gap between me and Vijay then because he's an Emacs guy and I'm a cursive guy. So, you know, if you can be the guys, if you can be on one side of a tool or another side, we're going to talk about being on one side or another side to do with politics as well,
Is Technology Political?
00:02:05
Speaker
won't we? I mean, you know, I guess if any if an IDE can be politics, then anything can be. Yeah, so I was going to open it up a little bit was talking about these people in front of the Senate this week.
00:02:18
Speaker
who were defending themselves against Al Franken, which is a bizarre concept in many ways, that Facebook lawyers and Google lawyers and Twitter lawyers need to defend themselves against an ex-comedian. But they were essentially admitting that their tech was used to essentially send out foul messages to the electorate in America.
00:02:46
Speaker
last November and that they were really going to be, it was very difficult for them to detect these foreign actors. Although, you know, paying in rubles and coming from Russia and doing political adverts apparently wasn't a good enough signal for them. So the question really was, you know, is tech political? I mean, you know, I think it is, I think you think it is, maybe it's Vijay thinks it's, I don't know, maybe we could just start with that one.
00:03:10
Speaker
I mean, I just don't see how it could not be. I mean, tech influences everybody's lives and it's only having a greater and greater influence.
Social Media Regulation and Ethics
00:03:23
Speaker
The situation with Facebook, Twitter, and these other social networks has shown that people get information from very different places in traditional media now, enough so that you can have an impact. And those channels are not nearly as regulated as traditional media. I actually come from a
00:03:46
Speaker
radio television film background and so when I went to school for that, of course, we talk a lot about the history and why regulations were put into place and all this stuff and certainly there's always somebody looking to make a buck, right? Some of the regulations that somebody wants to make a buck. But then I think that there is a significant amount of regulation that is also about
00:04:09
Speaker
that is in the public interest and I don't think we have that. Things have changed so quickly with social media. I mean I don't know what the answer is but I definitely think that
00:04:24
Speaker
We've seen at least one effect from having a very different way for people to get information that isn't nearly as regulated as other channels in the past. I saw this. There's a book by Cathie O'Neill called Weapons of Math Destruction.
00:04:41
Speaker
which is a beautiful title if nothing else. Her argument is that actually the problem with social media and in general and these ML environments in general is that
00:04:56
Speaker
The algorithms themselves are not even explicable by the people that write them. So one of the problems that we have is that we need to be able to be transparent about the production of these algorithms so that
00:05:12
Speaker
If there were any regulations if there are any discrepancies or any problems if there if these algorithms surface some bias and we've seen that you know there's a there's another lady called joy below me who does research at my tea about biasing algorithms.
00:05:29
Speaker
And she's got a group called, I think it's called the Algorithmic Justice League, that is about saying, how do we get these algorithms to be made more transparent? And I think that, like most regulations, I think transparency is often a key to these things. I mean, that's true.
Ethical Responsibilities in Software
00:05:52
Speaker
I definitely think
00:05:56
Speaker
I mean technology definitely has this problem which, you know, people, I mean technology is neutral only in the abstract. The problem is that technology by itself is inert. It's people's use of technology that often introduces the problems and you design an algorithm and, you know,
00:06:20
Speaker
A lot of times bad stuff happens not because anybody's malicious, just because they have a certain viewpoint about the world and that gets encoded into an algorithm and they don't really mean to mess everybody up. When you deploy that to 10 million customers, your decisions have a pretty big impact.
00:06:39
Speaker
So the classic one was Microsoft, wasn't it? Recently, you put this bot out there and that bot suddenly started spouting racist fascist, well, started shouting, sort of tweeting Nazi stuff within 24 hours.
00:06:54
Speaker
The population went on to it and started training it basically to repeat Nazi sentiments. So it was very easy to show that these algorithms were done basically.
00:07:11
Speaker
Well, and then I would say it's not so much the algorithms are dumb, it's that when people decide to put something out like that, you would have thought that, okay, let's talk to people who have some background into the humanities or ethics or who could have easily told you that like, or even somebody who had like a passing background in game theory, they could have predicted what was gonna happen.
00:07:38
Speaker
You can't expect that from a multi-billion dollar company like Microsoft or David. I mean, come on, be fair. But I think that's often the issue. People don't think of
00:07:54
Speaker
definitely think in the future, I think software engineers will have to consider themselves to also be, you know, in some sense, citizens of whatever state they belong to, and that the decisions matter, and they're really not you're really not in a vacuum. I mean, you know, it's like, before we were doing tech, if you were an engineer, and you know,
00:08:15
Speaker
You have to make decisions. Yeah, you have to feed your family and whatever, but maybe your job is to make bombs and you have to decide. Is that how you wanna make your money? Yeah, yeah, yeah. Building gas ovens was very popular at one point, but it seems to have gone out of business now. And all I pointed there is that everybody has their own calculus for this, but it's just, I think as software engineers, we have to begin to realize that the question is much more like,
00:08:44
Speaker
Is the thing that I'm doing going to have a negative effect on reality? Yeah. Yeah. That's an awesome point,
David Nolan's Journey to Clojure
00:08:50
Speaker
actually. Yeah. I think I saw a talk by, what's it called? The clean coding guy, Bob? Yeah. I can't remember his second name now. Anyway, clean code Bob. Uncle Bob. It's his first name, actually. Yeah. Uncle Bob. His first name is Uncle, his second name is Bob. Yes.
00:09:08
Speaker
I saw him doing a talk about the software code of ethics thing. I think some of his things were a bit off, but I think in general, I think it's in the air, isn't it? I think you're right, David. It's in the air to have some kind of thought process about whether or not you're having a negative impact. Likewise, what are you going to do about it? What are the choices that you can make?
00:09:33
Speaker
Okay, so on that bombshell, let's get back to closure. We're all making choices all the time, buddy. Indeed, indeed. Because I see this one a bit more questions of morality and technology as David was pointing out is just a tool so you don't know what you want to do with it. And whatever you do with it is reflecting your own morality, your own ethics and all that sort of stuff.
00:09:59
Speaker
By the way, if you're an employee of a company though, then where do you stand in that situation? You're working for people, you're working with people. How do you judge? That's the tricky part, but I don't want to go into that discussion too much because it might end up in whole discussion about philosophical choices and all that stuff. I think philosophical podcast is probably a nod in my zone, just like I'm not a right-wing intellectual as somebody was pointing out.
00:10:28
Speaker
On Twitter, I told him, dude, I'm not even an intellectual. What the fuck is right wing? I don't even know what that is. Well, we've got to clear that up at least. I mean, I think that is vital. Exactly. Yeah, yeah. And then they accused me of not using Emacs. And then I told him, I have to send a screenshot of my right now on my desktop, what is there, which is basically Emacs. So that cleared everything up. So it doesn't matter. Oh, he uses Emacs. So he must be good. So at least for the internet.
00:10:57
Speaker
But anyway, so David, first, so I think we should on that philosophical note. So who is David? So we need to come back to deeper questions. How did you make your choices, David? Yeah. How did you come to closure?
Contributions and Practicality of Clojure
00:11:12
Speaker
How did you because I know you were working at N.Y.T. at some point.
00:11:15
Speaker
Yeah, but that was so closure was I was it was I was working for a startup and I The startup thing ended and I had I decided to take like a three months sabbatical This was like 2008 at that point. I was just like sort of like an independent consultant doing, you know, whatever software things came to me and I was like interested in in lists because I done lists and
00:11:40
Speaker
For fun, like in 2003, I did structure interpretation computer programs in a 6P. That seemed pretty cool, but nobody seemed to be using Lisp. Then around 2008, I was on Hacker News and there was all this excitement about Common Lisp and Paul Graham had this thing called Arc.
00:12:02
Speaker
I played around with those, but they didn't do quite what I wanted. I couldn't really see myself doing actual work with that stuff. And then I found a website that had this thing called Closure, and I'd done quite a bit of Java and JVM stuff, and I was like, let me see how long it takes me to get this up and running. Because I'd messed around with
00:12:22
Speaker
a common list like SPCL and back in 2008 getting SPCL running was like massive pain in the butt. And then I downloaded this jar and in like, you know, five seconds I had a REPL and so I was like, okay, I'm going to use this. That was it. It was just, I was just looking for a list
00:12:42
Speaker
That seemed like I could actually maybe use it for something, like for work. That's how I encountered it. Closure was just a hobby for me. I worked on some open source stuff, which people are probably aware of like Core Match, Core Logic, and all this other stuff. And while I was at the New York Times, ClosureScript got released and I started contributing to that.
00:13:03
Speaker
And then I left the New York Times in 2014. I got hired by Cognitec to work on various things. I spent some time on Datomic. And then, of course, I was also hired to basically spend a significant amount of time developing ClosureScript itself.
00:13:19
Speaker
Yeah, so Lisp brought you to Clojure, and what made you stay? So what are the features that, not just the features, but what is it about the language that made you stay and then take more and more effort on your time to spend on ClojureScript? I mean, I was already pretty, because of, you know, a book like Sickpea sort of like,
00:13:47
Speaker
get you thinking functionally. Also, the nice thing about sick pee is that it sort of shows you that languages are something that people built. They're not really like, programming languages aren't really, they're not really mathematical constructions. I mean, this is something sort of like when I was a young programmer, I was like, you know,
00:14:07
Speaker
that came down from the mountain on tablets, C++. You think these committees were foreign by geniuses, but really it's just people, they're choosing some semantics and then of course they're making a programming language to the real world and anything that has to touch the real world is a big mess. So real programming language is just big messes.
00:14:27
Speaker
and sick P was like kind of eye opening for me because it was like oh with scheme you can do operator program you can do functional you can build you can do logical programming I mean logic programming and it just it just showed me that with the very loose a very tiny core
00:14:45
Speaker
Lisp had all this sort of expressiveness that you needed to do whatever you wanted. And so that was very exciting to me. And so I would say that's definitely what that closure had that part, had that part of Lisp that I liked, which was it's a fairly small core and it's very malleable. But really what kept me going was just that, I mean, to be honest, closure ran on stuff and I could see myself using it, right?
00:15:13
Speaker
The JVM's not going anywhere. And then with ClojureScript, JavaScript's not going anywhere. So, I mean, I could use a language with its own runtime, but...
00:15:24
Speaker
It just doesn't seem practical if I want to use a fairly cutting edge programming language yet at the same time I want to get stuff done. I think Closure is still totally owns that sweet spot. I haven't found anything else that is both interesting as a programming language and yet at the same time I can just do real work with it.
00:15:53
Speaker
use very popular technologies without really making a mess.
00:16:01
Speaker
I think actually, I mean, this is the point you made there about getting, you know, having getting started in five minutes. I think, as I mentioned to you, you know, pre-show. In the green room. Yeah, is that, you know, I've started to do some enclosure script as well myself recently. And I found it in, you know, honestly, a couple of years ago, it wasn't a five minute starting.
00:16:29
Speaker
five-year thing to start out. But really, these days, it pretty much is.
ClojureScript Accessibility
00:16:34
Speaker
It really is. You just download a few bits and pieces. You follow the reframe readme, or you follow some other readmes, and bam, you're off. And I've been using it in the browser. I've also used it with Node.js and the CLI. And it's been pretty sweet. It's been really sweet to get started and to make stuff happen pretty quickly.
00:16:56
Speaker
So kudos to you and to the team that's made that happen, I think. It's been really good. You know, we're definitely, you know, I think we like you say you started there with closure, it was five minutes to get started. And I think we're in on parity now, if not, you know, if not even easier in some ways with ClosureScript, because you don't have to install a JVM anymore. So I really think it's, you know, it's at least there, if not better. Yeah, yeah. So I mean, I agree. It took a long time. A lot of that has to do with
00:17:26
Speaker
I would definitely say it's still the case that ClosureScript is mostly about reaching clients and that's what most people are using it for. But I definitely think with the increasing interest in Node.js and the fact that we can bootstrap, React Native,
00:17:46
Speaker
You know, this is all this stuff. Like, you know, there's like somebody who has a, there's a whole bash like shell now enclosure using, which is, I mean, people are, people are going like, it's, I knew this, like when we did bootstrap two years ago, I was like, this is, this is going to be a thing which people are going to run with for a very long time. And it's more, it's more or less happened, right? This people are really going, doing, I mean, this, and if this is nothing,
00:18:12
Speaker
I don't work on that stuff. This is just community effort and goodwill. It's really amazing to see all the stuff that people are building, whether it's tooling frameworks or these really cool self-hosted things.
00:18:29
Speaker
So before we get into all the libraries that you built, of course, discussion about OM and the other things about ClosureScript, I was wondering, have you ever played with different types of languages other than
Dynamic vs Statically Typed Languages
00:18:45
Speaker
Closure? Because there has been a lot of discussion these days about latest Rechiki's talk about static and dynamic thing coming back again.
00:18:53
Speaker
This seems like a holy war that goes on for our network like we are any max stuff. So did you play with any static languages and what is your opinion on how closure sees the world compared to Haskell, for example?
00:19:06
Speaker
I mean, the only languages, I mean, I would say let's, we have to like differentiate between like languages I've used in anger, which means I was angry at some point and I had to ship something. Right? That's like, that's like, you know, there's like, it's like, it's so true. I mean, the languages that people hate and the languages that people use, right? That's just a true, that's like a truism, right? But the only languages I use that had types that I actually had to use for work were things like Java or Objective C or C++.
00:19:36
Speaker
So, those are all nominal typing. You have to give it a name and the names have to match. There's some annoying rules around inheritance and all this stuff. And then, of course, Java has generics, which is like generics actually came from type functional programming.
00:19:58
Speaker
But I've never had to use type functional programming languages in anger. I've dabbled in Haskell, StandardML, OCaml. I've played around with them. They're neat. But at the same time, I mean, for me, those StandardML, OCaml, and Haskell are like non-starters because, again, I'm not...
00:20:20
Speaker
Most of the stuff that I do is on the JVM or I want to use JVM based technologies. So I don't, there's no reason for me to use that stuff. The only other option would be something like Scala. But Scala is, and I think Scala is impressive. They've done an amazing work around that. It's very, it's very cool. But I'm happy with closure. I don't, I don't, I've never felt the need for
00:20:50
Speaker
I mean, to me, static typing is never a thing that I'm clamoring for. My experience so far in software development, everybody's experience differs. It really depends on, that's the thing, is people want to blame programming languages. They never want to blame themselves, right? Obviously. That's a good question. Call it things all over again. Software engineers never want to blame themselves, or they don't want to blame, you know,
00:21:17
Speaker
the management, all the things that actually make software projects fail, which I guarantee you it's not usually the programming language. It's whether there's a good testing methodology, whether you've thought about failure modes,
00:21:35
Speaker
continuous integration. And when it comes to UI stuff where I've seen tons of messes in every freaking programming language, there does not exist a programming language where you cannot make a mess when you do UI work. UIs are inherently like, they involve a lot of incidental complexity because generally for any non-trivial UI,
00:21:59
Speaker
you just need to at least be able to be able to model sort of complicated states. And my experience is that the biggest messes in a code base are just, it's just bad designs. And no amount of compile time checking is gonna fix your horrible design. You can make a mess even with all your compile time checks. And I don't really, I mean, there are a lot of people that, well, are like encode more stuff, more stuff, and I'm just like,
00:22:29
Speaker
It doesn't seem... As far as I can tell, I've seen no evidence that this actually works at scale for UI work, which is, again, that's where most of my focus has been, and that's where I've seen things get really hairy. I've never seen any evidence that that stuff matters for that type of work.
00:22:49
Speaker
And then I'm not convinced that like I mean to me like often when I see people do lots of crazy type stuff I'm like it just feels like over and over engineering in Java when you're in it when you're in a Java type base with checked exceptions And you know rampant use of generics, and you're like this sucks. Well. It's the same thing It's not it's just an over engineered mess so
Performance and Language Choice
00:23:13
Speaker
Yeah, I don't know. All I'm saying is it's just my experience and I've never had a convincing experience with this stuff. I think the people on the UI side that are probably the best arguers for types.
00:23:29
Speaker
And it's the only really proper people I've seen arguing for types on the UI side are the people who are doing game programs who want to have the compiler to do lots and lots of optimizations for them to get the best possible raw performance from the hardware.
00:23:46
Speaker
Yeah, those game guys really want to exploit the low level C and even C actually an assembler sometimes, which is not typed, obviously, but yeah, it's true. But I mean, you know, there you're talking about something which is like, you know, it's this other thing that people like types for, which is
00:24:05
Speaker
having access to primitives, whether that's numerical primitives or some sort of machine representation, certainly with languages like
00:24:19
Speaker
Haskell, you know, if you have the type of information you can eliminate boxing and all this stuff So I think that's a compelling argument, you know, if just like getting every last inch of performance That might be a case for it. But the truth is is that I
00:24:38
Speaker
There's all these best-selling games on iOS and they write that stuff in Unity. Unity is running on this crappy version of a C-sharp compiler without all those fancy optimizations that Microsoft has done in the past six or seven years or whatever it is.
00:24:56
Speaker
And people write perfectly fun games. So even then, it's like, what problem are you solving? And does that problem actually benefit from this programming language choice that you're making? Actually, the guns.
00:25:14
Speaker
I think it's the perspective, right? Because I remember this argument can be taken from both sides because it's like, OK, probably this is attributed to Steve Jobs or some other internet folklore. It's like, if it is beautiful outside, is it beautiful inside? That's the question. So of course, I can make an amazing application. But inside, does it conform to my sense of beauty or my sense of what
00:25:39
Speaker
what a good program should look like so for me it feels like if you are coming from this mathematical background that you know that the world is like properly structured in a way and then I'm going to represent it in much more mathematical sense then you lean towards going to the statically typed languages or these kind of things
00:26:01
Speaker
But of course, then again, you need to do a lot of workarounds to represent the real world. Because this is something that when I was in school, they explained there are only nine types of species or nine types that you divide. And then suddenly there is one exception and two exceptions and three exceptions. And then the real world doesn't conform to your classification anymore. And then you need to invent new ways of representing it.
00:26:25
Speaker
So i was thinking it all depends on individual perspective and some people see beauty in lisp some people see beauty in dynamism and some people see you know it conforms to your perspective.
React's Impact on State Management
00:26:39
Speaker
Absolutely i definitely think that's true i mean.
00:26:44
Speaker
I definitely think subjectivity plays into it, but at the same time, there's also something to be said where I also think that programmers are often blind to what causes issues in software. I recently spoke at ReactiveConf and I've revisited that paper
00:27:03
Speaker
by Ben Moseley and Peter Marks called Out of the Tar Pit, and that was written in 2006. And he really points out that state, like unmanaged state, they point out unmanaged state really just makes everything more complicated.
00:27:19
Speaker
And a great case in point where people are like, there's no proof that React is better, but why did React take off? And people could say it's just marketing, but that's like bullshit. The reason React took off was because React is much more disciplined about state, right? So even though there's a learning curve, there's a learning curve, tens of thousands, at this point not hundreds of thousands of JavaScript devs,
00:27:46
Speaker
They were using jQuery, and then they used React, and they spent a week on it, and they realized, oh, if I do less stateful stuff, it's easier to understand what my program is doing. So even though people had to experience it in order to determine that, I could never say, if I said this four years ago, it's easier if you manage your state. Everybody would say, that's not true.
00:28:12
Speaker
And now they use React and they're like, oh, it is true. But there's no proof. There's no mathematical proof because the world is messy and it's only through experience that you realize how do we manage the messiness of the real world? And that often doesn't bottom out in anything that I can prove to anybody.
00:28:39
Speaker
I think it's interesting, isn't it? JQuery didn't evolve because it was inherently a beautiful thing. It only became popular because the concept of browser doms was annoying. Basically, it was a way to neutralize the browser wars from a JavaScript perspective.
00:29:00
Speaker
It was also doing CSS type queries, but that's only partially true. So like if you actually understood jQuery, what did jQuery try to do? So jQuery did two things. One thing it did was try to paper over all the the incidental complexity of the differences, the arbitrary difference between browsers.
00:29:20
Speaker
That was just what it initially did. And later, what it did was it allowed you to do less stateful things. It used to be, before you use jQuery, that if you wanted to have an event handler, you'd have to attach the event handler on every event, on every single thing that's clickable.
00:29:39
Speaker
And later they had this aversion of event delegation, because the problem is an event listener is stateful. You have to attach it, and then you have to remove it. And then if you blow away the DOM and you forgot, then you have a leak, right? So there's all this stateful stuff that jQuery. Yeah, but the first version of jQuery did not use closure. It didn't use closures. It used to a global state, actually. That's the weird thing about jQuery. It was completely polluting the global state at the beginning. It was, but my point is that
00:30:09
Speaker
Even though people used it and they talked about these words, what it was doing for them was it allowed them to add some state management that they didn't have before. But he actually discovered closures after Doug Crockford, I think, explained them to him or write the book because his first version didn't have that kind of encapsulation that the letter versions had.
00:30:35
Speaker
So it was definitely an accident that it became popular to the Dom stuff. And then, yeah, you're right. He definitely cleaned his act up.
00:30:45
Speaker
That was on the back of his previous success, I think. But it doesn't matter. What the fuck? Who cares? The point is that it was basically about browser wars and then, like you say, managing state. But React was really, wasn't it about the Facebook saying, well, we've got these complex apps now. We have really complicated apps that React needs to be built for.
00:31:09
Speaker
Not really. React was created by one developer. One developer was this guy, Jordan Walk. He was working on a backbone app for one part of Facebook with, I think, maybe two other devs. It was a typical NBC app where you had stateful models, views, and controls. And he was coming from a functional background. He has a background in OCaml.
00:31:31
Speaker
And he was, I'm going to do this crazy idea where I do a virtual DOM thing and I'm going to functionally update the DOM and create a functional API. And React was actually in its niche first year not used at all at Facebook. Almost everybody at Facebook was like, that's just a weird thing. Let's open source it. Let's see what other people think.
00:31:53
Speaker
So React was not popular internally. Even React Native, when it came out, was very controversial. So this belief that Facebook had a unified front around React is just not true. But they sell it themselves, actually. At their own conferences, they say ReactJS was actually a kind of spinoff from our general React concept. They say that at their conferences.
00:32:18
Speaker
I mean, I mean, I know the people that developed it. It was one developer and they struggled. They struggled to get to get uptake within the company. Yeah. Well, we need him before the Senate next time. Yeah. Well, yeah. Okay. So that's fine about, I mean, but it definitely was there to try and solve this problem of more complicated applications. Wasn't it? It was, you know, it was to try and wrangle that state, like you say. Yeah.
00:32:47
Speaker
I think not necessarily because I think React actually has issues in more complicated applications. You need other abstractions. I mean, that's why people like Reframe because Reframe gives you more tools than React does out of the box. But what React does is it solves one particular problem. It eliminates the stateful DOM. Semantically, you no longer have to think of the DOM as being stateful. And that is a massive simplification. You can just use it declaratively, yeah. Yeah.
00:33:15
Speaker
So I think we're talking about React, which is a nice segue to get into this closure script, essentially using React.
React Integration in ClojureScript
00:33:26
Speaker
Because apart from Hoplon, I don't think there are many other closure script
00:33:31
Speaker
So there was some discussion about how to use jQuery stuff at some point, but I think more or less at large the community has owned or adopted React to be our back-end, so to speak, for the front-end or middle-end or whatever.
00:33:47
Speaker
So what do you think of this trend? Because I remember you started your blog post about React that was the initial, the first look into this thing from ClosureScript as well. And then that snowballed into I think sort of like 20 or 30 React plugins or React frameworks using ClosureScript.
00:34:10
Speaker
So what is your opinion on these things and where did you see OAM and then where do you see OAM in the future in this landscape? I mean, yeah, initially I was just, it was just that React presents a functional API. So one thing that was missing for ClosureScript was that none of the UI things were very functional. jQuery is not functional. Backbone is not functional. Ember is not functional. Angular is not functional. Google Closure Library is not functional. None of these things were functional.
00:34:38
Speaker
React was the very first framework that was written for JavaScript people that we could adopt it and the integration could be very clean. Anybody that's used Reagents, it's mind-blowing. I can write functions and functions make the UI. It's this beautiful world. I'm just writing plain old functions.
00:34:59
Speaker
Can I get to see stuff in the browser? All the stuff that you don't want to know about, you don't have to know about. To me, it's no wonder that it just blew up. Within four months, everybody in ClosureScript was using React. We were adopting React before JavaScript was adopting React.
00:35:19
Speaker
Yeah, because for us it was just so obvious. It was just the right way if you're coming from a functional standpoint. I'm glad that it was obvious to the closure community. I'm happy to see so many different versions. To be honest, I don't really care about these. There's a bazillion of these
00:35:41
Speaker
integrations around react and I think it's great. People want to do it however they want as long as you're doing it that way it's going to be better than whatever you were doing before. I did OM and OM was of course an experiment you know in the sense like I didn't know exactly how it's supposed to work
00:35:56
Speaker
There was an initial version which had this cursor thing, which actually, that idea was adopted in JavaScript. You have, you know, people use Redux with cursors and all this stuff. And then I did om-next, which was kind of a reaction to GraphQL, Relay, and Falcor, and these other JavaScript things. And then trying to think a bit about full stack dev, where there's a tighter integration between the front end and, say, a database like Datomic, which is like a functional database.
00:36:25
Speaker
But people are using, people use OmNEXT. I actually don't have that much time to work on it, but fortunately there's been some good devs. There's also been Tony Kay, which I believe was also on this show. And he's been working on Full Crow, which is really cool, which is like very much like a, in some sense, a much friendlier cleaned up version of OmNEXT. He's doing great stuff and I think he has some new stuff that he might probably be doing and probably hear about that.
00:36:52
Speaker
But to be honest, when I made OmNEXT, it's great. I'm happy that people use it. I'm happy that people are having fun with it. But to me, more important than using it is understanding why you might want to design a system in this way.
OmNEXT and Future UI Architecture
00:37:08
Speaker
And for example, I've worked on several client projects where
00:37:11
Speaker
for various reasons, we didn't use omNEXT, but we just adopted an omNEXT architecture, right? We did the exact same thing. We had Datomic in the back end, we had queries in the front end, and it made for a radically simpler code base. I mean, the entire logic for talking in the back end in that system was like, maybe it was 200 lines of code, and we just had a bunch of declarative queries where we would do Datomic pull on whatever data that we needed.
00:37:40
Speaker
And it was great. I mean, it was one of the cleanest front end things I ever worked on in my life.
00:37:47
Speaker
Nice. And where is omNEXT going then? I mean, where are you taking it to? So there's nothing. I mean, people have asked that question. There's nothing. I have no new features in mind. There are some things about dynamic queries, which people are talking about, which maybe we'll think about that. But I'm unlikely to tackle that anytime soon. Maybe in the near future, maybe some spec integration. Now that spec is starting to, it seems,
00:38:16
Speaker
probably in the next six months, at least the current version is gonna probably settle down. So, but excuse me, that's all I have in mind. I mean, I'm not, I mean, my experience was that Ohm Next does plenty. It does plenty. I don't know that it needs to do more than what it currently does.
00:38:38
Speaker
But do you think this ideas that Ohm Next has right now with the GraphQL and with the way the UI is being built, is it, what is the longevity of this one? I mean, because I'm interested in where are you looking at, because that's what I really liked when you started Ohm, that was a completely different view on how to build the UIs. Obviously, you give talks about it, standing on Jane's shoulders, et cetera.
00:39:06
Speaker
But still, because you have the visibility into the future, you're able to see this is how it should be. So do you see any other experimental ideas that are going to come up in this direction? I don't, but I'm also like, I'm very, I also think,
00:39:23
Speaker
I think it's going to probably take three or four years for people even to switch over to what I'm talking about. I do go to JavaScript conferences and you see GraphQL is slowly but surely taking hold.
00:39:39
Speaker
I think this is already pretty radical. It's radical enough of a change and in some sense it's a bit invasive because it requires buy-in from back-end developers to change their thinking. This is not a simple change. It's kind of like a holistic decision.
00:39:57
Speaker
So I think that it's at least a few years, but I'm also convinced that it's basically the future. I think people that want to build simpler systems are going to basically be building GraphQL-like systems.
00:40:10
Speaker
But isn't it something like, as you said, if you want to switch to GraphQL-based systems, then obviously you need to have the buy-in from the whole system. But isn't that the idea of fundamentally REST was trying to stay away from? You have this separation, and then we have this API, and then you let any kind of client talk to us. So how does it differ in terms of that kind of architecture?
00:40:36
Speaker
I mean, rest to me is like, number one, I don't think rest is very important. And I definitely think that the way people design current APIs is just broken with respect to clients. There's not much good about it. And really, this is not just my opinion. This is the opinion of companies like
00:41:00
Speaker
Facebook and Netflix there's all these people that are that are adopting this more flexible client driven design Because it removes it removes complexity it removes from complexity from both the front and the back end because clients can request whatever they actually need and then you don't really care about You don't need this all this time spent on a Pointless API design
00:41:30
Speaker
Yeah. So you think it's a bit more like a type system versus a dynamic system in that respect? Because there are some fundamentals in a graph. Obviously, you have to know what the edges are. You have to know what their relationships are. So there is some design going on there, isn't there? But you have to know this anyway.
00:41:54
Speaker
No, of course. Yeah, absolutely. Whenever you say that, you're like, well, I have to know what the rest response returns. I have to know what fields are there. I have to know what sub-entities are there. You already have to know that stuff. It's just that now I can friggin' describe it.
00:42:13
Speaker
I don't have to just eat whatever you give me. And you can limit it. That's a nice thing. So I think people are sort of like, they're not being self-reflexive. It's already the case that rest forces you to think about all these things, but it's inflexible.
00:42:33
Speaker
I think the thing that came up on top of REST was this JSON API which allowed you to do thinning of the objects and also to do queries. So I think the REST, there was a compromise definitely in that sense around this JSON API and I think Microsoft and Salesforce had this other thing. I'm blanking on it now.
00:43:01
Speaker
but it was a kind of queryable rest, as it were. Yeah, yeah. There's been quite a few things since GraphQL where people have come up with rest-like designs that are like GraphQL. And to me, it's like, it doesn't matter, right? It doesn't matter if it's GraphQL. It doesn't matter if it's Falco. It doesn't matter if it's augmented rest. It's all the same thing. It's an architectural design.
00:43:26
Speaker
We're not talking about the concrete technology. The point is that clients need to be able to describe what they want. Who cares how you accomplish that? Yeah. So what was the thing that you were talking about, spec? Apart from just saying the shape of the queries or the shape of the results, is there anything more deeper in spec that you're interested in exploring?
00:43:50
Speaker
Not really. It was really just about like, there's a nice feature in React where you have this thing called props validation where you can basically say the structure of the thing should look like this and you get validation. And basically by adding specs, if you did something wrong, you would get a nice descriptive reason for why the values that were passed into a component aren't correct. It really was no more complicated than that. That's plenty already, yeah.
00:44:20
Speaker
Yeah, okay, cool. Okay, so I'm going to move to the community questions because we tweeted out, you know, asked everything. And then there were a lot of people asking about WebAssembly, like, okay, what about WebAssembly? And if someone built a GC for WebAssembly, could that be sufficient? Are there any other blockers? I mean, what is the future? Well, number one,
00:44:45
Speaker
Writing a GC in WebAssembly. First, somebody would have to demonstrate that you can compete with the GC in the existing JavaScript engines, which at this point, they are state of the art. They're very state of the art. I'm skeptical that you could compete.
00:45:06
Speaker
So there's a performance hit there. So that's really the big thing. Until somebody demonstrates otherwise, I don't think you can achieve the performance that's necessary. You have to also remember that the GCs in browsers, they interact non-trivially with the browser itself. Because generally, there's some form of garbage collection for the DOM, and that's different from the one for the JavaScript engine. And the way these two things interact is non-trivial.
00:45:35
Speaker
whatever decisions you make, they all affect latency.
00:45:38
Speaker
So I don't really see that going anywhere. That said, we'll see. I mean, there recently, what was more exciting to me than WebAssembly, to be honest, was a proposal by the WebKit team to add shared memory concurrency to JavaScript Core. And I'm more excited about that because we already have written functional data structures.
00:46:08
Speaker
that would work well for us and we could then deliver all of Closure's concurrency primitives in the browser. That to me is way more interesting than Wasm at least at this point. So that means bringing not just Atom but other things as well.
00:46:23
Speaker
Everything. Basically, what WebKit's proposing, it's like shared memory concurrency with locks and everything. We could just replicate all the other concurrency stuff. Exactly. That's right. I would say Wasm. We'll see. Concurrency stuff. More interesting. Talking of concurrency. When is your next album coming out? Before we go on to this album.
00:46:55
Speaker
Okay, what about I mean, because some of the things that are interesting in terms of concurrency are these web workers on the browser side. Is that something that you've thought about in terms of how we could make that a bit easier to exploit? So web workers, they let you do a certain type of
00:47:16
Speaker
thing. So web workers are message passing only. You can't share data. They have this thing like this shared buffer thing, but it's really not that ideal, especially for ClosureScript. And then from a development perspective, it's really a bit annoying because you have to build your project for
00:47:37
Speaker
such a way so that you can reuse your code in the web worker and in the main page. So it's not, I would say it's not the most ideal thing. I mean, for some things it works, but it is not, for lots of things that you'd want to do, closure style concurrency, it doesn't solve that problem. Why? Okay. So Core Air Sync is just a better answer in general, at the moment, at least.
00:48:07
Speaker
Yeah, yeah. I mean, absolutely. If all you want is just, you know, you want to be able to break up your work into asynchronous tasks, Core Async is great. Sorry. No, it's okay. We still have plenty of questions, you know? Yeah. So somebody was, you won, I think. So he was asking, if you couldn't write Clojure script, what would you use? If I couldn't write Clojure script, I mean,
00:48:36
Speaker
Most of the things that are out there, I mean, I follow the compiled JavaScript languages quite a bit. I mean, I think Elma is really cool. I think Reason looks like it's getting some interest. Reason, which is the Facebook OCaml thing. You've got...
00:49:03
Speaker
ScalaJS, which is coming along quite well. Actually, ScalaJS is particularly impressive because it really feels like you have all of Scala, but you get to do browser dev and it's come a long way. It's very impressive. But as far as what I would use, I mean, it's really...
00:49:23
Speaker
I love ClosureScript. I've been working at ClosureScript for six years. I think you can say that's why a bit of ClosureScript. What would I use? I spent six years on this, so I don't have to use anything else. That's the whole point. If someone took away ClosureScript, you'd just write it. That's probably the best answer. Exactly.
00:49:47
Speaker
I would have ended up writing religious script anyway. Isn't it like this old story about that, you know, like every, every complicated language ended up just writing an inferior version of Lisp, you know, so just write a proper one instead, you know, that's the answer. So, um, let's see, uh, what, what are your views on TDD?
00:50:09
Speaker
I don't do TDD. I've never done TDD. I don't really think that it's that important. But I do like writing tests. And generally, when I'm writing code, I'm writing tests. But I don't necessarily start with tests. I don't think that's a good way to start. I generally start with thinking about what I'm doing. And then I write some code. And the REPL actually helps a lot with skipping trivial things that you would often write a test for if you're doing TDD.
00:50:38
Speaker
I think REPL driven development really changes your approach. At the same time, testing is super important. I mean, I just write tests. I just don't use that to drive dev. I think I was asking about your album. When is your next album coming out? Hopefully soon. I've been working out for so long, like two years. I don't know. Wow. Hopefully soon. These things take forever.
00:51:06
Speaker
Which one do you think is easier? I mean, producing software or producing music? I think they both take a lot of time. Far more time than you would think.
00:51:18
Speaker
Yeah, I agree. There was another question about, I don't know if you've seen this already, what is your thought about Shadow CLJS? Shadow CLJS, yeah, yeah. That's the alternate build tool. It's quite cool. We don't contribute to it. Shadow CLJS just reuses the compiler part and has a lot of
00:51:40
Speaker
custom stuff and it has an interesting integration for Node.js. If you're really excited about integrating with Webpack and you don't want to use JVM stuff, which I would argue it's not most people, so that's why I don't think that many people use Shadow. A lot of people are happy just sticking with
00:52:01
Speaker
the Closure and JVM build stuff. But if you have a different set of goals and a different set of interests, then ShadowSeal just is quite cool. I'm happy to see that there are alternate build tools.
00:52:15
Speaker
So do you see at some point closure and closure script? Of course, there is disparity because of the concurrency stuff not being available on JavaScript or a disparity. But do you see that they're going to be united at some point? Or do you see that closure script will take its own path and then, I don't know, become its own language?
00:52:38
Speaker
I know i mean we don't we don't add stuff there's only a handful of things in closure script that are different because there's a couple things you can do in javascript that we can't do on the jvm. And then there's like obvious stuff like you know.
00:52:55
Speaker
Hosty stuff which you were never gonna reconcile and we don't care about reconciling things like numerics things about things like, you know, JavaScript prototypes versus Java classes all that stuff you can't It's never gonna change. So no, I don't I mean
00:53:11
Speaker
ClosureScript stays in sync with Closure, right? This is why we have the same version scheme. And when we do our announcements, we announce what we've ported, what things we fixed that were different. I would say what we've done so far is probably how it's going to be, I mean, for many, many years, which is that we can't fix everything, but we can make it close enough that people are happy.
00:53:39
Speaker
Yeah. One quick question for you there, David, is something that struck me a little bit because I've been doing a bit of closure and closure script full stack. And one of the things that struck me a little bit with the namespaces was you have to do these refer macro things. It seems a bit awkward to have to do that. Is that something which is potentially clean-upable or is that an intrinsic problem?
00:54:08
Speaker
It's intrinsic because if you're not bootstrapped, then there's no compiler at runtime. So the reason you can
00:54:21
Speaker
The reason you can start up a Closure box on AWS and then make an SSH tunnel into it and then eval code is because that box is running the Closure compiler. But we don't ship the compiler to web browsers. So that means macros run at compile time.
00:54:42
Speaker
And they can't exist at any other time, so that's why you have this distinction for macros have to be handled differently, especially because you're never going to have the compiler at runtime. And technically, in Bootstrap, you could
00:55:02
Speaker
fix this. But the way that we did Bootstrapped, I intentionally discourage it by the way that Bootstrapped works so that when people write Bootstrapped stuff, people are encouraged to write portable stuff. We don't want a forked ecosystem. We want people to write code that works on the JVM and that works on JavaScript hosted things. We don't want there to be people to be relying on features that don't work everywhere. Nobody wants that.
00:55:32
Speaker
You don't want that. You lose some convenience for macros, but the beauty is that you decide, oh, my client now wants to do a Node.js only thing. You can use all that code that you were using before, and it's not going to be a problem. It's not going to be a problem.
00:55:50
Speaker
No, it was just this, like, the only reason I noticed it mostly because of Core Async, actually, is you have to refer certain parts of Core Async as macros and certain parts of Core Async as namespace. There's a ticket and a fix for that problem, actually, that specific problem. All right. Somebody needs to, like, just look at it, test it, and then merge it in. So there's a fix for that issue.
00:56:15
Speaker
All right, okay. Right, back to the other questions and VJ. I've got my answers. So that was your consulting hour. You keep saying, I just started Close Your Script, so maybe it's better to have David as a guest so I can just ask all the questions.
00:56:34
Speaker
That's the best way to get your project kick started. I think David is going to send us an invoice for consulting work. But anyway, I think that those are pretty much the questions that we got from people and also from us as well. Is there anything that you would like to
00:56:55
Speaker
Oh, you're going to be at a conference, right? Which one? The next one? Codemesh. Codemesh. OK. Yeah. Where is it? It's leaving on tomorrow. OK. Where is it? In London. Oh, sweet. OK. Yeah. And also, I see that Eric was also organizing a conference in New Orleans.
00:57:22
Speaker
Yeah, I mean, he was on the show and then we were discussing and then he explained the idea behind it. It was pretty exciting. Yeah, I'm excited. I've never been to New Orleans, so I'm looking forward to it. Nice. Okay. I think that's pretty much it from us. I guess the question, David, is there anything you wanted to discuss or share or anything else that you wanted to be missed out on?
00:57:49
Speaker
I can't think of anything. I think we covered a lot of the other questions. I mean, I think it's very exciting what's happening in ClosureScript. I mean, I would say that like, if you'd told me that there'd be this much stuff happening around it or it'd be used in so many different ways, I wouldn't have believed you. So it's pretty cool, it's pretty exciting. And I think there's a lot more work to do. So even though there might not be like,
00:58:17
Speaker
There's probably not going to be any big new features to announce, but I definitely think the next year or two is just going to be about making it easier to use, faster, go and fix. There's still lots of bugs we want to fix. So just bringing the quality of the thing, much, much pushing it up.
00:58:41
Speaker
Yeah. Yeah, but I think it's a great ecosystem around ClosureScript now. I mean, you know, all the fig wheel stuff and the reframe stuff and like you say, all those other component frameworks around data script. There's so much really great stuff happening out there that knocks the socks off anything that is in an equivalent ecosystem on the UI, that's for sure. You know, I'm really personally excited to be involved in it, you know, even as a consumer.
00:59:09
Speaker
Yeah, yeah, but I mean that's to me the most exciting like what I mean I'm using it right now at work and you know having seeing close seeing closure code in my browser and like just using closure in the browser like this is this is amazing I mean I've been using it you know for years and I still I still I'm still as enthusiastic about is when I started so
00:59:30
Speaker
Perfect. So I think that's pretty much it. So maybe we can wrap up. Thanks a lot, David, for taking the time. And of course, all the hard work that you put in and releasing it for open source and contributing your time and hours and speaking at the conferences and the way that you are sharing your ideas.
00:59:52
Speaker
It is very inspiring. And I'd like to personally thank you for all the old stuff and as well. Sometimes it goes a lot about my head, but still it takes some time to think. As you said, it took some time for people to understand about the state and these kind of things. So we're really, really happy to have you on the show. Absolutely. Yeah. And thanks for helping out, Ray, so he can do his job now.
01:00:17
Speaker
He keeps bragging about, I'm a full stack logic developer and now he can just tell people that, hey, I've been trained by David now. Yes, exactly. I can cite you. Let's just live up to his level. I've got three pages of an application and a small CLI application working. So, you know, not exactly a guru yet, but you know.
01:00:41
Speaker
Once you finish another to-do, we are done. That's the standard of things. Honestly, David, it's been a long time me getting into this stuff, but now I really feel it, and it just is so exciting to be using Clojure on the front end and on the node side as well. I've done both things in JavaScript in the past in other environments, and this new job is I've got more control over the technology myself,
01:01:09
Speaker
So I'm choosing to use these more leading-edge technologies that we have at our hands. Everyone's loving it. Everyone I speak to about it at work, they're all very excited because it's just so clean. Google Hangouts used to have these plugins to put Halo or something on people's heads. There's the moment when David should click that button and there's like Halo and then...
01:01:34
Speaker
Yeah, but that's actually maybe before you wrap up. I think that's the real awesome thing about Closure is that Closure is really ClosureScript and the ecosystem that's been built by the community. It's really now, I would say, it's an amazing ecosystem. You can really sit down and say, I want to build a whole system. I want to do back-end stuff. I want to do front-end stuff. There's just a lot of amazing tools to get the job done.
01:02:03
Speaker
I mean, my mind is blown. I mean, it's cool that we're building the programming language stuff, but the fact that the community has made it extremely practical and fun, like not just practical, right? It's productive, but it's also really fun. And yeah, it's been great to see the community really, you know, fully realize the dream.
01:02:28
Speaker
Brilliant. Let's save you on that. Superb. Yeah. Yes. Thanks very much, David. That's it for this episode. And we plan to produce, of course, more episodes in the pipeline. We have two more guests lined up in the next couple of weeks. We'll announce it very shortly on Twitter, who we're going to have on the show. I think we will continue on the Closure Script theme with the next guest. So you need to follow us on Twitter to know who is that going to be.
01:02:58
Speaker
And thanks again, David, for joining us. And right before we close this episode, we'd like to share something about some new initiative that we are taking. Did we start it already? We created an account on Patreon. It's there. Yeah, we've started it. That's pretty much what we've done so far. Yeah. We haven't done much about it yet, but the idea is to...
01:03:25
Speaker
Put the word out there and if you like the show, you might want to support us. There are some non-significant costs associated with this one because we don't want to go for the sponsorships or anything. So we'd love to have your...
01:03:42
Speaker
Your opinion about it and we haven't decided what kind of perks that you're gonna get if you have patreon Obviously, maybe we'll we'll we'll release a flack audio or something so you can hear us in much more piercing quality in your ears, but Probably that's not something that you're looking out for
01:03:59
Speaker
So we'll put the links in the show description and we'll also tweet about it. So it would be great to have some interaction with the people who are listening to this thing and what you want us to focus on in the future. That's it from us. And Ray, any closing words?
01:04:20
Speaker
Well, just to say again, thank you to David and I think it's really great to have this opportunity. I think we're very honoured to have you on the show and to let you loose and talk about these great things because yeah, it's a fantastic community. I'm benefiting from it, VJ's and I think all listeners are as well and I think it's a pure pleasure to talk to you as well.
01:04:47
Speaker
Let's be honest, you're a great guy. Thanks again for having me. It was a lot of fun. Awesome stuff. Thank you very much.
01:05:20
Speaker
you