Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
#32 - Conrad Barski aka @lisperati
65 Plays8 years ago
Conrad speaks clearly about his love of LISP and how that evolved into Clojure.
His projects have been inspired by teaching and remaining true to the spirit of LISPs as a toolkit for building languages and now we see that being brought to the blockchain.
It never grows old !
More information at the web site https://defn.audio
Recommended
Transcript
Introductions and Live Streaming
00:00:15
Speaker
Okay, welcome to Defin episode number 32. This is Vijay from Holland. Hi, it's Ray in Belgium. And Conrad from Chicago. The Windy City. Yep, it is.
00:00:31
Speaker
So we are very excited to have you Conrad finally on the episode. I think there's been some uncertainty whether we're going to record it today or not because of us, but I'm glad we made it. So let's get started. Of course, we are live streaming this episode just like the previous two episodes.
Conrad's Background and Podcast Appreciation
00:00:49
Speaker
So if we have any questions from people who are watching around the world, we'll pick them up somewhere around the end of the episode.
00:00:56
Speaker
So, first of all, welcome to DEFIN. So, did you hear any of our episodes or what do you think of this podcast? First of all, advertisement for DEFIN. Yes, I've been listening to it for a while. I'm a big podcast listener. I spend so much time in front of a monitor. And since I'm sort of a, I guess, a data bore, you know, somebody who likes to
00:01:18
Speaker
information. There's only, you know, since I spent all my time programming in front of a monitor, I consume most of my reading material and news by podcast or by audible and those kinds of things when I can. So, so yeah, so I've been listening to you guys for a while. And, you know, I've been really impressed by the the caliber of the guests. So the quality is really high, it'll
00:01:41
Speaker
It's kind of, it'll be tough to follow.
Journey into Programming Languages
00:01:44
Speaker
And yeah, I thought the overall structure and the kinds of questions were really well done. So yeah, so I'm a big fan of Deffen. Fantastic.
00:01:56
Speaker
No one's ever been crazy enough to admit that before, Conrad, so it's appreciated. Exactly. I think we're going to quote you on our website and everything, and then we put the GIF of you everywhere, and then we say, he said, we're good. So, OK, so let's do a quick round of introductions. Of course, I mean, most of the people already know about you, you know, because you wrote this Lisp book a long time ago, the line of Lisp. And you did a lot of work with Closure as well, starting from WebFoo here and different things. So we would talk about all those things. So how did you get into Lisp?
00:02:27
Speaker
Well, so I've been for a long time, like kind of a low level C and assembly language programmer. So a long time ago in undergrad, I worked for a contractor that was building Atari video games. So if you guys remember the ill-fated Atari Jaguar console,
00:02:46
Speaker
So I was lead developer on the game for that long, long time ago. That was lots of very ugly assembly language. And so that was kind of my background. And of course, you know, I always kind of been interested in like kind of the tooling and like
00:03:03
Speaker
figuring out what is the right way to write a computer program and those kinds of things. I did a lot of stuff in C and C++ and went down that rabbit hole and then quickly started realizing, this language doesn't really do what I want. I guess I'm going to have to start writing some preprocessors so that I can use this tool the way I want to. I went down that road and then
00:03:32
Speaker
I was listening to a interview with Bjorn Stroustrup. I probably totally butchered his name. But he... It's okay. He doesn't listen to this podcast. And so they asked him, like, what, you know, if we want to see what the new ideas are going to be in C++ moving forward, you know, where should we look? And he said, well, look at what the functional programming people are doing. And that was really the first time I heard that term. That was quite a while ago.
00:03:58
Speaker
And it's like, OK, so what's this? And then I first, if you look at functional programming, pretty much the first thing that will come up is Haskell and that type of stuff. So I went down that rabbit hole for a while. And those are really cool languages. And then I guess sometime around that time, I also started reading the Paul Graham essays, where he was speaking very highly of Lisp.
00:04:25
Speaker
And then I kind of realized, yeah, I kind of like these languages that kind of make it easier to do prototyping where you can just kind of start building stuff and you don't have to worry about what your type signatures are and all that. And then, of course, what's awesome about Lisp is that it sort of fulfilled my old dream where it's like, oh,
00:04:48
Speaker
Now I don't have to write a preprocessor, I can just write macros. And so I went
Functional Programming and Lisp
00:04:53
Speaker
macro crazy like every early whisper. And nowadays it's like, you know, once every six months I write a macro because you learn, the more you do it, the more you realize you shouldn't be using macros for everything.
00:05:06
Speaker
And yeah, so that's kind of how I got down that rabbit hole. And I mean, I think what sort of distinguishes me, because I have kind of a different background, both because I went into medicine and also just because I came out of a part of the country that wasn't really very
00:05:25
Speaker
sort of a tech area. I came out of South Florida and before the internet it was really hard to get sort of good computer science information. So if you wanted to be an autodidact, which I was because I wasn't getting a computer science degree,
00:05:45
Speaker
there wasn't a lot of information. So I kind of got into all of this sort of the computer science side of computer programming rather late. And I think that gave me kind of a unique perspective in that I could maybe explain some of these concepts more easily to beginners because I was also kind of a beginner that had just kind of picked this up and was really excited about it.
00:06:09
Speaker
And so I think that's why, like the early web tutorials I did around this programming, like the most well-known one is called Casting Spells. I think that's kind of why it hit a chord is just because it got people excited and it could explain kind of in a very basic way why these things are kind of interesting to somebody who
00:06:33
Speaker
It hasn't done macros and has dealt with homo-iconic languages and that kind of stuff. But as a person who is, as you said, you're kind of an outsider for computer science stuff. So how did you feel between Haskell and Clojure? I mean, you went into different sorts of languages.
00:06:56
Speaker
Without any computer science education, because if you get computer science education, then you start with types and type theory and if you go into that direction, then suddenly things are a bit different than coming to the real world programming, so to speak.
00:07:09
Speaker
Yeah, it's really weird and I'm still kind of ambivalent about this whole, you know, the whole argument about static typing because part of me really feels like if I was just kind of smart enough that and I spent enough time using Haskell and OCaml and all the ML languages that like that might be like the most effective way to write robust computer software. But like, you know, I have to live in the real world and the fact is that I can just
00:07:37
Speaker
write a lot more code in a dynamic language like closure. So I don't know how to explain the difference. The difference could be that maybe if I put in just another year of Haskell under my belt, then I would be just as good in Haskell.
00:07:55
Speaker
Or it could be that the idea of having to think really deeply about types at the beginning as you're developing software, that that maybe isn't like an optimal way to develop software. I really don't know what the answer is.
00:08:11
Speaker
clearly in the closure community there's sort of this this view that you know people have had recently where they've kind of said well you know maybe this being so heavily statically typed might not be the best thing ever maybe there there's actual tangible benefits to
00:08:30
Speaker
to not going down that in that direction because although it does give you certain guarantees, the guarantees are still limited. Types are not a silver bullet. And so, yeah, so there's trade-offs and it's really hard to judge what the right answer is there. I mean, I think I would recommend for anybody who's a serious programmer to learn both a statically typed language and a Lisp language.
00:08:59
Speaker
Yeah, going back to when you started to learn Lisp, because you said you worked on games, did you look at implementing some games in Lisp, or were you just looking at something completely different by that stage?
Web Development Frameworks
00:09:14
Speaker
Oh, so that's a good question. So I mean, the casting spells and lists that I did was a game, a text game, because I kind of I liked it. I was kind of intrigued by how a rebel is so similar to something like zork. And it seemed like the natural way to do like a tutorial. And, and yeah, I mean, I'm
00:09:37
Speaker
I was a kid when it was the early 80s, I would pick up those books like 110 basic computer games. And I would type them all into my Commodore 64. And so I really like that idea that there's something about games that lets you
00:10:00
Speaker
take abstract concepts and very quickly build something tangible that has some kind of utility. And it's just a great way of learning. And so the Land of List book is basically the design of it is that every chapter has a game in it.
00:10:15
Speaker
And the hard part with the book was, is that every game could only use concepts that were covered in previous chapters with previous games. And so it was very difficult figuring out the right ordering of the games and features in the games to make that work.
00:10:35
Speaker
How did you find that from an experiential perspective? I guess it was pretty good, otherwise you would have given up. But how did you find it when you were comparing it? People always say you can't write games in this stuff because it's too slow and it's too difficult to make a performance when you compare it with Assembler or C or even the
00:10:59
Speaker
Even JavaScript.go these days, I don't know. But certainly, like, you know, Objective-C or C++, people are writing all their games in that. So, do you feel like there's a subset of games that could be written in a Lisp, or is it just kind of, like, purely as a toy?
00:11:16
Speaker
Well, I kind of think that the things that I find interesting and compelling about games, like I was a big fan of the Ultima series, has very little to do with graphics and the performance you need to do interesting things in games in terms of storytelling and stuff.
00:11:34
Speaker
is not a very high bar. And certainly with a modern Lisp, you can do actually pretty high performance stuff if you want to. I mean, it's always a tough question exactly around how
00:11:49
Speaker
what role does optimization play in any sort of software that you develop? And I'm certainly somebody of the view that I like thinking about new ideas and I'm just somebody who likes building things. And for the most part, that means that I pay very little attention to performance or optimization because that just gets in the way of trying out new ideas.
00:12:16
Speaker
Bridge. Yeah, and when we talk about development frameworks, that attitude will come into play, I think. Yeah, that's awesome. I totally agree with that. I mean, well, I think it's a trope, isn't it, that you should get everything correct and right and happy first and then find out where the performance issues are and deal with that later. And even if you have to throw it all away, you've still got the thing that you want right
00:12:45
Speaker
Yeah, I think there's a definite case for writing software in lists, like if you're talking about high performance stuff like code for some embedded system. Like the way I would probably go about that if I had that job is I would write it in something like a closure with the expectation that the code would be thrown away. But after I got everything working in closure,
00:13:05
Speaker
then I would sit down and figure out, okay, what are the types? Then I would use some very performant statically type language to write all the types out and then code the rest of the system and then use that. But certainly for that early exploratory phase, closure seems to be a local maxima. It'll be interesting to see because it could totally be that five years down the road, I think there's starting to be room for new programming languages now.
00:13:34
Speaker
So we'll see if there's another rich hickey five years from now that comes up with something even cooler. But so far, closure seems to be pretty ideal.
00:13:45
Speaker
I think the other thing I'd be interested, because I'm doing some IoT stuff as well at the moment. And I've seen some videos of people doing lisps for embedded systems, mini versions of lisp that can run everything in a word. They can do all kinds of optimizations. So maybe this lisp machine, maybe the IoT will be the place where we start to get the lisp machine coming through again.
00:14:09
Speaker
because people want to be able to code in a lispy way. I mean, having a REPL on the IoT would be superb, I think. At the moment, I'm writing all of it in C and waiting for a long, long loop around before you can get any work done on these things.
00:14:25
Speaker
Yeah, and I think later on when we get into the discussion where we start talking about blockchain and smart contracts, that same issue comes into play because with the system where you want other people to validate your computations, performance and optimizations are very important.
00:14:43
Speaker
But did you, so you started with programming as a, I'm assuming as a hobby, not like really, you know, as a study, because, you know, doing medicine
Introduction to QLKit
00:14:51
Speaker
must be pretty exhausting and time consuming during that education. And then you moved into obviously learning all these languages. And now these days you're working on the blockchain stuff. We'll get to that point. But how did you manage to do the programming stuff? Did you work commercially with, I mean, building software for somebody or?
00:15:12
Speaker
Well, I mean, you know, I'm an older developer now in my mid 40s. So, you know, I come back from the era where you didn't really need a computer science degree to work at a software company. And I think even now it's more or less that is the case. I mean, if you know JavaScript, then you're a software developer. So yeah, yeah, yeah. I mean, it's a degree is more helpful now. But, you know, exactly basically nobody cared. And I just realized, like, you know, like, like,
00:15:40
Speaker
the guy that we've hired for our company, you know, that's been working for us for a long time. At some point I realized, hey, I don't know anything about you. Did you get a computer science degree? Did you graduate high school? Because it doesn't matter because like I know, you know, I knew his work. So that was completely irrelevant. It never occurred to me to ask him any questions like that, you know. And then you started now. So do you practice medicine or are you fully focused on your company right now?
00:16:09
Speaker
No, I basically got my medical degree. And I kind of, while I was at medical school, kind of decided that that was probably not the right career choice for me. I think just temperamentally, I'm not very good with just road memorization. And I'm not very good with sort of quick in the moment decision making, which is a big part of that job. I'm somebody who likes to sleep over things. And then I make good decisions the next day.
00:16:38
Speaker
So computer science is more up my alley. But it doesn't matter if you have a medical degree and you have a computer science background. This was right before the dot-com bubble when I started working for medical enterprise companies.
00:17:00
Speaker
like there was just easy demand, like, you know, people were interested in hiring you. So, you know, and, you know, computer software makes a pretty decent salary to compare to what a resident doctor makes. So, you know, I could pay my loans back and everything in the same way, pretty much so.
00:17:18
Speaker
Yeah. So you transitioned from Haskell to Lisp, obviously. I mean, you wrote a line of Lisp, which is a super fun book with all the fancy Lispy alien stuff and everything. It's amazing to read and really fun. And then you did a bit of a racket as well.
00:17:35
Speaker
Yeah, I played around with all the different lists at one point or another. And in fact, when I was approached by Nostarch Press about doing Land of Lists, so they had seen my online tutorials and thought I might give a good person for a book, I told them, there's this new language called Closure that looks kind of interesting. And we all decided, well, it's probably a little too early to write a Closure book. So that's why I wrote Land of Lists.
00:18:03
Speaker
But like, if it had been like another six months later, it might have been country of closure. That's nice. I mean, you always pick these words with some sort of a, you know, rhythm in it. I mean, Bitcoin for the befuddled and the realm of rocket and land of lisp. Yeah, I don't know why. I guess it just I like titles that roll easy off of the tongue. So.
00:18:28
Speaker
It's very easy to remember, right? I mean, if you say, Oh, which closure book was that? You know, it's much easier to remember which list book was that because I have, I've read enough, enough of list books. And I think the only book name that I can completely remember is LOL, leftover Lambda. That's like a really mental gymnastics with macros. I mean, by half of the time I read it and then I go reread it again. And then I'm like, okay, I don't understand anything anymore. It's a wonderful book. Yeah, it is a great book.
00:18:56
Speaker
Yeah. Great book that you don't understand here. Most religious books are like that, aren't they? Exactly. The thing that you don't understand is above your, then you suddenly start to revere it with some level of, I don't know,
QLKit and Blockchain Potential
00:19:12
Speaker
admiration and then. So it's a life of work, a whole life's work of study. Yeah.
00:19:22
Speaker
So, why? Because you started doing the blockchain stuff. Before we get into blockchain, I'd like to, I think, let's discuss a bit more about, I remember watching the video from, was it Closure Conch? Because you presented Webfue. Yeah. What was the background for that one?
00:19:39
Speaker
Yeah, so so this was just me. So so at my day job in medical enterprise software, very, very conservative field that you know that it was all about asp.net and so I was doing a lot of C sharp programming and and we were doing we were just starting up JavaScript development and.
00:20:03
Speaker
But yeah, I just kind of realized that I'm a functional programmer. I want to write functions that say that output as a result, what I want to see on the screen.
00:20:18
Speaker
And I had heard, there's a thing, what is it called? McClimb. It's a thing from the Common List world. And they started playing around with some of those kinds of ideas. But for the most part, just at that time, the concept that you would have an app that just is a function where you stick in what you
00:20:38
Speaker
the information about the app and then it spits out what you want to see on the screen. That hadn't really existed in a major way at that point. I just basically wrote a function that would just spit out HTML and then I would just say in JavaScript,
00:20:57
Speaker
like window.html or inner HTML or whatever it is. Then I just say equals to this big thing. Then you can write an app that way. It just spits out the HTML for the page. Then of course, the next thing you start thinking about is,
00:21:18
Speaker
what should be the correct way to have some sort of modularity and some kind of composability. And that's where I kind of got it wrong because I thought, well,
00:21:34
Speaker
I basically want this function that just dumps out HTML. Then if we want to break up the screen into different components, the way I would handle that is by just having more functions, one for each component. I didn't have the actual concept of a real component design with the idea being that each component has its own needs in terms of
00:21:59
Speaker
its own state and it's a life cycle where it can be mounted and unmounted and stuff like that. Anyway, I built this WebFooey thing and it was surprisingly hard to figure out how to do this low-level manipulation of the DOM. Anyway, at some point, I optimized it. The next obvious step is, if we have a copy of the old HTML and we have the new HTML, both of course, in an even format, closure even format,
00:22:28
Speaker
then we can do a delta. And so instead of replacing the whole screen, we can just replace little pieces based on that. And then now you've gone to the point where you're building your own virtual DOM engine. And yeah, there was like no resources on this. Nobody really had done it before, at least not publicly. And yeah, so that's what I presented at that closure conge.
00:22:52
Speaker
And then a couple of months later, Facebook released React. And then when I saw that, and the thing is, I didn't really want the job of developing my own web framework. It's just like, hey, the web frameworks don't work the way I want to. I want to work in a way that I want to work.
00:23:11
Speaker
The only option there was to build my own. Then as soon as React came out, I was like, thank God, because my framework was not a really solid implementation. It was very rough because it was just something I was doing in my free time. Then I went straight to the React forum and it's like, you guys have totally the right idea. This is fantastic.
00:23:34
Speaker
I was working on the same idea, but I don't care because it's great that these good ideas are being implemented. I was a big champion on day one when React came out. If you looked at the Hacker News story when React came out, everybody was like, well, this is just the dumbest thing ever. You're mixing your CSS and your HTML directly with the JavaScript.
00:23:57
Speaker
Like what kind of idiot would do that? And that's how React was for like the first six months. Everyone hated it. And then somehow people started realizing the benefits of this approach.
Blockchain Community Critique
00:24:12
Speaker
So, yeah.
00:24:14
Speaker
So you started from WebFui and then you obviously react. People stole your idea and then somehow made it more popular. That's pretty good for all of us then. I should point out they were working at it for like even a year before that. I don't do that. Don't point that out. You've been thinking about it for years before you started on it. So come on. Exactly. They stole the idea. Anyway, we're going to spread this thing around. Anyway.
00:24:38
Speaker
But you get, of course, I mean, it's a very exciting idea. And then there have been a lot of frameworks in Clojure which adopted React and then they build different things. Then how did you, because you recently announced QLKit. So why QLKit? When we have reframe, when we have omNEXT, when you have full CRO, I don't know, ROM question, whatever. There are millions of things these days. Yes. So I really,
00:25:08
Speaker
I mean, the big problem you run into, I mean, there's two big problems. Okay, so you figured out finally how to handle the information on the screen. React solves that beautifully. The two big problems you have to deal with next is that there is not a one-to-one mapping between your client application state and your UI. So basically, I guess the term would be it's a DAG.
00:25:34
Speaker
If you have friends, you're building a Facebook app and you have friends, then there might be one place where you see a list of your friends. Then in a completely different part of the UI, it'll say you have 10 friends. If you unfriend somebody on this side, it has to update that counter on the other side.
00:25:53
Speaker
and you have to manage that in your application state. And so now you have this problem where you have different parts of the UI that need to share the same backend data. So how do you solve that? So WebFooie totally didn't address that question. And even things like the early React and
00:26:13
Speaker
And some of the early framework's enclosure didn't really address that. The first one that I really saw that addressed that was Ohm, the first version of Ohm. And so what David Nolan did there is he had this concept of a cursor
00:26:30
Speaker
which was a complex, I won't get into it because he's already moved beyond that. Yeah, exactly. But it's like a fancier version of a zipper and it basically keeps track when you're inside, deeply inside of a component, how that maps onto something in terms of the global application state that you're managing. That was really appealing to me. Then I really got into OAM and
00:27:01
Speaker
And that was like the one that spoke to me because it solved the next big problem, which is how do we map the client application state to the UI. But then of course, you start messing with cursors and this cursor concept and you eventually you run into edge cases where cursors just don't work and where there's complicated enough relationships that you just can't use cursors for it. And then of course, if you look up
00:27:27
Speaker
the fact on OM at the time, you know, David Nolan would said, well, he said, well, you should use channels, you should have channels between things. And that way you can kind of have things kind of talk to each other, sort of out of band and things like that. But then it's like, well, now it's starting to kind of look a little bit like spaghetti. And, and so
00:27:47
Speaker
And that's why Ohm was then superseded by Ohm Next. And then I got totally obsessed with Ohm Next. And the idea with Ohm Next was, well, here's the thing. It's really hard for me to really understand what the underlying abstraction with Ohm Next was. What were the priorities that David had in mind?
00:28:13
Speaker
All I can speak to is when I studied it, like the features that I saw and some of the features really spoke to me and other ones, not so much. As we discussed earlier around optimization, Next went to great lengths to offer a really compelling optimization story. There was some costs with that naturally, one being that the code base is complicated,
00:28:43
Speaker
And another one is that there's, again, some edge cases where Ohm Next can be difficult to use, where you have to kind of look under the cover, specifically around the issue of when parent components pass information to child components, Ohm Next breaks that into two categories. One category is
00:29:05
Speaker
Things that relates to the the the application state and the queries that the child components have and then separately If the parent just wants to send like some kind of message or just give an extra property to a child It kind of handles that differently. So so so I'm not sure how well I'm explaining that but basically when when a parent component in all next
00:29:26
Speaker
passes data to a child, there's like two different ways to do it. You do it either as props, which is the React method, but then they have this other thing called computed props. When you mess around with that stuff enough, eventually, you again have to look under the cover.
Blockchain Challenges and Future
00:29:45
Speaker
So anyway, so Olmex is really great. But again, me being an outsider,
00:29:53
Speaker
It seemed like there might be some value that I could add by just sort of translating what I view as the really great ideas behind Ohm Next into like a different framework. So that's kind of what I've done. So that QLK really doesn't have a lot of new ideas. There's maybe a couple.
00:30:12
Speaker
But the debate, I mean, I guess I kind of think of it this way, like, you know, why is the English language like one of the easiest languages to learn for beginners? And the answer is, people speculate, linguists speculate that it was all the invaders from the Vikings from Scandinavia that came to England and Britain
00:30:35
Speaker
And they had to learn the language as adults, and they intermarried with the locals. And because of that, the language greatly simplified during the Viking invasions in Britain, because you're basically taking these very complicated ideas, and you're taking people that are novices, and they have to kind of reconceptualize these ideas in a different way. And there's a benefit in that.
00:31:01
Speaker
So are you saying that the whole of the Brits were all dumbed down basically? Well, the language was, and it's everybody's down. It's part of the reason. He's only talking about the language, not the Brits themselves. Well, I don't know. I think Brexit shows that the people were affected also. Okay, carry on. Yeah. Right, I interrupted you. So we're talking back to QLK.
00:31:26
Speaker
Yeah. So that's essentially what I did is I just looked at Home Next and there's so many awesome ideas in there. And I just said, if I didn't have Home Next, but I knew all these great ideas, what would it look like? And that's what QL did. I think that was most of the...
00:31:43
Speaker
Of course, I'm also not an expert on anything, obviously. The idea behind Ohm and OhmNext has always been, at least that's what I heard from David speaking at the conference, is that this is an idea exploration and then you can build on top of it. Yeah, exactly. So this is not the final framework that I'm bringing and then you should just use this one.
00:32:03
Speaker
Yeah, these are the ideas that you can start and then build on
Animation Technology with FP
00:32:06
Speaker
those things. So I think next was also kind of the similar. Yeah, almost a set of principles, you know, that the client should be able to express their desire in some kind of data type language to the server, and it should get exactly and only what it needs back. I mean, these are the kind of core principles.
00:32:27
Speaker
Yeah. Yeah. So so I mean, David Nolan, he said very clearly that he also that he basically just wants to share ideas. And that's what his goals are. And he's happy. And it sounds like he's happy when people take his ideas in other directions.
00:32:42
Speaker
But why not? Why not full-crow? Because full-crow, of course, I mean, I read your Medium blog post and I'm sorry, I didn't try out the whole QL kit yet. I will certainly next week, next weekend. So you have full-crow and then full-crow. We had Tony K as well on the, I'm not sure if you have heard the episode. So he was also doing similar kind of thing, like bringing home next to people like me. So did you look into that framework?
00:33:12
Speaker
Any good things that you pick up from there? Yeah, and I definitely owe some gratitude to Tony K because I use a lot of his tutorials for understanding OmNEXT. And OmNEXT does have a pretty high learning curve. And Tony K did a lot of work to help alleviate that.
00:33:33
Speaker
So yeah, I mean, the idea behind what Tony Kay was doing is, well, I don't want to speak for him, but it seems like his goals were to add features to OmNEXT and also to apply some
00:33:49
Speaker
uh opinions to om next so basically he said you know om next oh if you know back when uh david was starting om next you know and you would ask him hey uh david how how in your opinion how is somebody supposed to do uh you know this particular thing in om next and then his answer usually would be something along the lines of uh that's the beauty of it you can do it any way you want to which of course you don't want to hear you want um
00:34:14
Speaker
David to just tell you the right way to solve the problem, right? So that's kind of what Tony did. He said, okay, yeah, let's not do that. Let's have a version of Oh, Next where it tells you like at least a default way to do things.
00:34:29
Speaker
And now, of course, Tony has gone in another direction, which is that he's, from what I understand, he's pretty much duplicating the code base from om-next. He's like forking om-next to be more appropriate for full-flow. So they're starting to deviate more.
00:34:46
Speaker
Yeah, so my idea was mainly that what really got me is just the complexity of the code base of OmNEXT. I think the reason it's complicated is, again, number one, because the flexibility that David wanted and also these optimizations. If you use QLKit, the only optimization you get is the basic React optimizations that React does.
00:35:12
Speaker
but it doesn't go beyond that, whereas Next takes it to a whole another level of optimization. But there's, again, some costs in terms of the complexity of the code base. I was just wondering, well, if we didn't have that, what would the performance be like and how simple can we make the code? That's what I did. I think there's a couple of other things where I differ
00:35:41
Speaker
a lot of the syntax and stuff is different. I mean, there are some different views of it. I mean, what I really liked about Oh next that I thought was a really brilliant idea was that when a component, a component basically declares the data that it needs in a query as part of the component declaration. And this is usually done at.
00:36:03
Speaker
this is a static query. So basically, you say that when you write the code, you say this is the data it's going to need. And what's really great about that is that the first thing you do when you own Next after you have these queries
00:36:23
Speaker
and they all get kind of composed based on the component ordering, is you basically just immediately throw them away because you pass them to a parser and then you have this separate thing called these parser functions that parse the query.
00:36:42
Speaker
Basically, what you're doing is you're creating your own language for describing the data needs for all your components. Then you immediately throw that away by giving it to a parser that fulfills that. It's like you're writing your own language just for yourself. The query language basically just lives in the confines of your program. It's more in a way an organizational
00:37:06
Speaker
for the structure of the program, but it's not meant to really be used in the outside world. And in some ways, OmNEXT differs from that. First of all, the OmNEXT query syntax was built off of the atomic pull syntax.
00:37:23
Speaker
So that was, because of that, it was designed to be more something that you could send to outside entities like Datomic. And that introduced some complexity. And then also, there's this view, you know, next where
00:37:42
Speaker
Maybe the query language should be richer and have more features so that you don't have to write parsers that are as complicated. They have these things called links, which is a way to connect queries together in a certain way. They have parameterized queries where you can basically change a query at runtime. You can either just change the parameters of a query or even replace the entire query itself at runtime.
00:38:12
Speaker
And so to me, actually, I didn't find those ideas very good, because I like the fact that the query never changes. And I like the fact that if we can make the query language really, really simple, since the whole job of the query language is for our own use to parse it, we want to keep that language simple. And so if you read about the old NextQuery syntax,
00:38:35
Speaker
depending on whether you have parameters or not, you like the way the query is structured changes pretty radically. And so there's actually a separate parsing mechanism where they take the old next query and then parse it into an AST query. So they have two different query formats. Whereas with QLKit, I severely restrict
00:38:56
Speaker
what you can do in a query in terms of the syntax. Then you use that in your parsers directly so that we reduce that extra step. But then, of course, the very first question when I posted it online was, if I can have dynamic parameters in a component, how would I do certain basic things like just having a search field? Because in a search field,
00:39:25
Speaker
The idea is you have a component, it has a query saying, I'm looking for, let's say a person with this name is the query. And then as people start typing into the search field, you want to change what that name is and what is being queried from the server. And so they ask, well, if I can't change what the query is, and I don't have QLK and has parameters, but you just can't set them on a component at runtime, then how do I do that?
00:39:53
Speaker
And if you read my fact, there's very straightforward ways of doing it. What you have to do is you lift the concern of what the query is, what the search term is into the level of the global application state. So basically what you do is the component has
00:40:13
Speaker
a query that's static and it just says, give me all the people that match the search term, but it doesn't say what the search term is, it just says, I want the queries that match the search term. Then the search term itself is in the client application state.
00:40:31
Speaker
Then what QLKit offers is additional tools for helping to massage queries before they get to the server. Then at that point, you say, in order to answer this question, we can't do that in the client, we have to send it to the server. Now the server is going to have to know what the search term is because it doesn't have that information for every client. Now we will add that as a parameterized query,
00:41:00
Speaker
when it gets sent to the server. So it's just a different way of organizing it, but the goal is to simplify the query language. All components have static queries. You can't change them. You have to say what your data needs are at when you write your code.
00:41:15
Speaker
So the QLKit is built around GraphQL, right? I mean, this is completely driven by GraphQL. So it's not comparable to other toolkits which are decoupling back and in front end, like REST APIs or something like that.
00:41:30
Speaker
Well, the idea is that, so QLkit uses a graph query language. And QLkit is another type of graph query query language. It's a different, the two have a different syntax. And om-next and the datomic full syntax are also graph query languages and it has its own syntax. And all graph query languages are basically the same. They're solving the same problem, but they may have different syntaxes.
00:41:56
Speaker
It's easy to take the QLKit syntax and convert it to GraphQL if that's what you need to do, if you wanted to talk to a server with GraphQL. But the basic model is, we have our own query language,
00:42:18
Speaker
when a component asks for data, usually that those data needs are fulfilled through the application state that's in the client browser. But then there's like this extra stage where you can say, no, no, no, no, this piece of data, we don't have it in the client. We're going to have to ask the server for that.
00:42:37
Speaker
And then at that stage, you can actually change the query because it might be that from the context of the server, it needs to know more about what you're querying because it needs to know maybe what the user is, more about what the search term was that was maybe extra
00:42:55
Speaker
things you have to specify to lock down exactly what it is you're querying. So we have extra parsing functions that let you introduce this extra information before it reaches the server. And then on the server, just like with Ohm Next, we use QLkit2. So the exact same parsing library that you use for parsing reads and mutations against your client state in the browser, you use that exact same library
00:43:24
Speaker
on the server to parse the queries. And then when the data comes back, then there's, again, a set of parsing functions you can write that synchronize what's coming from the server with what's in the client state. And this is, again, a departure from om-next because what om-next does
00:43:45
Speaker
is they have this concept of auto normalization, where the idea is that the process of when data comes from the server, we're going to incorporate that into the client state automatically and the programmer doesn't need to do anything.
00:44:01
Speaker
But because of that, it places certain constraints on the structure of your client states and the data that's coming from the server has to be in a very specific format. QLKit just says, no, you just have to do it yourself, which makes things a lot simpler in some ways, but you have to write the code saying, okay, here's the data from the server. Now, how do I update my client state to match that?
00:44:26
Speaker
So how much of this QLKit code is in production in your blockchain application? Is it still? So I guess we don't really have any production app yet. I mean, we're a company in a very sort of early space and we're spending a lot of time trying to develop core technology. And there's a lot of
00:44:50
Speaker
There's a lot of efficiency gains that are possible by using graph queries, using closure, using core async is very useful here. Those through three things like nobody in the blockchain or very few people in the blockchain world really understand how powerful those things are. If you apply those to blockchain tech, there's major efficiency gains.
00:45:16
Speaker
Maybe a quick intro about, not intro, but a quick elevator pitch about what your company is doing. Can we just finish off the QL kit first? Just before we move on. Just because I had a question about how the server fits into persistent data stores like the Atomic or SQL Server or whatever.
00:45:35
Speaker
or Mongo if you really want to go crazy. Just to complete that and close the circle a little bit, what do you do in terms of integration to persistent data stores?
00:45:52
Speaker
Yeah, well, so again, the goal in a way is that what you want to do is when you describe the data needs for your application, what you do is you kind of invent your own language, which is the query language that your particular application has. So it might say, oh, this is an app.
00:46:12
Speaker
for keeping track of providers. So we're going to have data. So in the query, you can ask for providers. And then maybe you can say, I want providers whose name begins with A. You can invent your own DSL basically describing this. And you're constrained because it has to match the underlying syntax of the QLKit
00:46:35
Speaker
query language, or if you're using Next or GraphQL, they have their own syntax. So you have to meet those basic requirements. But then after that, you can basically come up with any format of how you're going to ask for data that you want. And so with QLKit, you have the parsers on the server that will make it very easy to take this query that's coming from the client. And part of the goal here, as you touched on earlier,
00:47:00
Speaker
is that there could be different types of clients. There could be mobile clients, desktop clients, which would have very different types of data needs in terms of how much information they want. And with these parses, you can very easily traverse the query and generate a result that's optimal for the type of client you're dealing with without having to write multiple backends, which is kind of a popular technique these days.
00:47:26
Speaker
But essentially, that's where QLKit stops. The best QLKit will do is it will give you a very precise language on the server that will tell you what data the client wants, and if it's doing a mutation, precisely what that mutation is, and additionally, what data will be affected as a result of the mutation that needs to be refreshed on the client. So that's all QLKit gives you.
00:47:55
Speaker
Then it's up to you to decide where the actual data lives on the server. You can convert it to GraphQL to use one of these GraphQL databases. You can convert it to atomic pull syntax to talk to datomic. You can just use a state atom because it's a simple demo app, but it's totally up to you to convert that graph query into something that's meaningful for your
00:48:22
Speaker
your server. So the goal here is that we're creating our own language, which for most people would seem like an insane idea because it sounds like a lot of work to have your own language for every application you're building.
00:48:38
Speaker
but to a lisper they realize that that's actually pretty easy and and and oh next i think uh to me what will make me what made it compelling is just that i just said yeah you know forget about all these cursors and stuff that just makes things complicated let's just say what everything needs
00:48:55
Speaker
And then we'll just do the hard work of figuring out how to satisfy those needs, both on the client and the server. And guess what? Because it's lists, it's actually not hard. So it's just the easiest thing to do anyway.
00:49:09
Speaker
So you're doing a David, are you there? You're just leaving the persistence as an exercise to the reader? Exactly. So you can do anything you want. Yeah. Oh, God. I want you to tell me the answer, Conrad. No, OK. Great. Great stuff. Sorry about so. Good. Right. We can move on to the stuff now.
00:49:28
Speaker
Yeah, so quick overview about what you're doing for a blockchain because I think some of the people might not be familiar with what you're trying to do. Maybe an elevator pitch about that one and then the technologies. Then we can talk about blockchain and how Closure is going to help with blockchain stuff.
00:49:47
Speaker
Yeah, so what we're doing for blockchain is pretty basic. I mean, I've been part of the crypto community for a long, long time and feel like I have a good overview of all the technology in the blockchain space.
00:50:04
Speaker
And we just simply think that there's some kind of intersection. You can have Venn diagrams. One Venn diagram is blockchain tech, and another one is medicine. And somewhere in the middle there, there's something useful there that we feel we're uniquely positioned to add value. And it's still early enough that it's really unclear what that is.
00:50:28
Speaker
Certainly, there's other companies working in this space and many of them will have very clear plans saying, you should do this and it's awesome. And we kind of look at what they're doing and it's like, well, that doesn't really seem that awesome. It seems like you're basically just making a very complicated traditional database.
00:50:49
Speaker
Yeah. So that's kind of where we're at. So what we're trying to do is focus first on use cases that are really compatible with blockchain tech. And since blockchain tech by its nature is very public,
00:51:09
Speaker
the most valuable types of blockchain technology are public in nature because what you're trying to get is this validation property that blockchain gives you and your data has to be public to do that. So that means it's useful for public data sets. So these are things like provider information like medical licenses, medical credentials, things like equipment inspections for like radiology equipment, things like
00:51:38
Speaker
figuring out the supply chain issues. Now, of course, as we're talking to people, I think there's still a lot of thinking in IT
00:51:53
Speaker
that sort of is pre-internet thinking. And in one way where that's the case is most programmers, when they learn their craft, they learn the idea that you collect data somehow,
00:52:09
Speaker
And now you have to put that data. Where are you going to put the data? Well, you're going to put the data in the database. And there's one database. Because this was before the internet, so you had an intranet. And there was only one database. So where else were you going to put the data? And I think that the world now is different. And basically, there's four types of data now.
00:52:35
Speaker
There's data that's still the traditional type of data. You collect it and it has to be kept secret and you want very strict controls about who's allowed to create that. You can just keep that in a traditional database. But then there's other types of data like there's data that's communications data. With communications data, you want to have a very low barrier to entry.
00:53:03
Speaker
for people being able to author information. So you want people to be able to send your employees emails or something. So anyone can author that. But then you need very strict rules for who's allowed to read that data. You want privacy around reading, but you want no security at all around writing or very low security. And then the most extreme type of data is stuff that we want everybody to read.
00:53:30
Speaker
and everybody to write, and this is where companies are starting to get into social networking and putting information open and that stuff. But then there's this fourth category of data, which is data that is where you want very strict controls over who is allowed to write that data, but you want everybody to be able to read it. A medical license would be the perfect example. Only particular employees and government,
00:53:57
Speaker
should be able to update a medical license but then once that has happened you want everybody to be able to see it and so that's kind of those are the use cases that are really where blockchain really makes a lot of sense so essentially what we want to do is so the first system we've built out and which we will probably make publicly accessible
00:54:19
Speaker
And we work with the Illinois Department of Professional Regulations to design the system. So it's a medical license system for updating medical licenses and keeping track of medical licenses. And it runs on a public blockchain.
00:54:35
Speaker
And what we want there is the fact is we have an answer now as to what the most secure way is to digitally sign information. The most secure way to digitally sign information
00:54:50
Speaker
is the Bitcoin and the Ethereum transaction signing mechanism. Why are those the most secure in the world? Because we now have multiple years of empirical data that people have stored billions of dollars in Bitcoin and Ethereum accounts, and nobody's been able to hack them by using the low-level mechanisms of these systems.
00:55:14
Speaker
So shouldn't we use those exact same digital signing algorithms to update a medical license? You know, right now, if you were to look at any kind of medical licensing system, the security there is relying on like one ASP.net programmer, that you hope is good, that built the authentication system around that software, right? And, you know, with our company, we don't want to be security experts, because we have the world's most secure data structure, which is the blockchain and
00:55:42
Speaker
Yeah, so we're working on that. Another really valuable use case is around what a lot of the problem is that there's so many hospitals in the world. And these hospitals have a lot of data that's valuable to companies, maybe just in terms of like, you know, who, you know, when people what's the current provider list, and who's who are employees, and
00:56:07
Speaker
and other information about what equipment they have. So there's a lot of data there, and there's very difficult issues around scalability for them to be able to, like, there's no incentive for them to provide that data to outside companies, because
00:56:26
Speaker
a company can't talk to call up every hospital in the country and say, hey, we're interested in knowing how many of these types of radiological equipment you have. Can we buy that from you? Like they can't have a conversation. So there has to be some mechanism
00:56:42
Speaker
for, again, outpatient data. We're talking just sort of facility and employee information where we can provide a scalable mechanism for aggregating that and giving incentives to hospitals to provide that data.
00:57:00
Speaker
But where does Closure and the thing that we talked about like Closure and then you said Closure is one of the probably your secret weapon for conquering blockchain. Yeah. So where does Closure come into the picture? So how do you use Closure for blockchain?
00:57:17
Speaker
Yeah, I mean, at the most basic level, so all web apps now are client server applications. And what's happening now with blockchain is you have these things called dApps. These are applications that they basically have a bundle of HTML and JavaScript.
00:57:37
Speaker
and that sort of provide the static assets for that application. But then the dynamic assets for that application are directly pulled out of a blockchain by the client without communicating with the server. Because that's the goal. The goal is to not have centralized failure points. And you want your client application to be able to directly communicate with the network. That's how you get the highest security, the highest reliability, and you don't have to deal with infrastructure for a data center.
00:58:07
Speaker
And the problem there is that programmers, JavaScript programmers are used to the idea that they own the full stack, including the server, and the server can massage data in a very specific format that makes the life for the JavaScript in the client as easy as possible.
00:58:30
Speaker
And the thing is that with blockchain applications, that's not the case. Data, when you write a properly optimized blockchain application in something like Ethereum that has smart contracts and where you can write actual programming logic that's enforced by the blockchain, you
00:58:50
Speaker
The data, the way that the data is structured on the blockchain, the top priority for the structure of that data is efficient validation by nodes inside of the network. It's not structured in a way to make application developers' lives easy. So what you end up doing in a DAP,
00:59:15
Speaker
is your client application will have to fire off maybe 50, 100 different queries to the blockchain that hit different parts of it. There's these log structures that you have to hit. And then there's also client local state that's within smart contracts. And you have to aggregate that all asynchronously in parallel
00:59:36
Speaker
and then gather it and turn it into a meaningful data structure. And you have to do that in a way that's as performant as possible. And you have to do that inside the browser. So that's where Core Async and Closure are your best friends. Because with Core Async, it's very easy to fire off multiple requests.
01:00:01
Speaker
to in parallel and to have very clean bookkeeping in terms of as the results come in that you properly assemble a massage piece of data that you can push into the UI part of your code. Of course, you can still do all of this with JavaScript, you can use promises, but it'll turn very ugly very quickly and having a proper channel system with Go blocks and having
01:00:30
Speaker
closure is a big benefit there. And of course, this ties in directly to QLKit, right? Because what we want to be able to do in the UI is just say, you know, a UI component should just say, I don't care what the blockchain looks like. Here's what I need. Somebody else needs to figure out how that maps onto resources on the blockchain. And then the parsers
01:00:54
Speaker
will figure out how to break those requests down into blockchain operations. And this goes beyond Ualkit because you need to have parsers that are wrapped inside of core async operations. So that's something we're going to release in the near future so that you can actually essentially do
01:01:17
Speaker
I mean, this is not totally the right term, but you can basically do multi-threaded parsers inside the browser because CoreAsync gives you something like a fake multi-threaded programming environment, which JavaScript doesn't have. So soon we'll have a good library to deal with blockchain enclosure then.
01:01:37
Speaker
But there are other initiatives like Status and District 0x or something. The guys are using Closure, those folks are using Closure and they are building dApps, especially status people, they're building dApps on top of Ethereum blockchain, right?
01:01:55
Speaker
I haven't had any chance to dig into their code base. I mean, there's so much stuff going on right now in the blockchain world. And I know some folks at Status very well. There's only a small sort of closure community in this space. And yeah, so I'm not sure exactly what they're doing.
01:02:16
Speaker
I haven't had time to dig into that, but we're definitely hoping to release a blockchain toolkit for Closure and QLKit. That's good, because I'm actually working on a blockchain startup as well, so we'll have to chat afterwards. Awesome. So off screen, we're going to talk about whether to sell Ethereum or not. Interesting.
01:02:36
Speaker
At this point, I just want to touch on one thing, which is that I think a lot of people that are in on this call are functional programming geeks and stuff and are wondering, is it worth getting into the whole blockchain thing? There's one thing that having been in the community for a while, it's clear that the blockchain community is dysfunctional at the moment.
01:03:05
Speaker
And the reason for that is that, you know, obviously, the main reason is because it has to do with money, right? And what has happened is, you know, the reason I found back in 2011, you know, I've been kind of in this for a while, back in 2011, when I got into Bitcoin, what really appealed, what I found appealing about it
01:03:32
Speaker
is that, I'm trying to remember what the name is of that, the bank robber with the famous quote, I can't think of his name now, but they asked him, no, no, no, but it's this old quote from this bank robber, but they asked him why he robbed banks and his answer was because that's where the money is, right?
01:03:52
Speaker
And so me as an enterprise employee for a long time, I always kind of felt like large companies undervalue their tech talent and place more value into like sales departments and into
01:04:09
Speaker
the management layer. I think part of the reason why that was historically is that those people were more able to clearly show an ROI for their employment. Whereas in the tech world, we were always on the very opposite side of the part of the business that brings in money.
01:04:31
Speaker
And so it was very hard to make a case for your value in an organization. So to me, like this cryptocurrency stuff, what at some level made it really exciting is that this is programmers that directly interact with money.
01:04:46
Speaker
at a fundamental level, and now we techies can have our hands on the money strings. We own money. I found that really exciting, but now, of course, the problem is that if you take a look at something like the programming language communities, we certainly have a lot of flame wars and
01:05:10
Speaker
you know, arguments about static versus dynamic typing and stuff. But at the end of the day, oh, yeah, somebody just said the bank robber was Willie Sutton. Yeah, that's wonderful. Martin, he said, Willie Sutton from Livestream. Yeah, that was him. Yeah. So we have the money as programmers. Yeah, so we have the money. But part of the problem is now that
01:05:33
Speaker
if you look at the programming language community, if I'm having an argument with somebody who thinks static typing or Haskell is better than Lisp or whatever, at the end of the day, we both know that the reason we're having this argument is that for the most part, everybody has good intentions, and we want to actually figure out what's the best answer, what is the better language, right? So there's a certain limit as to how ugly things can get, whereas in the crypto community, especially with Bitcoin,
01:06:01
Speaker
things get really ugly. And again, it's the fact that there's money involved. And if you as a closure developer, if you go for the first time and you start reading these white papers that people are putting out in the crypto community, you'll see very quickly that some staggering amount of the
01:06:25
Speaker
projects that are coming out and that have what look like serious people backing them with a budget. Like saying like 99% of them are just fundamentally bad ideas and at a technical level just wouldn't work. So and you know, maybe it's not quite that high. Maybe I there are some ideas in there where I don't see the value, but I'm just amazed at how crappy the work
01:06:46
Speaker
coming out of the crypto community is right now from a technical level. And the reason for that is that money is making it hard for people to figure out what's good and what's bad because it prevents the quality work from rising to the top because people will shout out the good work. And so there's a large noise to quality ratio there.
01:07:11
Speaker
And also the other problem is that it was very random that like there's people that made enormous amounts of money in the crypto world. And the people that made that money was made in a very sort of random haphazard way. So I really wonder at some of these large blockchain businesses, like ConsenSys, it must be weird because there must be like two programmers sitting next to each other, where one of them is a hundred fold millionaire.
01:07:36
Speaker
And the other one doesn't have enough for lunch. How do you run a company that way? I have no idea. And that, again, adds so much distortion. Now, of course, I think the answer. So anyway, so the reason I bring that up is just that I think a lot of people from the programming language world
01:07:57
Speaker
are going to, you know, might get a bit turned off by that. And I'm just saying, yeah, unfortunately, this is true. And what we all we can hope is that that market forces eventually start coming into play, and that there will be more accountability, that your product has to actually do something useful, and that people that can produce good work start being promoted. But right now, that's just not the case. It's a it's a Wild West. And it's hard to figure out what what is good and what is bad.
01:08:25
Speaker
It is interesting because, you know, in the beginning of the show, we were discussing that, you know, to make the ideas like complex ideas accessible to people. And then that reminded me of, you know, the crypto kitties on Ethereum blockchain. That sounded like completely stupid idea, but then the paper all talks about like, oh, we're going to bring in blockchain to people to make people understand blockchain. But what do you think of crypto kitty? Should I buy crypto kitty now?
01:08:53
Speaker
I don't know. I think it's a great project. Now, the problem, of course, with it is that it's essentially just like another type of money, right? And it's very similar to money. People have been trying to make a successful Ethereum game for a long time, including myself, but I never released anything because it was never good enough. And
01:09:15
Speaker
And anything that's successful in crypto is basically just new types of money. So there's Bitcoin was successful, ICOs. So the reason Ethereum is worth a lot is because people make ICOs on Ethereum. But ICOs are just like another form of private money.
01:09:32
Speaker
And then crypto kitties is another form of money. So so that there are there like no other than like the idea of using a blockchain for money. No other idea so far has been successful, even though I personally believe the applicability of this technology is very wide ranging.
01:09:50
Speaker
I mean, it's kind of, in a way, kind of an embarrassment at how little utility these systems have after all this time. And that, again, is causing a lot of dysfunction, I think, in the blockchain community. And it's part of the reason, I think, also why there isn't a lot of diversity, like there's no women or that kind of stuff. Which, I mean, all tech sectors kind of have those kinds of problems. But I think in crypto, it's particularly marked.
01:10:18
Speaker
Yeah, I was going to say the other thing that I see happening as well is that people say, yeah, crypto, the whole blockchain thing is too hard. It's not offering value. I saw this presentation by a guy, X CouchDB guy, who's made this thing called FaunaDB.
01:10:39
Speaker
And what he's done is he said, okay, well, what we want from the blockchain is a distributed ledger. So actually, why do we need the blockchain? It's pretty horrible. So let's just write a distributed ledger system using Amazon Lambdas. So
01:10:56
Speaker
I think he's way, way, way off because he's missing the point of the blockchain, which is this nature of the cryptography and the public nature of the data and the fact that you can verify things and trust things. These are much more important than using lambdas to store shit. That seems like, again, there's a sort of
01:11:19
Speaker
People don't get it yet, I think. I think there's a kind of, the penny hasn't dropped. Certainly from an external perspective, it's just about making money. Oh, these big cryptocurrencies, shall I invest or shall I invest? I think that's a really stupid question. The really better question is, what is this thing? How should it work? What are the benefits of this thing? And I think you've put it much better, which is that really what we're interested in is the security and the cryptography and the verifiability around this thing.
01:11:47
Speaker
that those are the key like value propositions if you like of the blockchain and all this other stuff is just bullshit yeah i mean it it's very tempting to say hey uh this blockchain is cool let's just stick it in our data center behind a firewall and we'll just stick the same private data on it as we always have and uh and we'll call it a blockchain and that that's somehow
01:12:09
Speaker
will be better than existing technology. And I think there are use cases for private blockchains, but yeah, it's really strange, right? I mean, I think us in the functional community, functional programming community can understand this because like we've had conversations with people that are not into functional programming and it's really hard. There's very smart people that you can talk to and you can try to tell them why they should use functional programming. And it's hard to make a good argument for it. It's just like you either get it or you don't.
01:12:39
Speaker
And you can be very smart and think that functional programming is just a giant waste of time. And that's the same thing around the public aspects of blockchain and the validation aspects of blockchain. Like that to me is where the story lies. But you can't really articulate a good reason for that.
01:13:06
Speaker
either people get it or if they don't get it, they'll get it three or four years from now. Once the technology has shaken out and they'll see that all successful products in this space will use that aspect of it, assuming that the world ends up that way.
01:13:23
Speaker
So before we get into that one, I want to take a couple of questions that we had on Twitter as well. So someone asked about Gerardo Lopez Sousa. I hope I'm pronouncing your name right. I apologize if I didn't. So he says, how to mitigate the complexity of multi-methods to resolve queries on QLKit? What is the best approach to testing?
01:13:46
Speaker
Yeah, so around complexity of queries. So this is kind of the cost of any kind of graph query system is the idea is that you have to actually parse these, you're creating these queries and then the next thing you do is you have to parse them. And it's like, why the heck do I,
01:14:03
Speaker
do I go through all this trouble, right? So first of all, you don't have to use multi-methods with QLKit. You can use regular functions. You can just define a function that handles reads or mutates, and then it will get the query as a parameter, and you can
01:14:23
Speaker
do what you need to do so you don't have to use multi-methods. Then, of course, there's helper functions that handle the recursive aspect where you have a query that has, you have a providers list query and then that has individual provider items in it, and then each provider has a name. There's helper functions that let you handle that recursive side of things, which is really the most complicated part of it.
01:14:52
Speaker
At the end of the day, the whole idea is that unlike other frameworks, you're going to have to do a lot more work around parsing of queries. The idea is that that will give you more benefits in other parts of your application. Then the second part of the question, what was it again?
01:15:12
Speaker
What is the best approach to testing in QLKit? So I think the testing story around these types of systems is really good. So there's kind of two things you want to test. One is the whole parsing, like if I send a query, will I get the right result? Now, QLKit makes a simplification. It maintains some global state.
01:15:36
Speaker
that's used in the parsing process because your parsers are just essentially taking data and then passing it off to children. And that starts getting tiresome. There's a lot of bookkeeping where you're kind of moving data around. So what we did is
01:15:51
Speaker
both in the browser and in the server side, there's a mount command where you can just say, here's everything that we want to do. And then the parsers have access to that. And so for certain sort of global things, like where does the state live for the global state? You don't have to pass the state in, which is different from omNEXT. Well, omNEXT uses an environment system, so it kind of has a middle ground there.
01:16:17
Speaker
So the way you test, and you can see this in the QLKit test that we have, is you just in a test, you just mount a piece of data in the state, and then you can run a bunch of queries and seem to get the right answer.
01:16:39
Speaker
and then that's it. Then in your next test, you can mount something else. There is a stateful component there. You don't just pass into the queries everything that they need. You have to first mount something that initializes the parsing system, and then you can run queries against that. Then the other thing you want to test is the UI.
01:17:02
Speaker
The way React and the way Next work is that the render function returns a bunch of nested React components, and they have some weird system where they do that in a really lightweight with special constructors and stuff in JavaScript. That's hard to test because it might be nice to write a test where you say, if this component gets this data, what will it look like?
01:17:31
Speaker
So with QLKit, we actually output essentially what you would either call subloano or hiccup. So we just return an even data structure as the render result. And so now it's easier to write a test where you just say, this is the even that should come out of this component when it gets this state and these other properties. It's more of a functional transform.
01:17:57
Speaker
Yeah, so it's more like that. Now with the limitation that event handlers, it's really hard to not return a function to handle an event when you're rendering. So if you do unit testing, you would just have to skip. When you compare data structures, you will have to skip over the event function because that's kind of impenetrable at render time.
01:18:22
Speaker
to test what would happen after the rendering when somebody clicks on this button or whatever. Anyway.
01:18:29
Speaker
So the other I think probably one of the last questions that somebody from the YouTube stream is asking. So because the Bitcoin has this inefficiency, you know, with all the energy for using a lot of energy, etc. So the question is, is this a less of a problem for smart contracts like the medical licenses that you just explained, like the usage of energy and then the cost and efficiency?
01:18:55
Speaker
Yeah, so this is one of the largest flame wars in the cryptocurrency world. So there's two ways of maintaining consensus on a blockchain, essentially. One is called proof of work and one is called proof of stake. And Bitcoin uses proof of work and it requires basically running
01:19:16
Speaker
Bitcoin requires more energy than the country of Ireland or something crazy like that. And in fact, I think that Ethereum requires even more, which is people don't realize because there's actually more computing power being put towards Ethereum than towards Bitcoin because the absolute amount of money paid to miners in Ethereum right now is actually higher than Bitcoin.
01:19:42
Speaker
I think that because of how it's designed, they ended up just handing out more money to miners. But anyway, so both of them have this problem. But there is this thing called proof of stake. And I'm in the camp where I believe that it's going to be a piece of cake to move over to a piece of proof of stake. And proof of stake basically doesn't have any sort of energy efficiency, other than just a traditional data center where you just have to
01:20:09
Speaker
You need servers to talk to, but it doesn't have to do complex calculations or anything and burn electricity the way proof of work does. And the problem is that for the people that say proof of stake is a bad idea, the only way to really prove them wrong is to get empirical data. So that will take time.
01:20:29
Speaker
The bigger thing, I mean the big issue in 2018 for blockchain is scalability. How do we let people create transactions and move money around and call smart contracts in a way that's cheaper, where they can do it without paying high network fees. And that's a really difficult problem.
01:20:51
Speaker
you know, since we are able to kind of have some forward-looking approach at our company, we are trying, we are working on some stuff in that direction. But it's technically very difficult, so the likelihood of success is, you know, you have to keep that in mind that we'll be able to come up
01:21:11
Speaker
Obviously, we don't want to get into this blockchain too much and then make this podcast about blockchain. Otherwise, we'll probably go into all sorts of directions. So I think one final question, Emacs or some other crap? Definitely Emacs. Okay. I think you win, obviously. You win the internet now.
01:21:32
Speaker
I think it's been blow by blow for Ray now. These days, every guest that comes on, they say, Max, and then Ray is like, oh my god, my life is meaningless now. I think it's like a random number system. You get a lot of fives. We'll get a six eventually. I have fifth. Exactly.
01:21:52
Speaker
Yeah, I think, oh, we're almost one and a half hour. Maybe we should just close down, or at least close the recording by, you've been remembering the stuff for, sorry, not remembering, somebody typed remember, I'm just typing, I'm just saying what did I say. You just posted something about the animation stuff. So a quick overview of that one, what are you trying to do there? It's like a generation animation.
01:22:21
Speaker
So the basic idea is, I mean, you know, we kind of have to look at what are like the big exciting problems in the world. And I think the exciting, the most exciting thing in computer science really is machine learning and blockchain tech right now. But I just find it fascinating how, you know, how important it is to be able to communicate with people, you know, as I tried to do with my books. And it's clear that like Hollywood is essentially slowly turning into a giant animation studio.
01:22:48
Speaker
And so animation is really interesting in that it's actually kind of important. There'll probably be the day where 5% of the world population is animators because these are the last jobs that everyone's going to be doing is feeding the machine learning systems and doing animation and stuff. And it seems to me that the technology
01:23:16
Speaker
for the animation tools, that there's a lot of room for improvement there. And I'm no expert by any means, but I've used Blender and what is it called? Tune Boom and those kinds of things.
01:23:32
Speaker
And they all just feel like you're being thrown into the cockpit of an airplane when you first fire them up. There's just a million dialogue boxes and it's impossible to see how everything fits together. And I think what it really comes down to is, so where I think these, yeah, I mean, I see several different
01:23:52
Speaker
places where this could be optimized. I've been working on my own development framework. If you go to forwardblockchain.com, there's a video there for our company. All the animation there, I actually built myself using my own animation tools from scratch. The basic idea behind it is, we want to apply functional programming to animation, which means that instead of building up these very brittle scene descriptions,
01:24:20
Speaker
that build this big tree of what are all the objects and when does this arm move there and when does that happen there. Everything is really brittle because you just build it once and then if somebody wants to change, you have to throw away a big piece of it because there's a lot of dependencies that make it hard to disentangle things after the fact. This is a typical example where we want to use the functional programming style
01:24:50
Speaker
to it so that we can have the posability of the different parts. But the problem, yeah, and so the core problem in general with animation, I think, is that on the one hand, you want to be able to tell a story
01:25:07
Speaker
And you want to think in sort of in a human way about animation, which to me basically means you think in terms of the storyboard, you know, this person walks into the room, then they talk to that person, then they hand them this object. And that's kind of how a human would describe a story. But of course, if
01:25:25
Speaker
If you want to take animation to its most primitive form, the most primitive form of animation would be something like a raw physics engine, where you simulate molecules bouncing around. That mechanistic way of thinking about the world is very incompatible with the way
01:25:46
Speaker
humans tell stories. And so a lot of these animation tools are fighting that, that divide. So so like if you, you know, so if you if you if in an animation program, if, if you take an object and they and you know, like a ball and one person throws it to another, what you do is you use something like a motion path and you use things like easing,
01:26:04
Speaker
And then, but then the animator, they have to do a lot of work because when the other guy catches the ball, you know, they'll learn, oh, well, they can't just catch the ball. You know, the ball has to have weight. And so and then they learn that the motion path has to go down and the person has a struggle to catch the ball and all that. And and it seems like
01:26:24
Speaker
I think that there could be something interesting where you build a tool where you basically describe in a domain-specific language in something like Eden what the different scenes are and then you
01:26:37
Speaker
And then you can attach to it physics properties to near the objects and things, and then kind of have an algorithm that kind of reconciles the two. So it reconciles the physics with the storytelling. So if they have to throw a ball, it figures out how far they are apart and how high like you would throw a ball in that case. And if it guesses it wrong,
01:27:03
Speaker
and somebody can adjust it. But actually, the way I'm building it is I'm basing it on a library called React Motion, which is an animation library for React. And it's interesting because it uses a spring animation for letting you have animation in your React app.
01:27:24
Speaker
The amount of time it will take for an object to move from one place to another in React Motion changes depending on how far the places are that it has to move. Usually when we think of doing animation in a website, we say, okay, I'm going to give two seconds for this when the person drags this over here, it's going to take two seconds to go over there. But React Motion says, no, we have to take the physics into account. In React Motion, you just say, well, I want the object to be here.
01:27:53
Speaker
Then the library figures out how to get it there in the most natural pleasing way. The framework I'm doing, it actually looks like React programming. You have a render function, but then you have another function for describing the physical properties of the components in the animation. Then you have another function where you can build out the storyboard for each component as it changes over time. That's roughly what I'm doing. I just posted on
01:28:22
Speaker
a quick demo app that kind of shows how you would animate a ball using these kinds of ideas. I think we'll post the link on the notes of the show. I think we came almost to the conclusion of today's thing. Just a couple of announcements I want to make.
01:28:42
Speaker
One is that we have Dutch closure day coming up on April 21st, Saturday in Amsterdam. So you're welcome to join. If you want to come to Amsterdam on a nice weather, it's going to be a lot of tulips around. So it'll be lovely to have you there. I don't know if you've ever been to Amsterdam. So consider this as a formal invitation from us.
01:29:04
Speaker
Oh, thanks. It's tough with a family to travel like that. I think you should bring everybody. That's the whole idea. When is it again? You should bring everyone. When is it again?
01:29:18
Speaker
I think it's April 21st. Okay, yeah. It'll be tough. It's a good time. But anyway, so the call for proposals is still open. I'm not sure by the time we release the episode if it will be open, probably because we're gonna end CFP on end of February.
01:29:36
Speaker
And it's going to be an amazing day again. This is the third time we're organizing. And next week, Ray and I, and also Wouter, our maestro behind the scenes who fixes all our sounding issues, is also going to be there in Germany, in Berlin. So I'll be speaking there about Onyx, and Ray will be offending everybody there with his deaf jokes. So if you're around, please stop by and say hi.
01:30:05
Speaker
Once again, Konrad, thanks a lot for joining us. There are a lot of topics that we discussed. You're doing this blockchain stuff, animation, QL kit, medicine, writing books and stuff. There are still a lot of things to talk about, so we'd love to have you back on
Conclusion and Future Episodes
01:30:25
Speaker
the show.
01:30:25
Speaker
Yeah, yeah, I'd be happy to come back sometime. Perfect. That's it from us. I think you'll see this episode on the... Well, we've been live streaming it, so we will try to do this every episode as well. And for the folks who want to see this videos later, we only restricted to the people who pay us with the money, real money.
01:30:51
Speaker
So we have Patreon, that's the idea. So if you think we're doing some useful job, go ahead and then click us and then show us your support. And the people who are supporting us, we are very grateful. And that's it from us on this nice springy Sunday from Holland. Goodbye. Goodbye. Yeah, great to meet you guys. It was a lot of fun. Bye bye.
01:31:47
Speaker
So I think it's a kind of dating application as well, you know, so we don't want to get involved in that.