Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
# 31 - Bruce Figgy Hauman aka @bhauman
48 Plays8 years ago
Oh man, so nice to speak with Bruce. He is such a great programmer and has inspired the whole Clojure community with his amazing tools.
It's a long episode, as it should be.
Recommended
Transcript
Introduction and Welcome
00:00:15
Speaker
Welcome to Deafend episode number 30 something. 31? 31 yeah. Yes 31 yeah. So this is our second episode in which we are trying to live stream this stuff. So just a quick hi to all the people who have joined in and we have I think around 14 people. So please post your questions or anything during the show and we'll happily
00:00:42
Speaker
try to read them out loud and then so Bruce can answer them. Or if you have any questions for us, you know, we'd love to answer them as well in whatever the way we can. So let's get started.
Meet Bruce Hallman
00:00:55
Speaker
So Bruce, please introduce yourself.
00:00:59
Speaker
Because it's my job. I will do the introductions here. My name is Bruce Hallman, and this is a Closure Podcast, so I... Hey, Bruce, how do you pronounce your last name? Ho-man. How-man. I say How-man. That is correct. That is correct. How-man is the correct pronunciation. And yeah, it's not a common name. It's not a common name.
00:01:29
Speaker
Seems like a German name, is that right? Or European name? It is a German name. So I have a German and Norwegian ancestry. So... Right, okay. Perfect American.
Journey into ClosureScript
00:01:40
Speaker
Oh, God. Sorry, we'll stop now. Stop at that. Stop talking about that. Back to Claudius. Surf space, surf space. My goodness.
00:01:57
Speaker
Back to Clojure. Yeah, I think people know me for Fig Wheel, mostly, and dev cards, and a couple talks I gave on ClojureScript. Yeah, and that's, in this context, I think that's probably the best way to... But how did you get to Fig Wheel? I mean, of course, we can talk about Fig Wheel, obviously. That is one of the, I think, kind of a game-changing stuff for ClojureScript stuff. I mean, every time I want to show something,
00:02:26
Speaker
But to any non-closure script people, I just show this. And look, this is the tooling that you need for building anything that is remotely awesome or remotely useful compared
Creation of Fig Wheel
00:02:40
Speaker
to the other languages. But how did you get into closure? Oh, how I got into closure? Well, I'm a whisper schemer from early on in my career.
00:02:55
Speaker
And not professionally, but just in school. I was a languages guy. I liked parsers. I liked languages. So Scheme and the Scheme community, especially Dr. Scheme and the PLT community, I was part of that. I worked on the pattern matching library for Dr. Scheme, which is now Racket. And when I was in college,
00:03:24
Speaker
And I don't know, so I've always had a penchant for Lisp in general. But you go into the real world and you work in Ruby or PHP or Java, whatever. And I did that for quite a while and ended up getting really sick of it. There is a point where you're just
00:03:53
Speaker
You're done. And my friend, good friend Toby Crawley was using closure. You know, he's building a mutant.
00:04:00
Speaker
And he was telling me about it. And it was a list. So it wasn't a hard sell. It wasn't really a hard sell at all. And so I kind of burnt out where I worked on a startup. And I was like, OK. And I burnt down on this large monolithic
Impact of Fig Wheel
00:04:20
Speaker
Ruby code base. And I was just done. How many more features can we pack on this application?
00:04:28
Speaker
And there's a point where your brain just says, why am I doing this and why am I doing it in one thread? Yeah.
00:04:42
Speaker
I happily took a pretty long hiatus and started playing with ClosureScript initially because I've always been a front-end guy, I've always been a UI guy, and I feel really comfortable in that domain. And ClosureScript was rougher back then when I started, but yeah, it was a bit rougher.
00:05:06
Speaker
but I really liked it. I really liked the language. And yeah, and so I was on a hiatus. I was introduced to ClosureScript. Working with ClosureScript was problematic and that led to Fig Wheel.
00:05:25
Speaker
No, I was just saying this is like one of those Hollywood movies where, you know, you got sick of all these shitty languages and you are somewhere living like a hermit. And there is this CIA people coming in and then saying, OK, you need to build something for us. And OK, I'm going to come back and build a fig wheel for you.
00:05:42
Speaker
Yeah, well, I like that. I like that dramatization of it. I am the hero in this scenario, so this is fine with me. That's terrific. I'm not the guy... You are indeed a hero. You have no idea how fig will change my life.
Evolution of ClosureScript
00:06:00
Speaker
But there is a question from one of our audience now. So do you still live in your dome, or is this a permanent house? Yeah. There are walls around me as we speak. I am in an apartment in Montreal. It is snowing outside. Yeah. Yeah. It's good to have solid walls. I'm telling you. Yeah.
00:06:30
Speaker
I did live in that dome for quite a while. Right now I'm not. I'm going to be in Montreal for a year at least.
00:06:37
Speaker
That was a bit of a non sequitur, I'm afraid. No, it's fine. Let's get off the dome and under something else. So I was going to say to you, Bruce, I mean, you know, you kind of like went from like closer script was a bit rough. So let's do Fig Wheel. I mean, but Fig Wheel is quite a big jump, wasn't it? I mean, it was like like real kind of, you know, Brett Victor was doing this stuff. Yeah. Bullshit wise, you know, a few years ago. But this made it real, you know. Yeah.
00:07:06
Speaker
Well, the thing, I just happened to be like the right person in the right place at the right time, right? Because you think about like, it was just a confluence of ideas.
Benefits of Exploratory Programming
00:07:20
Speaker
One, like, so ClosureScript, you could load files, right? I mean, ClosureScript, if you got the browser REPL up and running,
00:07:29
Speaker
and for somehow connected it to your editor. And then, you know, if you got this working somehow you could
00:07:38
Speaker
theoretically load files in real time. Now, none of this was working very well or at all, right? But you could load files into a process, like the tools and the possibility for loading files was there. And the Closure Compiler doesn't do strange encapsulation of their modules. They're just JavaScript objects, right?
00:08:07
Speaker
object literals in JavaScript. So boom, you can overwrite all the function definitions just by loading a file. And then most of the functions, most of the definitions are functions, right? You're not like clobbering state when you reload. And so like Closure had all this there already, right? And then React came along and it was kind of like
00:08:33
Speaker
Oh, well, this is a done deal. There's no reason why this shouldn't happen. And as far as the auto workload is concerned, that happened because the REPL didn't work. The REPL did not really
Dynamic vs Static Languages
00:08:50
Speaker
work that well. And so I needed another way to get feedback
00:08:54
Speaker
And so just having it load when you save a file was kind of like the next thing. And I tried it. I tried it, and I thought I was crazy for trying it. I tried it. It worked. I was shocked that it worked. I was shocked that it worked so well. And so then I've told the story of my talk, but yeah, it's how it actually happened. So go and watch his talk.
00:09:25
Speaker
What was that again? No, so go and watch his talk. So that's the cue here. But yeah, but it was just all the right things came in and all the right pieces were there. And I was like, you know, it doesn't sound like a good idea to reload into a running environment as you save a file. And so I was like, it doesn't sound like a good idea, but I'm going to try it anyway. And it worked out. So.
00:09:53
Speaker
So the question that comes from that, and you do answer this a little bit in the blog as well, is the reloading bit. And you have this problem, if you like, with the way that you write code, because now you have to start doing
00:10:11
Speaker
This, you know, thinking about state. So what, what, I mean, how have you kind of thoughts evolved on that one, Bruce, or is that like this writing reloadable code you have here? Yeah, yeah, yeah, yeah. So how I've evolved, like, so
Minimal Libraries Preference
00:10:30
Speaker
I think Figuille had a big impact in terms of adoption of ClosureScript, I think. But unfortunately, it made it easier for people to start using ClosureScript. The downside was this auto loading part. Because if people have not thought about the load time side effects of their code,
00:10:56
Speaker
which probably very few people have to this extent. It can be hell, right? If you're like, I want to just bang on stateful objects all day long, like 3JS stuff. And if you want to do stuff that's super stateful,
00:11:14
Speaker
And it can become quite, quite difficult. It can be a very, very difficult experience. You can turn that off, but who's going to? Then you have to learn about all the configuration. And so as a first time experience, I do worry about the auto loading part of Fig Wheel.
00:11:34
Speaker
You know, it'd be interesting if there were like a tool that like you turn it on and off in the fig wheel like a Tool like in your browser that you could just click on click off the auto loading boom just like that You can do it from the fig wheel REPL you can turn it on and off But again, I don't think a lot of people use those tools But if people could just turn it on and turn it off Then that would get it out of people's way. So
00:12:03
Speaker
Does that, is that an issue of question or are you thinking of something else when you ask that?
00:12:09
Speaker
I was just wondering
Future of ClosureScript
00:12:10
Speaker
like, when you're talking about as a beginner experience, I mean, I use it every day. Thank you very much. Okay. And I use it with reframe applications and, you know, I'm just pressing, I'm just pressing save, pressing save and it's coming up and it's a heads up display and everyone's rocking, you know, we're all happy. So I'm just, well, actually my real question is whether you think it's really an issue anymore in the ClosureScript world, you know, because you were kind of had to think about it,
00:12:37
Speaker
You know, in the early days, because there wasn't much support for this kind of thing and no one really had thought around it, it was a new thing. Yeah. But now that it's like a bigger community, we've got more frameworks, how are you seeing the feedback on that, you know, in real world usage, you know?
00:12:54
Speaker
Oh, gosh, maybe I didn't wake up early enough this morning. I'm having a little bit of a problem grokking the question, do I think it's, are you basically saying, do I think, do people even have to worry about thinking about the load time side effects of the code or is now it just becomes second nature to them and all the frameworks support it?
00:13:15
Speaker
Now, exactly. Yeah, that's what I mean by evolution. When you first started, you have to worry about this because, yes, it was an issue when JavaScript people coming to it from the beginning, you're thinking about them. But in the ClosureScript community, it seems like it doesn't seem like it's a big issue anymore. No, I would say I would agree with that. And I think, again, there are certain applications
00:13:41
Speaker
When you use Figuilon node, it's a different experience. You don't have a heads-up display. The running model inside of node is different. You're loading your code in real time, but the trade-off is a little narrower
Strictly Specking and Feedback
00:14:00
Speaker
there. It would be nice if you did have maybe a browser window giving you feedback.
00:14:06
Speaker
from the node process or duh duh duh duh duh. Maybe this is a new thing though because I've never used it with nodes. I didn't even know that was possible. I didn't even know that was possible. What the hell are you doing with that? Yeah, Figma works in node. It works in React Native. It gets around.
00:14:28
Speaker
He gets around in the nicest sense possible. And you can use it. You can develop Chrome plugins. You can do all these things with Figuille. Some of them, the setup is much harder than others, obviously.
00:14:45
Speaker
But yeah, yeah, yeah. So there are different trade-offs in these different environments. The browsers, if you're developing for the browser, I think your argument is correct. If you're developing for the browser, it seems like in the greater ClosureScript community, this is a solved problem. We like to isolate our state into one place. And even better than it being a solved problem, like Fig Wheel,
00:15:09
Speaker
by being the go-to tool forces people who are not used to doing that to do that and get on board pretty quickly because your return on investment for figuring out is pretty high. You're now developing in real time and getting this great feedback and everything. So yeah. So Bruce. Yeah.
00:15:37
Speaker
I mean, I see that most of your,
Improving Error Messages
00:15:40
Speaker
at least so far, we're only talking about closure script. So, what is your take on closure side of the world? Because you said, okay, you know, single threading and then all that stuff and closure script. And now, how much closure code do you write? Well, FigWell is a...
00:16:00
Speaker
Figuil is written in Closure. Using Closure to build other applications rather than tooling. You're saying how much real-world experience do I have with Closure itself?
00:16:14
Speaker
I wouldn't put it that way. Are you a real programmer Bruce? Exactly. That's the bigger question. No. The answer to that is always no. I am not a real programmer. Who does this stuff really? I just do cool demos that make people think.
00:16:35
Speaker
I can program. Success at that machine. Make them think that they can too. Forget that question. It was my question to myself, so I can still blame you guys for it. So no, I would say I do not have that much
00:17:03
Speaker
Professional experience with closure, but I've used closure quite a bit And again, like I've spent a lot of time working
REPL's Transformative Influence
00:17:10
Speaker
on fig wheel and it is a crazy program in a lot of ways and I've spent My most recent gig I did a lot of closure and it was closure in in the
00:17:24
Speaker
Combined with aetherium, right? So it was like super cool like extra cool closure aetherium. Come on, so Yeah, so that was mine was it was it a gas. Yeah. Yeah, it was a gas. I mean you know Ow
00:17:48
Speaker
It hurt in a way that you know very few things, you know, like oh the end of the day You know those programming days where at the end you're like, I don't know what day it is and don't ask me to do any date arithmetic or Don't ask me to like put two numbers together, you know, it was so it could it was difficult at times you know, especially when you're dealing with a platform that that is
00:18:14
Speaker
has very little tooling or feedback. It can be very difficult. So yeah. So do we using a closure script or a closure interface for the contracts? Yeah, yeah. We're using a closure interface to the Ethereum virtual machine. And yeah, yeah. So it was yeah, it was cool. It was cool.
00:18:39
Speaker
It was a cool job. But in terms of the larger question, what do I think of Clojure? I love it. In terms of programming experience, I find it much better than ClojureScript. I think it's got a lot of advantages. You're talking to one process.
00:19:08
Speaker
Proper, I love it. Closure script as well. I do not see myself using other languages.
00:19:18
Speaker
ever.
Collaborative Programming with REPLs
00:19:20
Speaker
I really don't. Depending on the problem, obviously, I don't see myself gravitating towards other. I consider closure a kind of strange maximum. It's like, this may be it for a while, guys. I know we have new programming languages coming out and new ideas, but the trade-offs
00:19:46
Speaker
you know, forgetting things done in the real world. I mean, you know, God, I hate to say that. It's so presented. You know, if you actually want to do work, if you want to do work, what are you doing with those other languages? Closure is the one, you know? But that's the way I... In your pretend world. Yeah, yeah, yeah.
00:20:04
Speaker
But that is the way I feel. I hate saying it out loud. But it is the way I feel. I like closure a lot. And if I need to do something,
00:20:16
Speaker
I'm going to reach foreclosure and foreclosure script. So I guess the obvious question is like, what about these situations? I mean, this is a trope, but what the hell? It's nice to hear your attitude about these things. What about these people who say, oh, yeah, but you need those types because then you're guaranteed certain, you know, your bugs are certain, bugs are gone.
00:20:37
Speaker
Once you put it in these types, you've got solid guarantees, you're not going to lose sleep at night. What's your answer to the people? Because obviously, forget spec for a moment, because that's still a bit weaker than real types. But what's your answer to those people who come at you and say, Bruce, you've really got to work with Scarlett or Dale or ML or Haskell or whatever? Well, screw you.
00:21:05
Speaker
No, no, it's just funny. First of all, it is a trope. So we are putting words in other people's mouths. It is, yeah. We are putting words in other people's mouths. But this general idea exists. And I think I'm trying to be not just write this off, but let's just do it and move on. No.
Advancements in Programming Environments
00:21:30
Speaker
I would say.
00:21:35
Speaker
I think they're overblowing the guarantees that they have. They're blowing the guarantees they have up and out of proportion to, again, the real world. If you're deploying 17 microservices, you have a system of state that is so complex, and you're not going to get any sleep at night. So in your types, they're going to give you not a lot of guarantees in that world.
00:22:04
Speaker
If you have a monolithic system that takes in data and spits it out, yeah, you can sleep very, very well. Like, oh, I take in data and I spit it out and I wrote Haskell. Yeah, I can roll with that. I think that is a solid argument. But we know in these real systems that
00:22:29
Speaker
guaranteeing that there's this process. And you do. And we can't say that types aren't helpful while you're programming.
00:22:41
Speaker
That would be like saying spec isn't helpful while you're programming. You can't say they are helpful and it would be great to have the best of all worlds. It would be great to somehow have a trade-off where we have progressive typing and we get these static guarantees. Typed closure is a great idea.
00:23:03
Speaker
If it came in a form that we enjoyed and liked working with,
Creative Processes and Programming
00:23:10
Speaker
no, again, I hope that's- I'm sorry, I didn't mean- Yeah, yeah, yeah. I'm not laughing at- He did his best. I mean, I think it's just extra work for-
00:23:20
Speaker
Until you get to spec, I think it felt like an extra burden for library writers that maybe wasn't getting the payback that it was worth the effort putting into. But nothing wrong with his effort, of course. No, no. And there's just sheer habit. There's a reason we like writing dynamic code. We get things done quickly.
00:23:44
Speaker
Yeah, and and and we pay the price at times for that like we're like, oh, you know Damn, that would have been solved by having types, you know, like I wouldn't had to spend three hours on that, you know if whatever but You know, I would say we are extremely productive. We get a lot, you know closure programmers and
00:24:06
Speaker
You get a lot of bang out of 10 lines of code. Yeah, definitely. You get a lot. And if you ever do advent of code or something like that, and you do a comparison of the solutions,
00:24:21
Speaker
Closure ends up looking pretty nice. It feels to me like this is sort of like strata, certain types of functions or definitions, it would be quite nice if we had types around them.
00:24:36
Speaker
But then when we want to consume data from external sources or explore APIs, we want to be able to do that interactively. It's almost impossible to do that when you have to do all the type ceremony up front. So it feels like, on the one hand, it would be nice to have a bit more typing and speccing on the bedrock. But on the other hand, when you're using the tools to explore stuff,
00:25:01
Speaker
It feels much more productive. That is a much better answer. Let's go with that one. I've been talking too much about this shit, right? I agree with you completely on that. Right. Vijay, what's the next question?
00:25:29
Speaker
Hey, by the way, just while Vijay is thinking about this, I give you a bit of props, by the way, because I had a little issue with FigWheel where I needed to connect up to a local server to do some API stuff. And I ended up being a little bit drop in a little proxy because you designed it in such a nice way. I could drop a little proxy in to connect back the FigWheel client into my API. So I was really happy about that. Super nice.
00:25:59
Speaker
I'm glad. I'm really glad to hear that. Yeah, I think most of that is the cores, right? It's a side channel and so you're not having to combine it with your server per se. Exactly.
00:26:22
Speaker
So I think there are two questions. One is, e-max or some other random shoot? I think I know the answer. Was that really a question, e-max? Exactly. OK, moving on. No, e-max. I mean, but I think that's well known. I use e-max.
00:26:46
Speaker
Okay, obviously that's not a real question, you know, we all know. So, it's so unfair. Exactly. Exactly. So, the other question is, I mean, we're talking about typing and you said you came from scheme and PLT racket and you know that those guys are working for gradual typing and things like that.
00:27:08
Speaker
So how do you contrast them? Because one of the ideas that I heard that I kind of convinced myself that when you're building a program, if you're spending in total, let's say, X amount of time, if you're using dynamic languages, then you spend more time later. Or if you're using static typing, you spend more time upfront. But in total, the time is the same. What do you think about that idea?
00:27:35
Speaker
I mean, that jives with my experience, so that makes sense to me. And the reason I think that I balk, right, against spending that time up front, and I think all of us do, right, so it's like, it kind of was a leading question, which I appreciate because then I don't have to think of everything. Yeah, it's, especially because so much of programming
00:28:05
Speaker
Is exploration, you know, you're exploring Like this will these pieces even fit together? Like I have this library. I have this API. I have this thing I've got to connect them. Are they going to connect? well Do you want to just see if they connect first or do you want to think? You know, do you want to plan it all out and like have the answer, you know, like right off the bat, you know by
00:28:31
Speaker
Because now you have to start characterizing these things. This is now a this and a this, and it has a this and a this in it. And don't forget, oh, forgot about that. And forgot about that. That makes the whole problem really painful. When you forgot about that and you just have to add a key to a map, it's not really a big deal.
00:28:54
Speaker
Right? Like, oh, my type has five fields in it. And I've been decon, you know, I've been, like, de structuring it, you know, in 100 places, and oh, darn, this is unfortunate. But again, yeah, yeah, so I prefer not, I prefer to have the flexibility to explore. And I think a lot
00:29:18
Speaker
A lot of what programmers do is exploratory for a pretty long period of time and then you resolve it. You explore, explore, explore and resolve it down into a hundred lines of code. Explore, explore, explore and then resolve.
00:29:37
Speaker
And yeah, I mean, that's my process. You know, bang on things until they work, you know? And then make it look good and pretend it looked good from the beginning. You like the git squash. Yes.
00:29:55
Speaker
But did you did you play with gradual typing for PLT or racket or things like that? I did not never did. OK, that was it was a long time ago when I did that. So I've never done it.
00:30:09
Speaker
Okay, so if you're building your own full stack application, so what are your choice components these days? I mean, which libraries would you pick for a full stack closure or closure script application? Because there are so many libraries available, so many ways to do things in closure.
00:30:26
Speaker
Oh, my gosh, as few as possible. So I think it's no, no, really, like, as few as possible. Again, like, Closure Script World is still young. You know, the maturity of the libraries is still.
00:30:43
Speaker
And the chance of it going out of fashion is high. Maybe let's put it a different way, Brian. Rather than actually naming libraries and saying which you prefer, because I think that's a bit unfair, what kind of leverage do you want to get out of libraries? Do you want to get leverage in terms of interacting with JavaScript? Or do you want to get leverage in terms of interacting with Node or with
00:31:10
Speaker
Yeah, yeah, yeah. With a browser or with a DOM or, you know, what kind of things are you looking to get leverage from? Okay, I would definitely use React and I would use Sablano. All right, like, so I always use React and Sablano in terms of a front-end application. And then I gradually, like, I build from Sablano and an Atom
00:31:37
Speaker
for as long as I can, right? And so I do it as long as I can, just use React, blah, blah, blah, blah, to see if I can do that. And then if I need some performance, I'll make a pure component or whatever, the pattern where it will only render if a state has changed, period. And then I use that until that doesn't work anymore. And then I start considering other frameworks.
00:32:07
Speaker
And I have a preference for an ohm style where you pass the state. I have a preference for passing the state around and not referencing a global state atom. It's just, and I know reframe, the thing is you can decouple things a little easier that way. And you can do it with reframe as well as long as you pass the state in to a function.
00:32:37
Speaker
So, and I, yeah, so, but true story, I haven't done a lot of Closure skip programming in the last year or so. So, yeah, these things change. And I think though, if I was gonna reach for something today, it would be reagent, reframe, something that everybody uses, it's got a lot of backing, it's got a future,
00:33:05
Speaker
period and but before that I would definitely still you know, you know roll simple until you you need Some more thinking around it, you know And I wouldn't make like making decisions about rest and graph QL and blah blah blah blah like a lot of applications You don't need that
00:33:24
Speaker
until you're a certain size or you're pushing a certain amount of data. A lot of applications are really small. So what you're thinking, just push a little bit of a message or just a JSON API or a sort of transit data over the wire, that kind of thing. Yeah, that's what I do initially with everything because
00:33:50
Speaker
I don't need to solve all the problems when I start picking the libraries for a project. I don't feel that way. You learn so much about the problem you're solving as you're solving it that an early commitment is not necessary.
00:34:13
Speaker
In my mind, but if you do know exactly what you're building and how big it's going to be and you're going to need these characteristics, like if you work for Netflix, you're like, okay, day one, we know we have certain problems that will need to be solved immediately. But for a lot of other things, for a tremendous number of applications, they don't need a serious amount of complexity.
00:34:43
Speaker
And maybe one of the things about closure and closure script is that you can scale that level of complexity out incrementally as well. You have options. You're dealing with functions. You have a lot of options.
00:35:01
Speaker
To change the changes to how the game is played. Yeah along the way you know it's very if you if you do things right right you're very low buying. To any particular thing although getting rid of react to the heart.
00:35:20
Speaker
So do you think ClosureScript is, I think, you keep saying React is the way to go to build applications, at least for you, or at least do you think that has a bright future? Yes. Do you think that is without React? Where do you see ClosureScript? Oh, without React. Yeah.
00:35:42
Speaker
I think of React, first of all, the beginning of your question is do I think ClosureScript is a good platform and do I see it going into the future? I honestly do. I think it's trade-offs for the people who use it. They're not like,
00:36:04
Speaker
worst experience ever. A lot of people, they come on board and they're quite enthusiastic. Thank goodness. This may not be the case if the complexity of the tooling in the JavaScript world has not hit the knee and the exponential curve. It was doing fine and then it just went.
00:36:27
Speaker
He went crazy. He went to the point where you come back to it and you have no idea what's going on. And you're like, wow. And keeping up with it is quite difficult. So Closure offers a tremendous story against that in the workflow and blah, blah, blah, blah. So even outside of React, I think if React did not exist, that the ClosureScript community would write React.
00:36:57
Speaker
Yeah, because we nearly had that, didn't we, recently with the Facebook legal bullshit? Oh, yeah, yeah, yeah, yeah. I don't know, actually, what you're talking about.
00:37:10
Speaker
What it was was that they were saying that everyone that used their software essentially was giving them a free pass to sue the shit out of them. So that was a really weird situation. So if you wrote an application with React,
00:37:27
Speaker
then you couldn't sue Facebook and Facebook could sue you, basically. So it was like a weird, weird legal arrangement where I think, you know, for most of people, it didn't really matter. But I think for people like Netflix or certain bigger companies, Amazon, Google, it was a problem.
00:37:46
Speaker
Yeah, that is a problem. That's definitely a problem. The control over it is not in our hands. I mean, luckily, it all went away, so we were relieved. But it was just a sort of, ooh.
00:38:04
Speaker
Yeah, yeah, that's unfortunate. I'm not well informed on that issue at all. And it's unfortunate to hear that somebody could take my React away. But I promise you, this community,
00:38:22
Speaker
There are people chomping at the bit to rewrite React. It sucks for deployed programs, but ClosureScript is a great language to write a replacement for that. I could see it happening very quickly.
00:38:45
Speaker
Yeah. I think, like you say, the nice thing about it is that Facebook have it. They've got a dozen engineers making the experience smoother, promoting it, building all the ecosystem and infrastructure around it. And that counts for a lot, doesn't it? It's not just a function of the view, is it? Obviously, that's the kind of the abstraction that they're offering. But there's a lot more than that. Yeah, you're right. You're absolutely right. There is a lot more to it. And that's why we use it.
00:39:15
Speaker
That's yet another reason why we use it. But yeah, you're right. Absolutely. And React Native. Yeah, yeah. Let's get into spec a bit. So you wrote this library strictly spec-ing. Yeah. So what is the background on that one? And what is the relationship with spec? And where do you see that thing?
00:39:37
Speaker
So strictly spec'ing was, I mean, is, was, and is primarily, right, so that I could give like feedback for the insane number of configuration parameters that are presented to somebody when they use fig wheel in conjunction with closure, and fig wheel and closure script, right? Like there's just a lot of configuration and the possibility of doing it wrong is very high.
00:40:04
Speaker
Right? Like the possibility that, you know, your assumptions about how the config should work and how it actually works can be widely divergent. So I wrote strictly spec-ing.
00:40:18
Speaker
And the funny thing, this thing took me three months. I started once. I, you know, this is, it started before spec came out, right? So I'm working on this thing and I wrote it once in CoreLogic because I don't like myself, you know?
00:40:39
Speaker
And then I saw how quickly that ran. I'm going to use not. It did not run quickly. It ran so badly. But it was an interesting exercise. But it took a long time. And then I started writing my own version of spec. This is before spec came out. So I started writing my own.
00:41:09
Speaker
And then Speck came out and I was like, well, darn. That's not what I said. I said something else. But yeah, I was like, so then I rewrote it again in Speck.
00:41:25
Speaker
And spec was missing some things. Spec was missing some things. So strictly specking is written in spec. Spec is used as the backend for this. And, yep.
00:41:42
Speaker
And spec was not as programmable as I needed it to be. Because all I wanted was a pointer. I wanted to know where in the data structure I need a path to the point in the data structure where the problem is. And unfortunately, that wasn't easily done in spec. There have been some changes to it.
00:42:10
Speaker
Like I literally had to parse the spec forms from top to bottom in order to get this pathway. And as spec changed, these things changed. So that's half of strictly spec-ing. The other half is like just doing kind of a probability inference of like, what did you mean when you said this?
00:42:35
Speaker
Right? And based on where you typed this, what did you mean? And that's the other part of it. And then printing it out in a way that, you know, within...
00:42:53
Speaker
my words are failing me, then printing it out with a code pointer in your typed code. It was very, very hard to actually write that. It wasn't easy and the library is kind of,
00:43:12
Speaker
Messy or a mess and I'm hoping to You know, I don't know. I hope I get a better idea sometime or a better way of structuring it because I'd like to see it in line I'd like to see it in other other things that are validating a lot of config a lot of complex config But right now I wouldn't I wouldn't advocate its use Out, you know outside of fig wheel really I mean
00:43:39
Speaker
Yeah, we have been discussing this spec things in a couple of episodes these days. And, you know, one of the biggest problems is that the error messages that we put out for people when you're using spec. So what is your opinion on that one? I mean, we've been very vocal about, you know, it's been shitty, so.
00:44:00
Speaker
OK, so you actually broke up a couple of times there, so I didn't hear you precisely. But I think you're asking about the specs error messages. Is that correct? OK, great. And yeah.
00:44:17
Speaker
And there are different contexts here, right? Obviously, like, I think, yeah, like if you're talking about specs error messages for the core macros, like closure core macros and closure core special forms, is that what you're talking about or? Okay, well, if you're talking about those, they're, you know,
00:44:44
Speaker
It's two things, right? On the plus side, you have very precise information about what went wrong. But on the downside, your programming is this experiential interactive activity, and your desire to go from the message to the problem quickly is very hot. You want this to be a quick transition. You don't want to parse spec messages.
00:45:12
Speaker
At that particular moment, especially not for core macros like deafen, you know, like you forgot the vector in deafen and now You think you have this message which is huge now You know moving backwards, so it feels like a devolution, right? Okay, but it's not right. It's a it is a stepping stone because like before it would the messages were ad hoc and
00:45:40
Speaker
They were still helped. They seemed more helpful than the messages we get now in certain situations. But so it feels like a devolution. But now you have precise data. And so on top of that, you could provide very, it would be some work.
00:46:02
Speaker
but you could provide extremely granular, you can, for the core macros now, you can write a library that says, okay, when I get this data, say this. When I get this data, say that. And so you could say precisely what's wrong in all the different situations that somebody types in the def in macro wrong, right? So there is increased, there's increased amount of data
00:46:31
Speaker
But, you know, it's very, and so this can evolve into something better. And I really personally think for the core macros and the core special forms, which essentially are syntax for
00:46:48
Speaker
Laman, you know like for layman their syntax for the core developers and the closure law They're they're they're running code You know, that's that's a macros just another piece of code that's running and I need you know Getting a stack trace into the macro for me is not a big idea. But for newer people it looks like syntax it feels like syntax and It's a syntactic error
00:47:12
Speaker
Now, it's important to have stack traces into macros when we're writing macros. We want to say, oh, it failed in the middle of the macro that I'm writing. And you want this big stack trace and blah, blah, blah, blah. But again, for the core and the core forms, we need better error messages.
00:47:33
Speaker
And right now we have a capacity to provide incredible error messages now that we have this extra data. How's that for like walking the line? You think I did a good job? You avoided every possible mind there.
00:47:51
Speaker
I wasn't, you know, it's too easy, right? It's too easy to be like, screw those error messages. Error messages, what? Am I right? Come on, what's up with those? Exactly. Yeah, but it's also, I think the other problem for me, Bruce, you know, I think you're engineering wise, you're absolutely spot on.
00:48:11
Speaker
But I think from a kind of experience perspective, it's way off. So I don't think it's actually, I think engineering-wise, it's been a definite step forward. But I think experience-wise, I think they've shot themselves in the foot a little bit. And that's a shame, you know? Yeah, I agree. I agree. I think that, yeah, I agree. The experience, when you're left with a question mark, a big question mark when a common error occurs,
00:48:42
Speaker
Yes, in terms of experience, it's hard to argue that
00:48:47
Speaker
Yeah, and I have more to say about error messages if you want. This is something I've thought about a lot. I think maybe the reason why we are not working on error messages as a community is that we don't make that many errors. So who cares? It's like, fuck this thing. People need error messages when constantly they keep making errors. We don't need them.
00:49:11
Speaker
And I don't think that's fair. You program with Emacs, you write closure, you don't make errors. You don't make errors. Oh my god. Exactly. I make errors so often. It's ridiculous. Why do you think my error messages look good, right? No. Makes sense. Yeah. So when it comes down to it, in this conversation about error messages, I think it'd be helpful to be a lot more precise.
00:49:42
Speaker
about like what specifically people really want, you know, to save better error messages.
00:49:49
Speaker
It could be misinterpreted very easily, you know, like better error messages. Like, you know, when you look at it and you know what you did wrong kind of an error message, you know, like, again, that's not very precise. Like, specifically what we want is a concise message along, and this is the along with us,
00:50:12
Speaker
A pointer to the start and the end of the relevant code right like as tool writers That's what people want right like and as consumers you and now unfortunately that pointer from the beginning to the end right is is contextual right what file are you in are you working on and blah blah blah blah but
00:50:37
Speaker
Unfortunately, the capacity needs to be there to provide that information. And in many ways, ClosureScript has an edge on this because it uses ToolsReader.
00:50:50
Speaker
Closure is behind on this, and there are a lot of situations where it's very hard. And spec doesn't help, right? Like spec doesn't give you, you know, it's hard to get to like, where in the code are we talking about here? So not, or it doesn't help yet. So like, this is our specific, I think this is people's specific ask.
00:51:14
Speaker
is a concise error message with a pointer from the beginning to the end of the relevant code, if possible.
00:51:26
Speaker
And I think that this is entirely possible. I think we want error messages and this impression that the court team doesn't want to provide them. I think there are priorities. And when you're the writer of the language, you get to have them.
00:51:50
Speaker
People can write libraries, standalone libraries that go a long way to do this. And you can wrap, compile, or eval around these libraries. You can do it to an extent, and you can get a pretty good ways
00:52:08
Speaker
uh towards providing this functionality but you know there are there are definitely i think i really you know i really like somebody closer to the core team to actually try and write a library like this
00:52:22
Speaker
Just because I think going through the exercise of trying to create good error messages for closure will provide informative feedback and back pressure on the language. Instead of giving people the impression that it's not a priority or it doesn't matter.
00:52:45
Speaker
I mean, you know, it's like, you know, if that's true, that people actually think this is stupid and people ask about it stupid. Yeah, that's a problem. You know, I don't know. I don't know that that's true. I think the issue is, I mean, everything you said is right. The problem is that the reason they put spec in the core
00:53:05
Speaker
was because they wanted to have broad adoption. And you can't have it both ways. You can't say, OK, we want to have broad adoption for a spec, so we're putting it in the core. But we're not going to give error messages because we don't need broad adoption of good error messages.
00:53:20
Speaker
I think your answer is good because you've got closure 1.9. It's depending on an alpha version of spec and that's fine. Why don't we have another library that goes with spec that's called error messages spec. That's another alpha library.
00:53:36
Speaker
That doesn't have to be finished now. It's some work that got to be done. And it's just a matter of the core team putting a flag in the ground saying, this is a priority for us. And not just saying, sort it out community. I honestly think that Rich and Stu need to say that. And I'm sorry if that offends them or it upsets them, but tough shit. They really need to make this a priority for the language.
00:54:03
Speaker
They don't have to do it on day one, I get that. There are priorities, there are timescales, but they need to make it clear that all this engineering effort they're doing with spec, which is going to give us better messages in the end, we've all been promised this, that they're also caring about it and they're going to make it part of the core experience, not just this add-on experience that we have to somehow find on Google. Yeah. Yeah. Yeah. And I really agree.
00:54:31
Speaker
I really agree that it is a problem. I agree it's a problem of the experience. I agree completely. And yeah, it would have been nicer if this was addressed longer ago.
00:54:47
Speaker
you know, it really would have been nice, you know, but again, with the caveat, again, I'm walking, why am I defending cognates acting rich? I have no idea. You know, maybe just because- We're not sponsored by them, Bruce. No, no. The thing is, is I empathize. I empathize with them. You know, it's a tough problem. Well, yeah. No one's disagreeing with that, you know. Yeah, yeah.
00:55:15
Speaker
But it's a solvable problem and that's probably why it's not impossible people. This is like this is a solvable problem, you know, it's and yeah, so Again, if they yeah, I don't know I want better error messages too and I want it I want it for newcomers and I and it shouldn't like
00:55:39
Speaker
Like, messing up while you write a death and mag, you know, where you're defining a function and getting an error message that is completely nonsensical, you know, is obviously not good for the closure. It's not good for closure. Now, it doesn't bother me. I mean, I mean, it doesn't bother me. I can, you know, that doesn't even matter. You know, I'll figure it out. It doesn't, like, I don't need,
00:56:07
Speaker
error message is the way I used to need them. As the compiler moves into my head, this becomes less of an issue. But I want them. I want more people to use Clojure. And that's why I'm writing the REPL read line. Yeah. Yeah. Yeah. But before we go on to the REPL read lines, I think that is getting everyone excited.
00:56:35
Speaker
I'll ask one random question from the stream, okay? And then I want to talk about dev cards. Okay. Because, you know, see what the state of that is. I don't know where there's a, do you know Zach Orks? He's another ClojureScript. Yeah, yeah. Of course you know Zach, awesome guy. Yeah, I know Zach. I mean, I don't know him personally, Zach. Zach, I don't know you personally. Well, you're lucky then. But yeah, yeah. I've heard of Zach, for sure.
00:57:01
Speaker
Yeah. So he asks a question in the stream that says, is there a connection between exploratory interactive programming and comedy improv? So you do some of that? I don't know. It's a creative process. Is that a good answer? Is it a creative process? But no, it is. Being in the flow and responding to the moment is
00:57:29
Speaker
Being in the flow and being able to respond to the moment, it's a singular experience, whether you're building a deck, or writing a program, or doing improv on stage, or greeting somebody you've never met before.
00:57:47
Speaker
Being open to what's actually happening and then you're responding to it. So yeah, yeah and Yeah, I'm and I am super experiential when it comes to programming I mean, I just try lots of stuff, you know this idea of like being some brainchild and boom You know, you know, it doesn't work like that. I uh, you know, I I try stuff a lot of stuff. Yeah, I
00:58:12
Speaker
Yeah. Okay. It was a bit of a random question, that one. So, Deaf cards, before we go on to the latest and greatest stuff, can you give us people a little bit of a background to Deaf cards? Deaf cards is just an extension. I would say all of my projects are like, all of my projects focus on the idea of bringing this dynamic, fluid, responsive nature of closure
00:58:43
Speaker
to life, you know putting it in people's hands in a way where they can use it like Immediately and yeah in dev cards is specifically that and the way I've explained this before many many times And then here what I didn't even have to say that why I say No, no, it's that
00:59:10
Speaker
You can't have a repel. There's no such thing as a repel with a GUI. It's very hard to get interactive feedback when you're like...
00:59:23
Speaker
creating GUI components from scratch, right? Because when you're writing, we develop in the context, we're always developing in the context of a larger program where we're developing for the browser. It's always a larger context. And so that context often prevents you
00:59:43
Speaker
from trying things out, like stupid things. Like, oh, in the middle of my application, now I'm going to plop in this dumb little experiment to see this button. I can make this button turn into a smiley face, right? You're like, there's no place in my code to put this and try it out. And if I have to create a whole new project to try it out, I'm going to shoot myself, right? Because it's not fun creating a whole new project. And so Dev Cards is born out of the idea that it should be easy
01:00:13
Speaker
to create independent code examples and have them be interactive and show up as soon as you type them. So that was the idea there.
01:00:27
Speaker
So, Vijay, it's awesome. To be honest, I've played them a couple of times, but I've not really went into it in a great deal of depth. I feel a bit bad. You shouldn't feel bad. I think that's the common experience.
01:00:50
Speaker
It's it's like kind of you either really dig it or you don't and I you know, I haven't used them a lot lately myself. So There you go. I mean good companies, you know I But I think given the situation where they make sense I would use them right like I would Yeah, but to think that I'm
01:01:12
Speaker
There's obviously places for them. For a certain type of programming where you're explaining what you're doing and seeing it visually, it could probably help you drill down on a problem a lot better. But yes, again, it's another tool you have to add in and you have to learn it and use it. There's weight there.
01:01:37
Speaker
But how do you see with Figwheel and Figwheel being one of the best experiences for the developers? I mean, what do you think is the future vision for this kind of developer tooling? How do you see the programming is going to be? Of course, we keep saying exploratory programming, interactive programming. But what do you see for the future for the developer tools?
01:02:03
Speaker
We're entering into a really interesting future. You saw a dynamic land, like Brett Victor's dynamic land. The pieces of paper with the programs on them. If you're talking in visionary, I'm just going to answer in a visionary response to that question. And you add to that,
01:02:26
Speaker
like real augmented reality, like with magic leap and stuff like that. There's just a lot of, you know, you can get a lot of feedback with augmented reality. You can get, you know, you can get a lot of, you can put a lot of functionality into inanimate objects. And so will that, you know, will that mean anything in terms of building a webpage?
01:02:56
Speaker
You know, in terms of closure script tooling and blah, blah, blah, blah, blah. Let me ask it back. Do you see something coming down the line? I mean, is there something that I need to know?
01:03:11
Speaker
No, no, no, no. Obviously, I'm not that experienced or I have no fucking clue. I just follow people like you who are much more experienced in creating tools that people like me use. So I was wondering if you're thinking about Fig Wheel, for example, that came out the idea of exploratory programming and making the feedback look as tighter as possible. So how do you see this kind of thing moving forward?
01:03:38
Speaker
Well, in terms of fig will, I've had several interesting ideas. One is
01:03:47
Speaker
obviously spec, providing decent feedback. And spec is different, because these are runtime errors. So this is different than the compile time errors that you see pop up in Fig Wheel. Delving into the runtime errors is something Fig Wheel hasn't really done. And DevTools rocks. So where do you fit in here? Well, spec
01:04:12
Speaker
there might be an opportunity to create something, and it doesn't even need to be part of Fig Wheel, right? Because this could be a library that's completely separate that provides feedback for spec errors. Another thing, like for ClosureScript, is in terms of tooling, keeping statistics about errors is, I think, super interesting. Keeping statistics about errors
01:04:43
Speaker
these meta things and having them viewable as data, I think is really interesting. And I think it's also interesting for tool creators. I think it's interesting for language creators. So yeah, keeping a visual history of the messages,
01:05:07
Speaker
that are like, oh, an error. I got an error, a warning, an error, boom, boom, boom, boom. I got this error a little while ago. Being able to open up a tab and being like, oh, this is what's transpired so far in my development experience. There might be something might pop out at you. It's just more information. I told with the idea of having
01:05:38
Speaker
When you launch Fig Wheel, you have this window that's an application and you can click whichever build you want to go to and then work on that build. So, Fig Wheel slash build idea gives you this meta view of the build.
01:05:54
Speaker
and the messages you've gotten so far, and maybe a UI to let you turn on and off Fig Wheel features. So add a little more UI to Fig Wheel that way. So that's something that's occurred to me. But nothing that's blown me away. I haven't had anything that's like,
01:06:13
Speaker
This is going to rock people's world type of thing. Well, I think pretty much Big Will did, at least to most of the people's worlds. Oh, my gosh. Great. So you've been working on a read line all a lifelong day. I know.
01:06:39
Speaker
I question myself before. That's a good one. I mean, yeah, okay. It's like, what, what is it? What is this thing that he's doing? But yeah, yep. I've been working on a read line for about three weeks and yeah, it's what there's a story here. Uh, and the story was I did advent of code.
01:07:08
Speaker
And every year, I do the advent of code programming challenge. And I don't compete because I'm not going to get up at midnight. I'm not going to start working on a programming problem at midnight every night for a month. That seems like a bad lifestyle choice for somebody. You're just telling us it's the wrong time zone, basically. Yeah, like if you live in California, yeah, then you're doing it at 9 o'clock at night, which seems fine.
01:07:35
Speaker
Nah, that's not, that kind of, that's too, but the working on the programming problems themselves is an excellent way to reflect on programming, programming experience, blah, blah, blah, blah, and just have fun working on concise problems,
01:07:53
Speaker
that there's literally no downside to doing it wrong. So it reminds you to enjoy yourself while you're programming again. I really like it. And then I was so addicted to doing problems, I picked up TIS 100. I don't know if you're familiar with the assembly programming game by Zachtronics, TIS 100.
01:08:15
Speaker
It's super fun. It's assembly programming and There's all these parallel processors that you're only allowed to put 12 instructions in each in a grid and you can talk to the processors next to each other and you've got like 12 or 15 instructions in each of these blocks and you have a set of problems you need to solve and It really it's
01:08:39
Speaker
is quite fun, for some strange reason. Describing it, it sounds like the opposite of fun. But it is a surprising amount of fun. You start it and you think, I'm going to hate this. And then you're like, five problems in, and you're like, oh, if I put this over here, then I can do that.
01:09:03
Speaker
Yeah, it's great fun. I advise everybody to try it. It's like the easiest way to remember assembly programming again. And yeah, okay. So that led me to thinking about writing a game of my own that with this theme of like these programming games are fascinating to me. Like why is it fun to program? You know, I love programming. I have fun. I mean, I literally have fun programming. I write a lot of open source without, you know,
01:09:32
Speaker
a lot of remuneration and I keep, you know, I do it. I keep doing it. What is my problem? So I thought, well, you know, the REPL is kind of a game. So I had this idea, like, what if
01:09:49
Speaker
Somebody boots up a REPL and it says connecting to a remote server and then gives you some kind of heading like this one said list system 14 and like a block ASCII letters and then had a login. It has like a login.
01:10:09
Speaker
It asks for a password. So you don't know what to do, right? So you type in a password, and then it says wrong password, and then it does a core dump, and it dumps you into the REPL. And then you have to figure out what the heck is going on, right? And so you start doing dir and source. You start using these REPL commands to inspect the environment, and you find out that, oh, there's a bug in the password.
01:10:36
Speaker
Thing right and you fix the bug in the password thing and then you move into the next stage It loads like a new namespace. You have a new problem with solve and you keep doing this So this is like and it's funny because I mean, this is way too much detail But the idea is like the next module is encrypted to the answer of the previous module, right? so you could pull it down offline or blah blah blah blah blah as soon as you figure out the answer to the the previous one and so the idea with
01:11:05
Speaker
This is great, and you need a really good story to drive this. I don't have a good story yet. So I started working on this thing, and it was a tremendous amount of work. And I just noticed that the REPL experience is not game worthy, right? It's like so not game worthy. You know, it's not, like it just doesn't, it doesn't, yeah, it's not good, right? And it doesn't need to be good for experienced programmers.
01:11:33
Speaker
For experienced closure programmers, you do not need to have a good REPL experience, because you've hooked it into your editor, and Bob's your uncle. But for people who are new, people who are experienced. So anyway, I decided to write this read line. And I'm doing a quick segue because I was starting to go off on a tangent. So I started to write this read line, and it
01:12:03
Speaker
It really made me reflect more on the idea that we experience closure so differently than people are coming to the language in the beginning. We experience it so differently. Now, this is a different thing about closure. A lot of other languages, the compile
01:12:31
Speaker
Right run feedback loop is the default so people can come to closure
01:12:38
Speaker
and do a right-run feedback loop. They can use Closure Main or rerun a script with Closure Main over and over again, and pretty much assume, oh, they got it. It's a programming language that has these features, blah, blah, blah. They're missing what I would say at least 50% of the story, if not 70% of the story, which is the experience of writing Closure.
01:13:05
Speaker
and the fluidity of the feedback. So let's put it into the read line. Let's put our experience as experienced closure developers. If we put it into the first thing that these people experience,
01:13:23
Speaker
It gives them time to acclimatize to this idea of inline eval, which kind of sounds stupid to put in a REPL, inline eval, but then once you start doing it, it starts making sense. So if we put this experience of inline eval, which is extremely foreign to other people,
01:13:43
Speaker
to other programmers coming from other programming languages, you can show it to them, you can describe it to them, and they still don't get what inline eval is. Like you have to experience it and make it part of your problem solving, and then you're like, ah, parentheses make sense. You know, you start to really, really get it. So yeah, that's the idea behind this readline library is to make
01:14:10
Speaker
the fluidity of our programming experience available to newcomers and so they can annihilate foreclosure problems, right? They've got this really nice editing interface in the ripple and they're doing foreclosure. They've got a great way to work and they have, you know, they can learn more about what it's like to work with a closure program, a list programming language and
01:14:38
Speaker
I had another point. Oh, the other thing is right. It's impossible to choose tooling if you're new to closure. Yeah, it is basically impossible. Everybody says emacs cursive
01:14:52
Speaker
So blah, you know, yeah, I use VS code. And then what, oh, they don't have experience, like a lot of programming, like a lot of programs from other programming, we just do not have an experience of an integrated REPL, right? So they don't know how to choose tools that optimize this. Well, if we provide that in our REPL immediately, they will get this immediate experience of
01:15:20
Speaker
Oh, these are the features I want from my editor, right? I want to have access to online documentation. I want to have, you know, access to, you know, source code. I want to have, you know, I want to have inline avail. I want to have a Propos. Is that how you pronounce that? How do you, a Propos? Probably. I have no idea. Who cares? But we know what you mean. Apropos. Apropos. Yeah. Apropos.
01:15:50
Speaker
I don't know. Yeah, anyway. So yeah, that's the idea. If I preach so long enough about that, like who's going to disagree with me at this point? No, no, no. I think honestly, the funny thing is that this is one of the things that I say a lot as well is because actually,
01:16:07
Speaker
I came from a Java background in a sea and all these kind of compiled environments didn't have the experience at the beginning of this REPL. And it probably took me really, I'd say even a year to fully grok that the REPL was the thing. And I really get it now. I do everything in the REPL now.
01:16:33
Speaker
Putting things into files is kind of annoying, you know? It's just something I've got to do to ship code, you know? Doing the dishes, washing, everything. What was that, Vijay? No, as I say, he's doing everything in Endeppel now. So, you know, doing washing and dishes and stuff. Practically everything is in Endeppel now.
01:16:54
Speaker
Well, actually, the funny thing is, that's kind of true, because it comes back to what you were saying about being experiential. It's because when you're doing your real life thing, you're getting feedback all the time. And actually, so I bring in the washing machine, if you like, to the
01:17:10
Speaker
into the programming environment because everything is just live. I find it really nice when people like you and Zach and other people are really working like Mike Fikes and all these guys are working on the repls and making them better, this proto-repl stuff. All the repl stuff is really exciting because I think that's the superpower of Clojure.
01:17:32
Speaker
I really do, you know, I think that's, if we're looking for like, what's the game changer? It's not machine learning. You know, it's not all this other bullshit because every language can do that, but they haven't got a repel. And if they have got one, it's shit. You know, so this is, this is like, why, why aren't we selling this as hard and as, you know, hard as deep as possible? So I love it. I love, I think you're doing a great job there.
01:17:56
Speaker
Oh, thank you. Thank you. It was a surprise that I didn't know that I, you know, I certainly didn't know I was going to work on this, but I got lucky. I got lucky here too. J-Line 3, you know, this tireless programmer has been working on this.
01:18:15
Speaker
And yeah, it's pretty darn capable, and it handles all the hard stuff of doing terminal read line, which is, there's a whole layer there that you don't ever want to have to get into, so yeah.
01:18:29
Speaker
Great. OK. So I mean, that's one of the things to me is, like, in far as the repl is concerned, like, where do you think that whole live experience is going to go? I mean, you're doing this read line stuff. What are your plans for it beyond the already awesome stuff you've got here? Where are you going with it? I mean, so that's a good question. There are a couple of things that occur to me, right?
01:19:00
Speaker
First of all, there's a lot of features. You could put a lot of features into, it's practically an editor, right? It looks a lot like Emacs once you start programming it. You're like, oh, this looks very, oh, yes, very familiar with this. I'm got a buffer, I'm changing things in the buffer, I'm setting it back into, you know, it's very, I'm syntax highlighting, I mean, all of this is very familiar.
01:19:32
Speaker
I mean, in terms of making the experience better, I think that what I have is already pretty nice compared to all the repls I've seen. I've looked at IPython. I tried to get a look at what people were doing. I looked at reasons.
01:19:54
Speaker
And this is pretty nice. And most of it is because Closure does this already. I'm just kind of lifting it up so people can see it more quickly.
01:20:08
Speaker
It'd be, further features for this particular thing would be inline read errors, like read exceptions. Like, oh, this is a bad token, underline it. All right, that would be very, very nice. Again, kind of common, common experience. But yeah, bringing more things like that, I would love to have the, I love,
01:20:32
Speaker
Like this is just a real line library, so it doesn't really have anything to do with the output. But I would love to have pair this with libraries that do handle output, that handle error messages and stuff like that. I think that all together you could create like an amazing repl experience with colored output and blah, blah, blah, blah.
01:20:55
Speaker
And reformatting the last line with a pointer to where the error is would be fantastic. Aside from that,
01:21:07
Speaker
This terminal library is very interesting, and I think you could easily write a library that would let people experiment with writing terminal games. You could easily write a library with a nice programming, because basically you're taking in data, you're returning a string. So you could write a nice functional library,
01:21:31
Speaker
that composes widgets or that composes objects the way you would in a game library that has an update. Maybe it calls update and then you draw a new screen kind of a thing. You could do this very very quickly and give access to kids and other programmers like
01:21:58
Speaker
Another domain in which to explore programming, which is very safe, like it's just the REPL. I don't have to learn all of HTML, HTTP, but, you know, I don't have to learn this whole model. Now I just have this program running on this computer and I can write a graphical-ish program using characters, which is very, very, very comprehensible for people. So give another domain for people to explore and have fun with. Yeah. Okay. Excellent. Yeah.
01:22:25
Speaker
Because I was thinking also the thing that these repels could do is contribute towards this literary programming or that kind of, which we say, the notebook thing that's becoming popular with machine learning people or big data people. This concept of integrating these repels into a broader kind of environment.
01:22:56
Speaker
Yeah, yeah, yeah. I think that's, of course, I find that super interesting. Very, very interesting. And I haven't, you know, I've been so down in the technicals, I haven't like stepped back for a more visionary look at it, but you're right.
01:23:14
Speaker
This particular library, it's just for... Yeah, yeah. It's not a new REPL. It's only read-line. So again, in terms of vision around REPLs, I don't know if you've ever used IPython Notebook or Gorilla REPL or anything, but you feel... I've used Gorilla when you call it a REPL and stuff like that. Yeah.
01:23:38
Speaker
Yeah, yeah. I still feel really confined in that. Like, for some reason, not being in a file... See, not being in a file...
01:23:50
Speaker
I find really constricting in terms of expression. Not being in a file in an editor that is like Emacs or something like that, I find difficult to edit in. Now, these things are getting much, much better like in the browser and blah, blah, blah. So that experience could change and it could just be. What do you mean not being in a file, Bruce? I'm kind of confused by that. What do you mean by not being in a file?
01:24:18
Speaker
Well, Python Notebook, you're actually in this interface when you're editing code, right? You're in the browser.
01:24:27
Speaker
and when you're editing code, right? Unless I've got this wrong. When you use IPython Notebook, you're in a browser, you're in a web app, and you're typing in code. So coding in that environment, I find, personally, by instructing. Yeah, okay, I'm with you, yeah. Sorry, no, I mistook you. I thought it was just a round, because I was getting, I think that would be very constraining as well, yeah. Yeah, yeah, I find it very, very constraining.
01:24:55
Speaker
And that's what's different about dev cards. Like if you ever get a chance to use it, I find dev cards to be an interesting direction for proto REPL and these, let's just say graphical REPLs for better.
01:25:11
Speaker
You know, the graphical literate REPLs. I find dev cards is kind of my answer to like an interesting take on that because you can use dev cards as a graphical interactive REPL. But the thing is you're typing in a file.
01:25:28
Speaker
and you're getting the graphical feedback in the browser immediately. So you get to actually operate in a file and do whatever you want, and then the feedback and the graphs and the whatever you want is coming in in the browser. And that, I think that's a much more interesting, let me put it another way. I think you have opportunity for more expression and more exploration that way.
01:25:56
Speaker
The other question I've got for you, and it's something that maybe I'm not saying all of this thing is your responsibility, by the way.
01:26:03
Speaker
I'm not saying you want something. Oh my God. And we're just talking about ideas, you know? So it's one of the things that I was doing something with a friend of mine recently where we were trying to experiment with like shared and there's been some projects with it to have like two or three or four people on the same file editing things together and collaborating.
01:26:27
Speaker
And there was a guy who was on this show actually, I guess, did this crepel, which is this collaborative repel. But he's kind of run out of steam and money and time, so bit of a shame, but there we are.
01:26:43
Speaker
But this whole notion of having a REPL that you can log into, and then you can share it. I was getting excited by this Atom thing. They have this thing called Teletype where you can essentially log into the same, but it's logging into the same text file. It's like a Google Doc or something. Now, Atom does have a REPL, so in theory,
01:27:06
Speaker
But you can't see it. You can't share it. So it's fucking annoying, basically. Excuse me. So I don't want to edit the file. The file is bullshit. I want to put my code in the REPL and evaluate things. And that doesn't exist. And that's sort of annoying to me. So can you do that? No. But what do you think about the idea? I mean, I'm not saying, like I say, you're not on the hook for it. Is that something that is interesting to you?
01:27:37
Speaker
Yeah, I find that really interesting. And it's a tough one. Yeah, like if I was going to explore this problem, it's a tough one because you're buying into something. And it's tough to create something that transcends it all. Like I recently used
01:28:02
Speaker
like a Tmux sharing app that lets you share, you know, your your terminal screen. Yeah. You know, even if you're behind four levels of NAT and whatever, you know, like you could still you could still do it. And that was, you know, that was interesting. There was an N REPL middleware. You can do it. No, actually, I've tried this and that does work.
01:28:29
Speaker
Yeah, that works. You can have multiple people typing into the REPL via tmux. Yeah, that works. OK. Yeah, but I think there's also N REPL middleware that was created to do this. I have never used it. And because when you think about it, you're just multiplexing messages at that point with N REPL middleware. But I'm not so sure.
01:28:58
Speaker
Yeah, there would need to be. The problem with Team Hooks is that you're just typing a REPL, so anybody can do anything. There's no differentiation. You can't see Ray's doing this and John is doing that. Oh, yeah. I see what you're saying.
01:29:17
Speaker
Gotcha, gotcha, gotcha, gotcha. Whereas that's a nice thing about the Google Docs or the Cripple was because it's using the CRDT model, then you could see what the source of the input was and you could see what the timeline was and how it was evolved. Anyway, it was really nice. Yeah, yeah, yeah, yeah. And it sounds really nice. It sounds really nice. I'm just a loner though, man. I'm just a loner.
01:29:47
Speaker
Obviously, you don't need multiple people typing into REPL because one programmer is enough for closure. It's like we don't need error messages. We don't need multiple people in the team. It's just bullshit. You just sit one programmer opening CLJ with the Jline tool that Bruce has built and then Fig Wheel and you're done. That's it. Why the fuck do you need like 17 people typing into REPL anyway? It doesn't make any sense. You don't need it.
01:30:13
Speaker
You don't need anything, DJ. I told you, obviously, you know. I'm a dreamer. I should do it myself. I should shut up and just do it myself. All right. Listen, so when there's a read line coming out then, Bruce, what's the plan for that? Because, you know, you're teasing us all with this video. So when are you going to put it out there? Yeah, yeah, yeah.
01:30:35
Speaker
Scoop for deaf and you know i don't know yeah please give it to us. I am in the process of moving it from a exploration into something that people can use.
01:30:51
Speaker
And I don't know how that is. There's a point where the edge of your feature, you try to cut your feature list and you're like, boom. But unfortunately,
01:31:09
Speaker
Rounding all those off, the surface area is always a little bigger than you
Importance of Feedback and Real-World Challenges
01:31:14
Speaker
expect. As you're cleaning it up and rounding it out, you're like, the surface area is a bit bigger than I expected. So I would like to have something people can give me feedback on. Not something that's going to work, but something that people can give me feedback on.
01:31:30
Speaker
in a couple weeks. Okay. Couple. You know, that's, I'd really, I'd really like to do that because, you know, it might not work. Like it works in a high term, you know, it works great. Like, you know, once it gets out in the world, if it doesn't, if it just falls flat on its face, you know, I, it'd be nice to know earlier. If you're looking for some beta tells, just let me know. Okay. All right.
01:31:56
Speaker
OK, so I think we are almost one hour 40 minutes now. Oh, man. Yeah, OK. Yeah. Wow. I think there are still people who are still watching us.
JavaScript Evolution and Preferences
01:32:08
Speaker
That's pretty nice. Yeah. So I think we covered most of the questions that we got, except for only one question that's like, what do you think about JavaScript itself compared to other things? Closure scripts.
01:32:27
Speaker
You know, I worked in JavaScript for a long time and
01:32:34
Speaker
And this is before, this is a much earlier time, a different age. And I enjoyed the experience because it was dynamic and you got feedback pretty quickly, comparatively quickly. Really, like this is before you compiled your JavaScript. You just reload the browser and you see the new behavior and it was guaranteed that you would see new behavior. You know, like there was no complexity between.
01:33:04
Speaker
That's a good old job. I think yeah, I think but that you know It's just too easy to say, you know, JavaScript has problems and blah blah blah blah blah I was really fascinated to hear that Python outstripped JavaScript in terms of popularity. I Don't know what numbers back that up. I you know, it didn't make any sense to me, but that was that was a weird. Yeah But yeah, the JavaScript language is
01:33:34
Speaker
It's fine. If I had to use it, I would use it and not complain that much. I would complain about the schooling all day, but the language.
01:33:47
Speaker
If I had a choice, I would choose CoffeeScript. I would definitely want to blunt the edge a little bit, but the new JavaScript syntax is nice. They've got nice features, but there's still lots of little things waiting there for you.
01:34:09
Speaker
Cool. OK. So I think we covered most of the questions that people asked. And if the people who have joined on the live stream, if you have any questions, then this is you have like three seconds to type the questions. Otherwise, we're going to close the show for now. And thanks a lot for joining.
Community Support for Fig Wheel
01:34:30
Speaker
And Bruce, again, Figuille is one of the greatest tools available right now.
01:34:37
Speaker
We are so thankful for making this tool and then releasing it for free. I don't know how you're getting paid by all this stuff, but giving it away for free is amazing. Oh, you know what? I have to announce something else. Yes, please. Well, actually, I do get paid every time. You guys heard of closures together, right? Yes.
01:35:03
Speaker
Yeah, I got that to work on Fig Wheel. It's like $5,400. And yeah, it is some money. And I hope I got that number, right? So just $54.
01:35:24
Speaker
That was actually cents. That was just cents. Well, that's great. $54. That pays for like 30 hours of my time, so that's great. No, kidding. Please don't take this. No, no, no, no. So yeah, so I got that, and I'm super-sick about that. I think Daniel Compton's done a great job with that. Yes, yes.
Supporting Open-Source Sustainability
01:35:44
Speaker
And yeah so it's fantastic I mean of course I mean this is something that we want to tell other people as well as much as possible Daniel was there on the show as well talking about closures together because this is this one of the things that that community needs right at the end of the day I mean people need to pay people need to work on things and you can't just keep shitting out code without you know getting food.
01:36:08
Speaker
Wow, that's a nice metaphor. OK. How did you know where my coat got? Exactly. That was just a private thing. Some people have having time, other people have other times. Other times, too.
01:36:24
Speaker
No, but all the joking aside, I mean, things like Clojus together, I mean, they help sustaining the community for a longer amount of time. Because people need to pay the bills, and they need to work on these tools. And these tools are not, they're extremely high quality, things like Fig Wheel, things like Dove Cards. And even the ASCII thing that you're building right now, we thought, all right, this is just mind-blowing stuff. And I can imagine the amount of time that you're putting to make these things shine like this. So we are very, very grateful for that.
01:36:53
Speaker
And of course, just being grateful is not enough to pay the bills. This is why people need to contribute to things like closures together. So people who are listening to this thing, if you're using any of these tools, go to closures together. Join as a member. Ask your company to join as a member if you're using closure. That'll be amazing.
01:37:15
Speaker
Anyway, so Bruce. And I think that is true. And direct contributions work as well.
01:37:29
Speaker
as well. So it really does. It helps direct contributions. And you think, oh, why would you need to ask for that? It helps me monetarily, and it helps me know that people actually care about the tools instead of just through word of mouth.
Gratitude for Community Contributions
01:37:52
Speaker
So I don't get a lot in there, but when I do, it makes me feel good.
01:37:58
Speaker
It makes me feel like people appreciate it. And yeah, so it's another way. But do not take money away from closures together to give to me. I would say that I want closures together to succeed and be well supported. And every now and then, think of me. That's all I'm saying. I hate to end on asking for money because this is not where I wanted to go. No, no, no, no. It's not where I wanted to go.
01:38:29
Speaker
I wouldn't see that like that. People cannot shy away from this stuff. People can keep taking things for free. It's not a problem. Free is not free as in it's about the freedom that people are getting.
Encouraging Contributions to Clojurists Together
01:38:42
Speaker
They can fix the code, they can look at the code, they can do whatever they want.
01:38:51
Speaker
asking for, it's not asking for money, it's people showing appreciation, people showing their support. So that is something, you know, that we appreciate a lot as well. And when we open Patreon, we're like, oh my God, you know, people are
01:39:07
Speaker
Actually giving us dollars or like, okay, this is too much. This is too much. This is just random shit that we are speaking out into the microphones and people are putting their hard-earned money. So anyway. But yeah, Closest Together is something that I think should become a bigger organization and helping much more libraries for long-term sustainability of the language. I agree with you completely on that one.
01:39:32
Speaker
Okay. Okay. Zach says, Bruce, you rock. And Zach Oaks, he says, I rock. And he also said that we should make tote bags with the Fig Wheel logo on them and sell them. Merchandise, Bruce. That's what it's all about. Take a pass on that one. I should have started merchandising a long time ago. I don't know what I was thinking.
Humor in Open-Source Monetization
01:39:57
Speaker
Because you know, I mean today you just put your junk on Amazon fulfillment and let it let it fly. So yeah. Oh my God. You're right. I want to end. I'm begging for money and I'm putting my junk out on the internet.
01:40:24
Speaker
Gosh, I wanted to end on a positive note and it's we're all obviously too tired. Yeah. Yeah. Yeah. Come on. I mean, Bruce, I mean, did you hear did you hear any did you listen to any of the episodes from death and before?
01:40:38
Speaker
You know this is bullshit. You know how things end indefinitely anyway. You should have known before you come on to the show, you're like, this is going to be a disaster. Yeah, that's true. This is going to be horrible. No, it's great. In fact, I really enjoyed every minute of it. This is fun. Thanks for asking me. Thanks a lot for joining and thanks a lot for all the work.
Success and Challenges of Live Streaming
01:41:03
Speaker
And for the people who are watching, thanks a lot for bearing with us during our technical difficulties and everything. We hope you enjoyed the show. And I think we'll try to continue doing this live streaming thing a bit and then see how it works. It seems to have worked a lot better this week. I mean, we've got more people chatting. I think, you know, if people do put type into live chat, that's the words. The words have to come out.
01:41:33
Speaker
Yeah, people type in the live chat and get a bit of an interaction going, then it's really lovely, you know, and it's been really good. Thank you guys for who's been on the live stream. I really appreciate it. And all the people on Twitter and these other people and Slack, all the questions that have came in for you, Bruce, you know, it's easy when you're here because everyone's loving you. So, you know, we like basking the reflected glory of the Howman. So that's good for us.
01:41:59
Speaker
Exactly. Oh my god. Which might have been not a good note, but okay. Well, let's do it again sometime for sure. You know, let's do it again sometime and... Exactly. I'd love to talk to you guys again. Perfect. Next year or something, that'd be great. Definitely. Well, you're always producing stuff, you know, never-ending font of new code, so it'll be great. So, goodbye everyone, and then I think you can listen to this on podcast pretty soon. Thank you.
01:42:59
Speaker
Can you stop the recorder? I don't know what I'm doing.