Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
#51 - Sean Corfield a.k.a @seancorfield
69 Plays6 years ago
We meet the king of JDBC and discover his many other areas of expertise.
A gentle and warm conversation with a delightful gent.
Enjoy his many repos and links to his other work
https://github.com/seancorfield
Recommended
Transcript
Introductions and Expat Experiences
00:00:15
Speaker
Welcome to Deaf in episode number 51. And today, as usual, this is Vijay from Holland. Red from Belgium. And we have our special guest, Sean, from the US of America. Yes, I'm from the Bay Area, California at the moment. Welcome to the episode, Sean. But you sound about as American as I sound Belgian. Yeah, I'm a transplant.
00:00:45
Speaker
Yeah, we're all transplants. In fact, all three of us are transplants, aren't we? Yeah.
Exploring San Francisco's Geography
00:00:51
Speaker
Yeah. Because, well, yeah, technically I crossed some oceans, but yeah, so from India to here. Yeah. If Iranian airspace is clear, then it is faster, but otherwise you need to go. I need to go over water to get the channel. Yeah, exactly. I went in the tunnel, but shut up. Okay. I went under water.
00:01:12
Speaker
And Sean, you were originally from the UK. Yeah, I was born and raised in Northern Ireland and my family moved back to the mainland in 69 and then I moved over here in 99.
00:01:23
Speaker
So I've been here 20 years. Right. So which, which place are you based in the US now? I'm in the San Francisco Bay area. Um, you know, the high tech Silicon Valley center, but I'm actually on the East side of the Bay. So I'm in a lovely little suburban community and I can stay away from the craziness that is Silicon Valley.
00:01:47
Speaker
OK, it's a beautiful part of the world, isn't it? It really is. Oh, yeah. I mean, you know, today, today it's going to be in the 80s. It's it's been really nice here. We get rain just through the winter and then through the summer, it's all just dry and warm.
00:02:06
Speaker
which of course is why we have so many wildfires. That's the bad part. Yeah, that's the downside. But we don't get tornadoes, we don't get hurricanes, and we don't get flooding. So I'll take it. One out of five. Well, you're kind of on a San Andreas fault, aren't you? I know my friends of mine who live out there,
00:02:29
Speaker
They had to have special accommodations and houses, special underpinnings and earthquake proofing. Is that something you have to do as well? Yeah. Where I live, I'm right on top of the Hayward Fault. Right. OK. It's the nature of fault lines in California that that's where they tended to build the roads because that was the best place to put roads. And I'm literally just a couple of miles off one of the main interstate freeways here.
00:02:58
Speaker
So we do get earthquakes from time to time. To be honest, if it's a four or less, you just ignore it. Even if it's a five, it's kind of like, well, if it was right under your house, things would fall off shelves and break.
00:03:14
Speaker
But yeah, it does mean you have to have, you know, everything that's up on a shelf has museum putty to hold it in place. The big bookshelf here in the office is actually strapped to the wall so it can't fall down. You do have to think about these things because there's no warning. I mean, you just suddenly everything shakes and then you just pick up the pieces and go back to normal life. Well, let's hope for the duration of this podcast. We don't need too many wobbles.
00:03:43
Speaker
So, Sean, obviously you've been in the industry for many, many, many years.
Sean's Programming Journey Begins
00:03:50
Speaker
Decades. Decades. Decades. Yes, exactly. We joined the veteran crew on Dafn. Can you give us like a whirlwind tour of your experience? Yeah, sure.
00:04:03
Speaker
When I was back in university in England, I kind of got interested in programming languages. My final year project, I actually wrote an APL interpreter. And then I stayed on and did PhD research into functional programming. So I was looking at implementation and design of functional programming languages.
00:04:23
Speaker
And it was a time in England when pretty much every university was designing its own programming language. And so when I went out into the world, because of those connections, I ended up working for a tiny little compiler company in England. And we actually built one of the world's first ANSI-validated C compiler systems. What was the company, by the way? It was called Knowledge Software.
00:04:47
Speaker
Oh, okay. And pretty much no one's heard of them because they're really tiny. Because I remember the instruction set and they had a compiler as well. Yeah, I mean, it was kind of an interesting time. I mean, you know, Microfocus, we worked with them a fair bit. They had their COBOL compiler. When we got our C compiler verified, it was the same day, I believe, as Inmos.
00:05:12
Speaker
and I think maybe ball and we were like the first three to get the certification. And so I went from there to working on C++. I got involved with the C++ standards work and was on the committee there for eight years. And then I discovered Java. And back then I was still very skeptical.
From England to the US: Sean's Career Shift
00:05:33
Speaker
Java was brand new.
00:05:34
Speaker
and no one really knew if it would stick around. But that got me onto Java and that got me into Macromedia, which was just after I moved to America. And funnily enough, what happened then was Macromedia bought a lair who had cold fusion. And so suddenly Macromedia, which was this Java and C++ shop,
00:05:58
Speaker
We're confronted with this ColdFusion product, and because it was our own product now, Dog Fooding said, yep, you're going to build web stuff with ColdFusion. So while we still did C++ and Java, a lot of our customer-facing work was ColdFusion. And then Adobe bought Macromedia, and I lasted about a year there before getting a little frustrated with Adobe.
00:06:24
Speaker
And went off and was freelance for a while, worked for a startup, doing a mixture of different languages, but at the time primarily ColdFusion. And I then ended up working at another sort of startup-like company, and they were a ColdFusion shop, but open to other tech.
00:06:45
Speaker
And they had a particular problem process that they had tried to build various ways that just needed to run 24-7 and scavenge the database for updates and put information in search engines and send emails.
Introducing Clojure to ColdFusion Shops
00:07:01
Speaker
And ColdFusion isn't particularly good for anything that's a continuous process because it's really designed for request response web stuff.
00:07:09
Speaker
Yeah, for the people who are, I think, younger generation, maybe you can explain what Coldfusion is. So it's like pre-JSP, pre-PHP days. Yeah, it's true. Coldfusion got its start in the mid-90s, and it was created as a way to help people build websites with dynamic content. So in the early days, you literally had an HTML page
00:07:33
Speaker
And you wrote in, and I believe in the early days, tags that began with DB. And so you could read database content into a webpage. And then they changed it to be called Cold Fusion and changed the tags to be CF. And by the time I encountered it in, let me see, 2000, 2001, I guess.
00:07:56
Speaker
A layer had started an initiative to rewrite it completely from scratch as a JVM language. And so the first cold fusion I ever used had some OO extensions in it. It was essentially a dynamic scripting language for the JVM that compiled on demand to JVM bytecode.
00:08:16
Speaker
And so, you know, it's dynamic. You can do metaprogramming. It now has a very nice JavaScript-like scripting syntax as well as the old template syntax. There are open source implementations.
00:08:33
Speaker
For the last 10 years, whenever I've done any cold fusion, I've used Lucy, which is a European based group that has an open source project that is a full open source, uh, implementation of the cold fusion language. Um, and so while I was working with that at the new company,
00:08:54
Speaker
looking at this problem process, one of the things I thought I'd try out would be Scala. So learn some Scala, built it in Scala. And it kind of worked. You know, it was new to us. Didn't kind of really sit well with some of the other team members because ColdFusion you edit, you reload your browser,
00:09:13
Speaker
And it's compiled and run. Scala, of course, you know, compile for ages, deploy, restart your system. Back then it was before play and things like that. And so I had seen some chatter about Clojure.
00:09:31
Speaker
And back in early 2010, Amit Rathore, who wrote Closure in Action, he had a startup in Silicon Valley and advertised that he was doing a workshop to learn Closure on a Saturday morning for, it was like 200 bucks. And I thought, you know, yeah, 200 bucks of my money, I could go do that. And I thought it was fantastic. I was instantly hooked.
00:10:00
Speaker
And over the next year, I looked at whether or not we could use it at work and rewrote the Scala processing closure as a test.
00:10:10
Speaker
And we went into production with Closure in spring 2011 on 1.3 alpha 7 or alpha 8, I think. That is pretty idly an option. Yeah. And so we've been using Closure in production since then. The company I work for is an online dating company.
00:10:32
Speaker
And so we have dozens and dozens of websites that all are targeted at what we call ethnic verticals. So we have ArabLounge.com, EligibleGreeks.com, Desicis.com, LatinRomantico, and a whole bunch of other sites around that sort of thing. And from having introduced a bit of closure into that Cold Fusion shop back in 2011,
00:10:59
Speaker
We've gone to essentially all closure on the backend over time and gradually retired the various bits of cold fusion code. We still have one fairly sizable app written in it, but it's mostly the sort of the view controller layer and then all of the model is written in closure.
00:11:21
Speaker
And in terms of the database, data storage, what type of technology use this? We've used a bunch of stuff. Right now we're using Redis for sort of transient stuff and MySQL. We were using MongoDB for a while. I was very enamored with MongoDB.
00:11:37
Speaker
for a while. And we just found that trying to maintain a production scale MongoDB cluster as well as a production scale MySQL cluster was expensive and frustrating. And in the end, we actually migrated everything into MySQL and stopped using MongoDB.
Functional vs. Object-Oriented Programming
00:11:58
Speaker
Yeah. So you've been, so you tried something in Scala and then you felt closure was more attractive. So what was the difference? What was the difference or what did you find? Well, one of the things was, as I said, it was a cold fusion shop. So the team were used to editing code, reloading in the browser and it was just up and running there. So Scala really didn't fit that.
00:12:25
Speaker
But Closure did because you've got the REPL, you can work dynamically with the code. If you're building web apps, you have the Watchers. As soon as you save a file, it reloads the code. You just reload in the browser. So it actually fitted a lot better with what the team culture was. And everyone seemed to think it was really fun and interesting to learn this new Lisp language. So folks were pretty enthusiastic about it because it was new.
00:12:55
Speaker
What did ColdFusion look like, by the way, because I can't really remember coding it. I think I've done some tag stuff a long time ago, obviously, but did it look a little bit like C or JavaScript or something, or was it more kind of 4GLE?
00:13:11
Speaker
It's evolved a lot over the years, and most people's experience with it still dates back to the early days when it was a proprietary system and it was all tag-based. But since the early 2000s, it developed a pretty solid scripting language that has evolved over time.
00:13:30
Speaker
And so if you looked at modern cold fusion now, you still have the tags for use in the HTML templates, but pretty much everything else is going to be written in a language that looks an awful lot like JavaScript. You know, it's got full object oriented capabilities, although it calls them components instead of classes.
00:13:49
Speaker
It's got metaprogramming support, so you can modify components at runtime. You can do stuff like the on missing method that other languages have.
00:14:06
Speaker
It's really quite a nice language these days. It's unfair that it's taken so long to evolve to that point. A lot of people have just said, it's a proprietary, weird, tag-based system, not interested. There's an open source implementation, as I said.
00:14:24
Speaker
For people coming in who want a free, fast, get up and running quickly system, it's kind of nice. So it's in the same sort of space as PHP really, but obviously PHP is so big now. Yes. Yeah. And I mean, it's very much niche and I mean, we're used to closure being a niche language, but CFML is super, super niche.
00:14:49
Speaker
And integrating Clojure and CFML is the ultimate niche-ness, I guess, is what you're doing. I guess it is. I mean, it was one of those things where I wanted to be able to use Clojure as a library language so that we could rewrite certain pieces of the system in that. And so I created a bridge from cold fusion to Clojure.
00:15:10
Speaker
and made it possible to dynamically load Closure through the old Closure Lang RT system at the time. And so gradually we were able to rewrite the system from the bottom up in Closure. And I've kept up with that, so we changed over to the Closure Java API when that appeared.
00:15:36
Speaker
which was 1.6, I believe. And so that's how we do the integration. We declare a set of namespaces we're going to use, and the cold fusion code bootstraps that and pulls in all of those namespaces with require.
00:15:54
Speaker
and sets up at runtime a what looks like a nested structure with functions in, which is the namespaces enclosure. And so apart from having the parentheses in a slightly strange space for us, it looks like you're running closure code.
00:16:13
Speaker
But how did the, because you started with functional programming and programming languages research, right? Long time ago. And then you switched to C++, which is object oriented in one sense, and then Java and then ColdFusion. So how do you see the functional programming thing in enclosure now compared to when you started?
00:16:42
Speaker
Yeah, it's kind of interesting because I moved into the OO world because that's what you needed to do to get a job. I'll be completely honest, if I'd have had the choice, I would have stayed with functional programming. And I must admit, when Haskell appeared in 91-ish
00:17:00
Speaker
It was drawn from a lot of the university languages that were being created. And I was very excited about Haskell. I was like, great. Finally, functional programming is going to take over the world. We've got this robust state of the art language. And of course that didn't happen. And so I was like, well, I'll go learn C++ and work on that.
00:17:27
Speaker
I never thought we'd get functional programming back, to be honest, in the mainstream. So when I started to see functional programming becoming more of a buzz and seeing more adoption of the ideas from functional programming, it was really, really nice to come back home to that idiom.
00:17:46
Speaker
I guess you were kind of like brought up if you're kind of like looking back at those university things to say there have been various people doing history of Haskell and history of FP in the UK and the US and everything. And obviously a lot of those systems draw their influence and there are kind of like heritage from lisps but
00:18:05
Speaker
They're adding types and other kind of affordances to make life simpler, easier. That's always like a tricky concept, but they wanted to make it more powerful in some ways. They wanted to make it more mathematical to prove more stuff, essentially.
00:18:21
Speaker
about what the characteristics of the system is. So what was your kind of research and how do you feel about that now in terms of like that? I know it's always like the bullshit question, you know, but come on, let's just take it on. Yeah, we've got time. It's Sunday afternoon. My focus, I mean, my focus when I was doing research was very much on looking at programming language design. What were good features to have in a programming language? What made things more expressive?
00:18:49
Speaker
And so I built a, initially what I did actually was I built a Lisp system using Peter Henderson's Lisp kit implementation. And so I had a small core Lisp interpreter, and then I built language features on top with a parser that took ML style languages and compiled them down to Lisp and then ran the Lisp on the Lisp kit system.
00:19:16
Speaker
And one of the things that allowed me to do was to actually experiment with language features in Lisp. And if they worked out, I would then rewrite them in the core language of the parser system that I'd built.
00:19:34
Speaker
It's sort of, it's interesting to see that the functional programming kind of went two ways. We have the ML family, which culminated in Haskell and various things we've had since then with F-sharp and OCaml and so on. And the Lisp side of things
00:19:51
Speaker
sort of died out. And I think the gut reaction people have to parentheses seems so visceral that a lot of people can't get past that, which has always surprised me because there's so little difference between C-style script languages and Lisp. For most code, you just move the parentheses. That's all you have to do.
00:20:18
Speaker
But would you would you say that this this opinion of yours is because you have been scarred by APL before? Actually, that's true. Yes, of course. My final project at university was to build an APL interpreter.
00:20:35
Speaker
You know, I liked APL. I thought APL was pretty impressive. I mean, I tried it like one day or half a day or something using Emacs. I'm like, what the fuck is this? Like all these weird symbols and shit. Yeah. I done a sandwich placement year when I was at university at a sandwich placement with an insurance company and discovered that they had a few people using APL there.
00:20:59
Speaker
Wow. And I was blown away that this really compact language and one example that I used to give to people was I think it was like a 13 character expression that could find a substring in another string.
00:21:17
Speaker
And if you changed one character, it would count how many times the substring appeared. And if you changed a different character, it would tell you what the index of the substring was rather than just yes or no. And that compactness and expressiveness just blew me away. And so that's why when I went back to university after my placement year, I was like, I want to write an APL interpreter because it's a cool language. I mean, it gives a new meaning to write only programming in that, doesn't it?
00:21:48
Speaker
Yeah, it's kind of a little unfair. But yes, if you are not familiar with APL, you look at it and it looks like a grab bag of math symbols and Greek letters. I think it looks like Egyptian hieroglyphics or something. That's how it looked like. The weird thing that people were not able to decrypt so far. The Rosetta Stone. Oh, no. OK.
00:22:14
Speaker
No, no, some manuscript. Anyway, I'm sorry. I understand you're sorry for the digression into APL because I remembered my Emacs mode and I was getting confused by all this crap.
00:22:29
Speaker
I think the parentheses thing, I think when people look at the opening parentheses, I don't think there's such a difference. I think it's what I hear and the people I speak to that don't program less, but see it for the first time. It's like, whoa, how come there's like 20 parentheses at the end of that expression or 10 off? You don't notice it, but oh shit, yeah, there is, yeah.
00:22:56
Speaker
Especially with web applications and React and reframe and stuff like that, you certainly have this big bundle of 10 or 15 parens at the end of your expression, which is, it doesn't matter. But some people feel like it. It's the same in JavaScript, right? If you have callbacks, JavaScript will have the same curly braces like more than that. But I think syntactically, we are used to keeping them in different lines. So they look thinned out, probably.
00:23:21
Speaker
Yes, that's possibly true as well. If you adopt sort of lisp layout and indentation of your C-style languages, they'll look pretty darn weird. Yeah, exactly. Because you'll have a line that ends in, you know, alternating braces, parentheses, and semicolons. It looked pretty natural to us, I think.
00:23:43
Speaker
Yeah, it's like, oh, look, look, here's a Lisp programmer writing JavaScript. But in terms of functional programming, because these days, I think Haskell is also becoming a bit popular. I just came back from Zuri hack. I'm not sure if you can see my T-shirt.
00:24:02
Speaker
So I was there and for I think about five milliseconds I understood what zygohistomorphic pre-paramorphism is. And then probably I didn't understand anything anymore. But there seems to be, because I go to Zuri hack every year almost. So this year there have been like 500 people. It has grown really big.
00:24:26
Speaker
So it seems like Haskell is gaining a lot of traction. So what is your opinion on Haskell type of functional programming versus closure type of functional programming? You know, it's one of those weird debates that people get into because ultimately it nearly always comes down to do you like static type systems or do you like dynamic type systems? Yeah. And there's trade-offs with both.
00:24:53
Speaker
And for all that it's great fun to argue the pros and cons, I think ultimately it comes down to a subjective preference of the developers.
Static vs. Dynamic Typing: Sean's Preference
00:25:06
Speaker
I've worked, obviously since I started with FP back in the early 80s,
00:25:13
Speaker
And I've done O since, let me see, yeah, early 90s. So I've gone back and forth between languages that are dynamic, that are strongly typed, statically typed rather. And I just prefer dynamically typed languages. I understand
00:25:35
Speaker
The trade-offs, I understand why some people like statically typed languages. I can certainly see why those people love Haskell. But for me, I just find statically typed languages to be frustrating when I work with them. So, you know, there's a lot of trade-offs. If you need a system where you are really sure
00:26:02
Speaker
that everything is, is going to be close to a formal proof. Sure. Haskell is going to be great. Idris, if it ever goes mainstream would be great. Um, there's a lot to be said for the additional, uh, safety that a very, very strict, uh, statically typed system can provide. But depending on what you're working on,
00:26:31
Speaker
There's also a lot to be said for a very flexible, very fluid, um, dynamic language, especially when you have the fast feedback of closures. Yeah. Um, and so for me, I find myself much more productive working with something like closure. Um, even though I'm going to be using it in the same style of programming as if I was working with Haskell.
00:26:55
Speaker
One question for you, Sean. I mean, you mentioned about your earlier work where you would essentially flesh out your ideas in Lisp and then write them in the parser language. Is that something you're attempted to do as well with Clojure? In other words, use Clojure. And I've heard people do this, you know, that they use Clojure as a kind of
00:27:13
Speaker
experimental land and then they will write it in a more optimized for the hardware type language after they've got the basic design and the feasibility all worked out.
00:27:27
Speaker
I could see myself doing it if I worked in a different industry. Because I work in the web industry, closure is certainly fast enough. And there's also still quite a lot of benefits of having closure in production, since you can just ripple into a process and inspect it. And even dare I say, apply patches live on the fly, if you wish.
00:27:53
Speaker
Um, and like I say, if I was in, in some industry where, you know, we wanted the most optimized, um, systems driven setup, then yes, I could see rewriting these, uh, proof of concepts or, you know, early exploration in something like Rust, perhaps. Hmm. Yep.
00:28:17
Speaker
So in being playing the bit with trust as well, I was really curious, especially given that it has a static type system and also the whole native compilation thing. I mean, especially if you come from a repel side of it, then it feels strange to go back to compile cycle.
00:28:38
Speaker
Yeah, it certainly can. I try to learn a new language every year or two. The pragmatic programmer book says, try and learn a new language every year. And so, in addition to having been doing Clojure more and more full-time since 2011,
00:28:56
Speaker
Along the side, I've learned Go, Elm, Rust, Kotlin, and I've gone back to Haskell several times. I keep going back and thinking, well, I'll learn a bit more Haskell. I'll get more fluent with it.
00:29:13
Speaker
And then I'm like, Ah, Haskell just drives me crazy. It's so frustrating to work with. So, you know, it's always going to be language a bit of Haskell while it's closure all the way through.
00:29:29
Speaker
It seems like my sort of journey. Every year I go to Zurich thinking that this is going to be the year of Haskell for me. And then I come back and, okay, back to reality now. I'm done. I told you, it's the Finnegan's work of programming. Yeah, exactly.
00:29:45
Speaker
so talking about closure development or at least using closure for development so emacs or some other shit you know it's it my story with emacs is also kind of one of those long weird ones um i started using emacs back in the 17 dot something
00:30:04
Speaker
The 17th century. Oh, my God. Yeah. 17th century. It certainly felt like that at times. So, yeah, very early on in my career, I was an Emacs user. You know, machines were very low powered. Emacs was lightweight, fast and powerful. I stuck with it through the 18 dot releases. And I think I was just into the beginning of the 19 dot releases when I was beginning to work with languages that there was better support in other editors.
00:30:34
Speaker
And so I moved off kind of into the IDE world for a while. One of the things that I used and absolutely love while I was a C++ programmer was a system called Together Soft. And it came out of a German company, as I recall, and you had both code editing and UML editing. And so you could draw a UML diagram
00:31:01
Speaker
and it would generate classes. And if you modified the class hierarchy, it would redraw the UML. And you could also draw sequence diagrams in UML, and it would generate the sort of the conditional flow of your code, C++, mostly I was working on. And I absolutely loved that system. I thought it was terrific.
00:31:27
Speaker
Sorry, my kids are playing games in the back time. Sorry about that. My cats are all being very well behaved at the moment, but I'm going to try not to disturb them. Otherwise we'll have the same thing here. Did they have Java version as well? They did together, yeah.
00:31:43
Speaker
together, Jay. Yeah. Holy fuck. Okay. I'm really old now. Jay builder. Yeah, exactly. Jay builder. Yeah. Because that's right. Yeah. And so, you know, I was using that. I was still doing work on systems where I tended to use VI quite a bit sort of on the system, but for general development, I was using IDEs. And so when I started to look at closure,
00:32:07
Speaker
I think when I did the workshop with Amit, I used TextMate and some early Closure plugin and the REPL. And as I started working with Closure more and more, I tried a lot of different editors and integrations. And for a while I was using Eclipse with counterclockwise, partly because I was also using Eclipse for my non-Closure programming.
00:32:34
Speaker
But, of course, the more I worked with Clojure, the more the gravity of Emacs pulls you back. And so I decided I'd go back and try Emacs. And I can't remember, it was preview builds. I think it might've been preview builds of 24 were available then. And so I downloaded, I'm like, oh, I wonder what's happened to Emacs in the last 20 years. And I powered it up and I'm like,
00:33:00
Speaker
Oh, wow. Yep. I still recognize this looks, looks pretty much just like it did 20 years ago. It's the same. Yeah. I needed obviously to get a lot more functional. Yeah. Um, you know, and so for a few years I was using Emacs again. Um, but
00:33:18
Speaker
I never found an Emacs configuration that I really liked. And I tried a whole bunch. I tried setting it up from scratch. I tried all sorts of curated versions of it. And in the end, I was like, no, no, this is just too clunky. It breaks too often. Anytime I updated packages, I seem to break stuff.
00:33:43
Speaker
And I was like, well, okay, let's see what else is out there. So I went and looked at a few other things. What really triggered me to change though, from Emacs was seeing Jason Gilman's talk at Closure Conge, where he introduced Proto-Rapple.
00:33:59
Speaker
Yeah. For Atom, right? Yeah. And I hadn't even heard of Atom at the time. And I was like, oh, that looks like a nice integration. Well, let me go try that. And I loved it. I thought it was terrific because it showed all of the results in line in Atom. And it just seemed a really nice flexible system. And, you know, you could extend it with CoffeeScript if you felt you wanted to.
00:34:21
Speaker
Yeah. And so I switched. And that was, gosh, I can't remember when he did that talk, but I've been an atom user ever since. And I switched from protoreple to chlorine.
00:34:38
Speaker
trying to think that was December last year, so I've been a chlorine user for about six months at this point, seven months. I don't even know what chlorine is actually. What is chlorine? It's a new closure plugin for Atom, but it works off a socket REPL.
00:34:54
Speaker
So you don't need N REPL as a dependency, you don't need an N REPL server up and running, you just need a socket REPL. And it uses N REPL under the hood to load the blob into, I think that creates another socket REPL that it uses for the control side of things. And what I like about that is I can take any closure process I've got,
00:35:19
Speaker
I can add in the JVM option at startup, and now I've got a closure process I can connect into with my editor and do full evaluation and all the things that I'm used to doing in Emacs, but I can do it from a nice friendly IDE editor running against any process at all with no extra dependencies. So you haven't moved to all the cool kits moving to VS Code yet?
00:35:47
Speaker
You know, I keep trying VS code and I like it. I mean, it's nice. I haven't managed to get used to the key bindings and I don't want to redo all of the key bindings just so that I'm comfortable with it. Who knows? I might end up switching to it. Everyone else seems to be loving it.
00:36:07
Speaker
The funny thing for me though, I looked at it and I thought the branding is a bit weird. Having an editor called versus code, it's like, whoa, what's going on here? Why are you? Is it deliberately provocative? Then I realized, of course, it was something else, but yeah. It's you versus code. Yeah, exactly. Microsoft versus code. Yeah, okay, I get it.
00:36:34
Speaker
We were just we're just talking I think just right before we started recording like the world has changed so much since since the early days of Microsoft to you know Microsoft being the evilest company if that is a word you know back in the day and then now they are like releasing open source software left and right and everybody's on vs code. There are more evil companies you know.
00:36:57
Speaker
Exactly. I think, relatively speaking, they became software, I guess. I would personally say that Google is more evil than Microsoft ever was.
00:37:08
Speaker
I do actually agree with that. And it's funny because I've been an Apple user since the very early 90s. I started with Apple using System 6 and I ran Tenon InterSystems Mark 10, which was a BSD 4.3 Linux that ran on the Mac. And the way it worked was it sort of parasitically took over the scheduling.
00:37:36
Speaker
And so you kind of booted up the app and you now had a Unix system that just happened to have a System 6 user interface. And that was what I used for development because it had full command line and I was writing a lot of C code back then.
00:37:55
Speaker
So you had Mac OS X before Mac OS X existed. Yeah. And I stuck with system six and then system seven and through 7.5 and then I skipped eight and nine and then jumped to 10.1.
00:38:11
Speaker
So for me, Apple Macs have always had a Unix-like command line system under the hood for 25 plus years. So when Microsoft started putting Unix-like stuff on it, I'm in the insider program for Microsoft and I have run fast ring builds of Windows 10. So I got very early builds of Windows subsystem for Linux when it could run Ruby, but it couldn't run the JVM.
00:38:41
Speaker
Yeah, and then it could run the JVM, but it couldn't run line again for some of the stuff lining. And then it could run line again, but it couldn't run boot. But the nice thing was Microsoft were doing all the bug tracking out in the open. They had GitHub repo. Their engineers were very, very proactive in responding to stuff.
00:39:00
Speaker
And I was like, oh, you know, this, this is different. This is interesting. And gradually over time, I've adopted much more Microsoft stuff than I ever thought I would. My iPhone runs Microsoft edge, Outlook, Microsoft to do and Cortana. My laptop is a windows laptop that I do some closure development on in PowerShell and WSL.
00:39:30
Speaker
And my desktop, even though it's a Mac, mostly I work inside Parallels running Windows 10 for all of my day-to-day stuff. Even though I still do closure development on the terminal side. This is horrifying. It really is.
00:39:47
Speaker
So you have a Mac running Windows in Parallels in which you have WSL that has Linux on it. Yeah, I know. It's like an inception. Serious inception. It really is. Yeah. But it is nice, right? I mean, it's wonderful to see we can do these kind of things these days. I mean, back in the day, the only thing that I can think of was like the wine or something to port all the Windows APIs onto Linux or something. And that's pretty much it.
00:40:17
Speaker
Then QT was the biggest cross-platform thing and there is nothing else. It still strikes me personally as a little bit sad that we're ending up with like three operating systems essentially. There's definitely scope for a few more.
00:40:32
Speaker
Yeah. I mean, there is still a BOS driven thing called Haiku something. Every now and then, I download the VM and then play with it a bit. So you can check out, I think, Haiku. But there is no other things left. There used to be QNX or something that is more real-time. For embedded stuff, yeah. Yeah, RTOS. But they, and then.
00:40:52
Speaker
There's quite a lot of operating systems at the IOT level. That's probably where most of the actual kind of like, let's say, innovation is really happening, I think, at the IOT level. Probably. Yeah. So maybe we should talk a bit about closure, I think. Yeah. We are almost like 40 minutes into the podcast. In one of the most- Yeah, exactly. So, you know, rest of the eight hours we can speak about the closure now. So, Sean.
00:41:21
Speaker
Let's talk about the latest development. Why are you doing JDBC? Next JDBC, yes. Well, going back to when I first got started with Closure and we were looking at doing it in production, Closure 1.3 was in development at the time. And so anyone who was around back then,
00:41:42
Speaker
would remember the huge sort of turmoil in the 1.2 to 1.3 change. In 1.2, we had a monolithic contrib library. It actually had 63 or 64 sub projects inside it, but it was only being released every time Closure was released. So it wasn't being moved forward very fast.
00:42:09
Speaker
And so they decided that what they'd do is break it up and only the libraries that had active maintainers would go forward, but they'd go forward as separate libraries. And I wanted to adopt Closure, but we used SQL databases. And so I was like, okay, well, what's going to happen with Closure Contrib SQL? And I was shocked that at the time in Closure, almost no one seemed to be doing SQL work.
00:42:37
Speaker
And so this was an unmentained library. Stephen Gillardi had written it and then had moved on from working with SQL. And I kept sort of jumping up and down going, come on, come on. I want to see a SQL library. I want to see a SQL library. And I think it was Stu Holloway eventually said, oh, for goodness sake, if you care about it that much,
00:42:55
Speaker
Could you maintain it? And I was like, yeah, yeah, sure. You know, I need to use it at work. I'm going to maintain it. And so it moved from Closure Contrib SQL to Closure Java JDBC. And I used it very heavily at work ever since.
00:43:13
Speaker
But it didn't feel very closurey. And so over time, I changed the API twice, in fact, with all those naughty breaking changes. And it had gotten to the point where it had a lot of history. It was solid. It was in production all over the place. A lot more people now are using SQL with closure. But the library had ended up with a lot of complexity inside it.
00:43:42
Speaker
Certain things were hard to do, certain things were slow. Because of its heritage, it had separate paths to run select queries versus DDL operations versus updates and deletions and inserts. And I really wanted something simpler and faster and more streamlined. But I couldn't do it without changing the API.
00:44:13
Speaker
So I started to think about what a modern version of Clojure Java JDBC would look like and started planning it late last year. And I actually had a GitHub repo just privately on OneDrive for months.
00:44:29
Speaker
where I was experimenting with what's the smallest, fastest, most idiomatic way to do this. And then I got to the point where I'm like, okay, I think I've got enough functionality here to show people.
00:44:45
Speaker
It's a different API, but it was simpler, faster, and I thought it a lot easier to work with than Java JDBC. But I still hadn't decided where it was going to live. I hadn't decided what to do with it. And so I wouldn't accept pull requests on it. I kept it.
00:45:02
Speaker
mostly hidden for the first sort of few alphas, because I thought maybe I would add it into Clojure Java JDBC as new namespaces. And people started using it and giving me good feedback. And we had a big discussion about contrib libraries earlier this year. Yeah.
00:45:23
Speaker
And in the end, I decided to keep Next JDBC where it is. And it does its CI up on Circle CI. It's got its documentation auto-generated on CLJ doc. And it lives in my personal GitHub repo. And it was interesting to see the feedback from people that they were like, well, that's OK. If it's got your name in it, we don't really care. We don't care if it's in the namespaces.
00:45:53
Speaker
Yeah. Um, but that, that was what drove next JDBC. And I really, I wanted it to be.
00:46:01
Speaker
much simpler to have a much smaller API. It now uses the JDBC execute method inside for all SQL. So it's much more consistent in its behavior. I wanted it to support Datify and Nav so that if you use it with Rebel or similar tools, you can actually navigate through essentially the schema of your data.
00:46:26
Speaker
I wanted it to use namespaced keywords, columns. So it fitted more with sort of the direction that Closure was going with. So that was what drove me.
Creating Next.jdbc: Motivations and Goals
00:46:38
Speaker
And we have it in production. We're using it in production alongside Closure Java JDBC. And I'm using Next JDBC for all of my new work in Closure that interacts with databases.
00:46:51
Speaker
Yeah, yeah. So apart from this, I mean, you're involved in multiple projects like CLJ time, and you've been contributing to a lot of other projects, including Closure Core. So as a person who has seen all the controversies around all the community-driven versus all this stuff, so what is your opinion on this thing?
00:47:15
Speaker
Yeah, I think I got to a point where I was a bit frustrated about what was officially said about Contrib. I think a lot of the discussions that have been had over the years about the pros and cons of it
00:47:34
Speaker
there wasn't a solid foundational understanding of what Contrib was. So people were coming at it from a lot of different positions. And I kind of badgered Alex a bit about it and said, you know, we really do need to have this stated much more clearly, because I think if it was much clearer what Contrib was about,
00:47:55
Speaker
people would stop haranguing the Closure Core team about those Contrib libraries. We've seen several pages go up on closure.org now that help explain what Contrib is, how it's governed, how it got to be the way it is. There's a great blog post from
00:48:14
Speaker
I think Stuart Sierra dating back to 2012, which is on the closure.org site that talks about how Contrib actually came into being and how it went from the 1.2 monolithic Contrib to the 1.3 individual projects. And so all of that's been surfaced now. I think it's much, much clearer what Contrib really is.
00:48:36
Speaker
And I think over time, what we'll see is more pieces of Closure's core infrastructure split out into individual libraries within the Contrib umbrella. But we probably won't see otherwise new things crop up in Contrib. I think we're at a point now where the ecosystem is so rich and so well established
00:49:00
Speaker
that people will naturally create their libraries elsewhere, which is fine. And gradually over time, I expect some of the contrib libraries to go from active to stable to inactive. And that's also fine.
00:49:20
Speaker
And so CLJ time is also something that you contributed a lot, right? Yeah. But it is completely out of country actually. Oh, yeah. I was the lead maintainer for Congo Mongo for a while when we were using MongoDB.
00:49:36
Speaker
I ended up co-mentaining CLJ time with Michael Clichon, partly because we relied on it very heavily at work and it lost its primary maintainer. Since then, of course, now that Java 8 is everywhere and we have Java time built in, CLJ time is now in maintenance mode and we're actively encouraging people to move off that.
00:50:05
Speaker
But yeah, there's a bunch of stuff. I'm trying to think what else. I've taken over Honey SQL recently because the maintainer kind of stepped away from that and we use it very heavily at work. In the contrib libraries, core cache and core memoize.
00:50:23
Speaker
which Fogus created. He hasn't been very active on those. And so they were transferred to me. And again, we rely on them very, very heavily. And I just yesterday put out a screencast of how I went about fixing one of the bugs that just got recently created for core memois.
00:50:49
Speaker
Uh, so I'm pretty actively maintaining those tools.cli is another contrib library that I maintain. Lost its maintainer and we relied on it quite heavily. So I took it over. Um, Java JDBC, obviously they've been maintaining for eight years. Um, next dot JDBC, which is, you know, what I consider to be the next generation of it.
00:51:15
Speaker
And if you go to my GitHub page, you'll see dozens, I can't remember how many repos, I don't know, like 80 repos. And some of them were things that I forked intending to maintain and then found I didn't actually need them much. For a while, I had the most active fork of CLJ soap.
00:51:38
Speaker
And I started getting a lot of questions about it. I'd done it because I found a version of the library that didn't run on 1.3. So I forked it, got it running on 1.3, tried to use it to talk to a third party system at work, and eventually gave up and went a different approach.
00:51:59
Speaker
But I started getting so many questions about CLJ soap that in the end, I had to put a notice on the repo saying, if, if you want to help with it, please fork it, you know, and, and run with it, but I'm not maintaining this. So open sources is forever because if you do start to maintain something, you can guarantee someone will find it and want you to fix a bug or help them use it or something.
00:52:25
Speaker
or flame you for not getting it perfectly right according to their needs. Yes, yes, yes. You know, there's definitely there's a lot of great stuff about being an open source project maintainer. But sometimes you do kind of want to reach through the wires and slap people down. Don't be so damned ungrateful. There should be there should be something, you know, some some sort of a rebel command. I'm pretty sure there is a new Max command for that.
00:52:54
Speaker
And I feel for the Closure Core folks because, you know, there's so much grief that they get over some of these things. And, you know, Stu and Rich have been very, very clear over the years that just because you create an open source project doesn't mean you owe anyone anything. You know, you've created it. You've developed it for whatever your needs are. You've made it open source. Yeah. Other people can use it.
00:53:23
Speaker
But then, you know, these people turn around and demand you fix this bug. This bug's holding up my entire production infrastructure and I've done it myself. I must admit, I mean, I, I, I berated project maintainers because, you know, this, this is a terrible bug. How on earth could you let this get into your code and why won't you fix it immediately for me? Um, and then I go, wow, don't I sound like an ass? I shouldn't do that. That that's not nice. Yeah.
00:53:51
Speaker
But it's kind of a strange thing, especially in terms of open source, because where does the ownership lie? Especially once the, for example, if you have seen like CLJ time and other things that you're maintaining, it's really awesome that you're maintaining all this.
00:54:07
Speaker
I would say even one of the core libraries that everybody is using, JDBC is something that everybody uses practically. And CLJtime, I'm pretty sure there are plenty of projects and I've used it myself everywhere. But at the same time, you have this risk of one person just maintaining it, right? And then if not finding someone to hand it over, then it's an extremely risky proposition.
00:54:33
Speaker
Yeah, it is tough. And I mean, when we stopped using MongoDB, I continued using, uh, maintaining Congo Mongo for a while. Um, but I was really trying to get someone to take that over. Uh, and then, you know, as the maintainer of it, I was going, well, you know, if you're starting using MongoDB, I'd go use Mongo because that's actively maintained and Congo Mongo isn't.
00:54:56
Speaker
But someone did step up. They were using Congo Mongo at work. They were heavily invested in MongoDB. And so they've done a lot of work on it since I handed the project off to them. CLJ time is kind of the odd one because we've sort of actively deprecated it and told people to use Java time instead. But a lot of people still seem to pick it up and run with it, even though the read me is quite clear.
00:55:22
Speaker
Yeah, that's that's an interesting thing, right? Because if you think about it, we have JDBC and and there is a nice closure API that you're building on top of it. Don't you think CLJ time has the similar kind of vibe? I mean, for me, it feels like it absolutely does. But
00:55:39
Speaker
It's built on top of JODA time, and the JODA project has said, stop using JODA, go migrate to Java time. And so that's really why CLJ time is in maintenance mode at this point. Yeah, probably there is a need for CLJ time next.
00:55:58
Speaker
Yeah, it's going to be on top of Yeah, I time time and date is such a hard. Yes, yes. So, you know, I've said to people go use Java time directly via interop. Or if you really want to wrap up those closure dot Java Java time, and there's a newer one just come out, which is
00:56:24
Speaker
cljc.java time, I think, something like that, which is a very, very thin wrapper around Java time. But it also provides the exact same API in JavaScript. And it has an implementation behind it, essentially of Java time, but for JavaScript. That's kind of cool. I think there was a presentation about it at the closure north.
00:56:46
Speaker
Closer north, yes. Yes. It looked very interesting because I think there's a lot of people wanting to use those kind of affordances on both sides. I think it's a very interesting project. Yeah. It's interesting for me because
00:57:01
Speaker
I work with Kevin Downey, hired man on stuff. And we are the closure team, he and I. And he doesn't have a lot of time for wrapper libraries. Unless they offer something
00:57:19
Speaker
beyond the API, as far as he's concerned, just use Java Interop because it's perfectly fine. And with Java time, that's mostly OK. But there are certain things where it's like, oh, that amount of Interop looks really ugly. Here's what it would look like in the closure wrapper. Yes, this is a win. This is much more readable closure code. So he and I do sort of have these discussions about whether or not
00:57:49
Speaker
replacing this particular piece of Java interop with this particular closure library is worth it or not. And I've certainly found since I've been working with him, I tend to drop down to Java interop more often than going out and finding a wrapper library now. Now that might change if I started doing closure script as well, because I would want
00:58:11
Speaker
Certainly for something like time, I would want the same API so I could share source code between ClosureScript and Closure. Yeah, that makes sense. So in terms of your team, because you have transitioned from the other language to Closure, so how hard it was to make them start on Closure?
00:58:33
Speaker
You know, it wasn't that hard. It was, it was really interesting because, uh, we were a team of three at the time. Um, I introduced closure and both of my teammates were kind of like, Oh, that looks like fun. That looks interesting. Yeah. You know, we'll get paid to learn a new language and, you know, improve our skills. And it did work fairly well for quite a while. Um, the more closure we got though.
00:59:01
Speaker
the more our development process has changed. And gradually our deployment process has changed too. And in the end, those two team members both moved on. One went back to a cold fusion shop. They'd been a cold fusion developer for years, a decade or more, I think. And they liked cold fusion and that's fine. And cold fusion developers are in short supply.
00:59:30
Speaker
They could get nice jobs. And then the other team member moved on to go and work in a much more closure, rich environment. So they kind of went in opposite directions. And when we hired in Kevin, you know, he's only ever done closure. I mean, this is what's kind of so awesome about working with him. Closure was basically his first language. And so he's very
00:59:59
Speaker
uh steeped in closure thinking um and that's really nice because we don't we don't end up having discussions about should we do this enclosure we might have discussions about how we do this enclosure yeah uh and the two of us you know we're we're pretty darn productive um you know it's one of those things where you can get a lot done in closure with very few people yeah so how does your stack look like in terms of closure
01:00:27
Speaker
Well, most of the apps we have are web-based. So the Ring, most of them are composure. We have one that uses Biddy for routing. We run on the Embedded Jetty adapter for everything. We use Selma for any HTML templating we need. Several of the apps use Core Async fairly heavily.
01:00:55
Speaker
And then the different apps use a lot of different things depending on what they're specifically for. We have an OAuth2 authentication system. We've built our own OAuth2 server.
01:01:11
Speaker
So there's a whole bunch of Apache libraries bound into that on the Java side. Our sort of corporate ware is all based on Office and Microsoft authentication. So we have a bunch of Microsoft libraries that we use for all of the interaction with the Microsoft systems there.
01:01:36
Speaker
It's a pretty varied setup. We use Redis, so we use Redison because that handles the clustering very nicely. So there's a lot of Java level stuff that we're using and just a huge grab bag of closure libraries. But the core stack is Jetty, Ring, Composer, Soma. And on the front end, you don't have as much closure script, I suppose.
01:02:03
Speaker
No, we looked at ClosureScript back in 2014 and 15. And it was, you know, that was pretty early days for ClosureScript. The tooling really wasn't there. The language wasn't on a par with Closure. But we built a proof of concept, a real-time dashboard with Arm and Senti for the WebSocket.
01:02:28
Speaker
And that went reasonably well as a small project. And then we rewrote it using Reagent just to see the pros and cons. And we decided we liked Reagent a lot better. But the tooling was very sharp and very rough around the edges. And we kept running into things you couldn't do in ClosureScript that you could do in Closure. So we had to keep remembering that it was a dialect and not really the same language compiling to JavaScript.
01:02:57
Speaker
And in the end, we decided that whilst we could probably use it for internal projects back then, we didn't feel at all comfortable putting it in front of our customers around the world. Particularly because it's a global customer base and a lot of users are on either slow connections or slow devices or certainly were back then. And to be honest, it was hard to find ClosureScript developers.
01:03:24
Speaker
Yeah. So we ended up going with React and JavaScript and we hired in two developers to build the front end and they're still with us. And we have the whole front end of the app. If you go to any of the dating sites, it's a pure JavaScript React app that talks to closure services on the backend.
01:03:51
Speaker
Yeah, yeah. So you're building closure that bringing people together. Yes, that's kind of what we like. I mean, I don't know if you can see the t-shirt. Yes. We make real connections happen, which is kind of our sort of thing.
01:04:06
Speaker
So with the React people, because they kind of have the GraphQL stuff now. And GraphQL is the big next thing for APIs, let's say. Is that something which you're also experimenting with?
01:04:25
Speaker
Yeah, actually, we have one of our apps which Kevin built over the last year, which all of the API for that is GraphQL. So we're using Licinia for that on the Closure side. And that's proved to be a very nice, flexible way to interact between a Closure server and a React-based JavaScript app.
01:04:45
Speaker
And you're still, and are you kind of like getting the data via the JDBC libraries? Because you're not running a graph database at the back, are you?
01:04:56
Speaker
No, we use Redis for some stuff, but pretty much everything we do is MySQL. We have a big, fast, well-tuned cluster of Percona 5.7 servers. And so all of our data goes in and out of the system through Closure Java JDBC for the legacy code and Next.JDBC for code we're writing these days. And then
01:05:22
Speaker
It's all transformed, it's all data inside, and then it's fairly easy to transform it in and out of whatever we need for GraphQL. This is a random thought, but does that help with the GraphQL? We're not using it in that area at the moment.
01:05:41
Speaker
It's going to take a little while before the Datafy Nav stuff kind of permeates through. Mostly where I leverage that right now is in development and debugging, because I use Cognitex Rebel all the time. And so when I'm working with code that is pulling data out of the database,
01:06:03
Speaker
I can navigate through it automatically across multiple tables, and so I'm finding it very useful from that point of view. I think we probably will look at doing datification and navigation on other things over time, but it's still kind of early days for that. It takes a little while before you really see a good application of these things.
01:06:32
Speaker
On the same note of making real connections, thanks a lot for managing Closure and Slack and everything. I know you're one of the admins there. Yeah. Or maybe you were one of the persons who created the organization, probably. No, no, no. I just got on board with the admin team pretty early on. I think it was just one of those experiments. It's like, oh, Slack, communities are using Slack.
01:06:58
Speaker
There's a closure slack, okay, I'll go join that. And to this day, I'm still absolutely stunned that we've ended up with 15,000 people on the closure slack. Now, I think only somewhere between about 1,500 to 2,000 are active on a sort of a day-to-day basis, but it's still a very, very active closure community.
01:07:22
Speaker
Yeah, that's true. And also, I mean, as I was talking to you right before we clicked record, I mean, I've seen you in the Closure community for so long. You know, it's like it's synonymous. It's like, oh, you know, apparently Sean is part of Closure stuff. It's impossible for me to see, not to see your name anymore, anyway.
01:07:43
Speaker
because you're so helpful on Slack, you're so helpful on even on Zulip, you know, you joined early on there, and on Closureverse, for example, and you take time to help other people, which is really amazing, and all the libraries that you're maintaining, and this is extremely helpful. And hopefully, you know, you keep making more of Closure stuff at work. Yeah, we're deeply invested in Closure at work at this point.
01:08:10
Speaker
Yeah, yeah, that's amazing. And also I see every time there is a new release, I immediately see your email saying, oh, we tried this alpha on our systems and everything is fine. It's like if you say everything is fine, I'm like, oh, okay, that seems like a big code base. So I'm happy. Yeah. I mean, this all started because we got going before Closure 1.3 was actually gold release. So if we wanted to go to production, we had to go to production on pre-release build.
01:08:35
Speaker
And one of the things that's so amazing about Closure is it's so incredibly stable that we've been able to adopt alpha and beta builds of every single Closure release and go to production on them. And I'm trying to think, I think we got shot in the foot once and we dodged a bullet once. When 1.5.0 came out, it had a bug in.
01:09:01
Speaker
that was quite a showstopper in production for some people. And 151 was released very, very quickly.
Using Clojure Pre-Releases in Production
01:09:09
Speaker
And it just so happened that our release cadence had us go to production on a release candidate, and our next production release happened to fall after 151. So we didn't actually have 150 in production.
01:09:23
Speaker
But it was almost pure coincidence. But when the spec stuff started, we adopted that very early on. We ran with pre-release builds of 1.9, pre-release builds of 1.10.
01:09:40
Speaker
Yeah, I'm chomping at the bit to get hold of spec two. We actually have a branch of our code base at work that runs on it. But until Alex gives me the green light that it's supposed to be robust enough and stable enough to be used in a real world app, I'm not going to pull the trigger on that.
01:10:01
Speaker
But yeah, as a company, we do try to take advantage of the new things that come along because it makes our lives easier. Yeah, and also you're providing a real-world code-based feedback immediately, and that is also helping a lot to the community. There might be other people who are not as fast as you in terms of adopting, but at least you're helping them, giving some sort of an idea of where the point is.
01:10:32
Speaker
And I really do want to encourage people because I'm very, very happy working with Closure. And I've been very, very happy working with Closure, Alpha, and Beta builds. And so I really do want to encourage more people to use Closure to pick up the new features as soon as they become available.
01:10:52
Speaker
You know, it's kind of, again, spec two, it's kind of an interesting thing. I'd love to encourage people to play with it. But if I encourage people too much, Alex usually pops up and goes, oh, wait a minute, you know, it's not ready for release yet. Don't do that.
01:11:08
Speaker
One of the things I use from you actually is CLJ New, because that makes it pretty easy to start a new Deps.Eden project, which I've got to say for me, I think that's been, for me, for my personal workflow and at work as well, that's been huge, the Deps.Eden stuff that really has
01:11:29
Speaker
Yeah, we switched over completely last year to CLJ and DEP CDN. Obviously, when we got started with it back in 2011, the only game in town was Liningham. Yeah, sure. And I tried early versions of Boot when they appeared and it seemed, it wasn't cross-platform and it seemed kind of fragile and weird. But when 2.5, I think it was, came out,
01:11:58
Speaker
Um, that, that was just a really strong, solid, stable product at that point. Uh, and we actually switched from line again to boot in, I want to say 2015. I think it was December of 2015. Um, and we, we hit a bit of a wall with line again.
01:12:19
Speaker
We have a mono repo, we have about 30 sub projects in our mono repo. We needed to be able to manage and build them all individually, but we also have a lot of source level cross usage.
01:12:35
Speaker
And we didn't want to have to build artifacts just to depend on projects across the Mono repo. And part of that is legacy reason because of the Coldfusion stuff, which is all based on using Clojure from source, not from libraries, even though we could package everything up in libraries.
01:12:53
Speaker
So we switched to boot. It was much, much easier for us to build custom tasks. We kind of got in very deep with boot. We ended up with something like a 2000 line build file. Wow. Yeah.
01:13:11
Speaker
Um, which had a huge number of tasks in it that all should have been separated out into different namespaces. But you know, you start off and you go, well, just add this one task or not. Just add the second task. And I might as well add these next three tasks. And then suddenly you've got this, this giant monstrosity. Um, but we had begun to run into some, some weird edge case bugs with boot, um, with the pods and the way pods refresh. We'd started to see strange, um,
01:13:41
Speaker
bugs from that and I did eventually open a bug report because we were getting it often enough that it was clearly either something we were doing wrong in our usage or a bug in the pod handling. But it was really hard to produce a repo case because we were the only people seeing this and we were one of the few people who had such a gigantic boot system.
01:14:07
Speaker
So when the CLI came out, as has always been the case with me, I'm like, Oh, you know, new shiny, let me go try it. And I realized that it would solve a lot of the problems we had because we could have every sub project with its own depth CDN file. We could have kind of a master depth CDN, and then we could easily pick and choose which sub projects constituted any given artifact we wanted to run or build.
01:14:34
Speaker
And so we switched over, we took boot out of the picture completely. And we have a small shell script called build.
01:14:44
Speaker
which you can give it a list of essentially alias groups and a sub project. And it will loop through all of those and run the various things. So if you, for example, wanted to build an Uber jar and put it up on a test server, you could say, build Uber jar project name, run CIFTP project name and the target. And it would just go off and do that.
01:15:12
Speaker
And so, yeah, everything we do is aliases and depth CDN and this little tiny shell script to glue it all together. I got a little comment the other day actually from Mike Fikes. And he said there's such a thing in depth.edan, which I've never heard of called the core field comma.
01:15:40
Speaker
I don't think I originated it, but once I'd seen it happen as a workaround, I was the one popping up on chat all the time going, ah, if you use a comma, that'll work. So the issue is that
01:15:56
Speaker
The CLJ is a script. It's a shell script. And so it's taking EDN from the DEPS files and things from the command line. And ultimately it's creating cached versions of main operations, libraries, and dependencies, and so on. If you look in any folder you view CLJ in, you'll see a .CP cache directory.
01:16:21
Speaker
And inside there are the various files. Well, because the way it works with the main ops is it writes it out to the file. And then when it gets to the run part of it, it sucks the file in as a set of command line options by going from closure to shell, back out to shell, back into closure.
01:16:46
Speaker
it's really hard to get the escaping right. And so if you do something simple, like trying to start a socket REPL and you say, okay, we need the JVM opt minus D closure server, REPL equals brace port space, 5,000 comma space, accept space,
01:17:09
Speaker
and the server name and it goes through and what pops out is individual command line arguments. And of course it breaks and someone somewhere said, ah, but closure uses comma as white space. I wonder.
01:17:25
Speaker
And it just happens to work. And because I was using depth so much, I'd got commas in all of my compound stuff. And someone jokingly one day, when I popped up for like the 20th time saying, do you use commerce? That'll work. Said, ah, the Corfield comma. And I'm like, no, no, no, don't, no. So we're compounding that now. Yes. So, so I'm, I'm forever going to be known for it.
01:17:53
Speaker
It would be amazing after all these years of work and all these years of libraries and every possible language. There are certain things that get people's names attached to them in really unfortunate ways. From the C++ world, there's something known as the Koenig namespace lookup rule. And it's named after Andrew Koenig.
01:18:21
Speaker
And I, someone pointed me at a piece he'd written or interview he'd done where he actually said, I don't know why my name's attached to this. I did not come up with this particular lookup rule. I was just editor at the time and, you know, talk about it. He said, you know, I kind of wish I could remember who it was. And I'm thinking, I probably shouldn't put my head above the parapet and say it was me.
01:18:47
Speaker
But it was. We were in committee. We were arguing we'd spent several meetings and lots of working group time looking at how friend and namespace lookup interacted in C++. And it turned out that there was this one particular case that was quite common.
01:19:10
Speaker
where you essentially needed friend to be transitive across namespace lookups because you needed to be able to bring in friend functions from a namespace and have them automatically get picked up in the lookup chain without having to do some syntax to say, oh, when I say plus here, I mean this friend function from that namespace over there. And we tried all sorts of things and I somewhat jokingly
01:19:39
Speaker
suggested what I thought was this really complicated but clever, clever extension to the lookout rules. I really meant it as a joke because it was really complicated and the committee sort of thought about it and went, you know,
01:19:58
Speaker
that actually does solve the problem. And it isn't too horrible for us to write it down and describe how it behaves. And I was just like, Oh no, what have I done? And I just feel very lucky that Andrew Koenig's name somehow got attached to this. And so it's forever been known as the Koenig namespace lookup rule. So, so there you go. Now you're wondering, I don't think I'm ever escape the comma.
01:20:26
Speaker
As you know, this, this, this podcast is super popular. So from now on, you'll be, you know, maybe you should just register the domain. Like Amazon board, they don't get the comma. Yeah. Very valuable. We listed it. I was sitting on.
01:20:47
Speaker
Anyway, so, um, wow. Uh, time flies from APL to closure. Um, so any man back again. So any closing thoughts Sean about closure and about the work and you know, all the stuff that is going on around the world.
01:21:06
Speaker
Yeah, I think a lot of people talk about the joy of working with Clojure. When people ask me, people who aren't Clojure programmers, when they ask me, why do you like Clojure? I say, because it makes programming fun.
01:21:22
Speaker
tangible and malleable thing. You've got a REPL, you're interacting with your code right there. This weekend I've actually been going through the third edition of Dimitri's web development book because I want to go back and learn the current state of the art with ClosureScript tooling and I figured that his book would be a good way to get into at least some of that with Luminous. And
01:21:49
Speaker
My first sort of roadblock was oh, it's it's all line again and then rebel based and my current editor doesn't do and rebel and I was like wait all I have to do is start a socket rebel and it'll all just work.
01:22:02
Speaker
So I added a line profile called socket, which adds the JVM up to start a socket repl. And so whenever I'm doing any of the examples from the book, I just say line with profile plus socket, whatever, connect my editor to it. And right there, I've got all of the code. I've got all of the
01:22:22
Speaker
the muscle memory of everything that I do working with it. Um, and so that's what I really love about closure. And that's what I tell people that it's, it's so involving. So, so fun, you know, and we live in a world where, you know, fun sometimes isn't a bit of short supply, particularly when you're working.
Clojure: A Source of Joy in Programming
01:22:44
Speaker
So to find something that will bring joy to your work, I think it's terrific.
01:22:50
Speaker
Well, yeah, that's an excellent sentiment, I think, which we can all get behind here. Agreed. So I think, thanks again, Sean, for spending this time with us and hopefully your cats are not really agitated that much. No, one of them's bored and she's gone up and she's wandering around. I'm surprised she hasn't started yowling. The rest of them are all sacked out because it's just so hot here.
01:23:17
Speaker
But seriously, all the hard work that you're putting in, in the open, with the libraries, with participating in the community and everything that you're doing, thanks a lot for that. And thanks again for taking the time to join us today and sharing your vast experience with us. Well, thanks, guys. It's been a blast. Thank you for having me on. Of course, it is. Awesome. And hopefully we'll get you back again and then discuss APL.
01:23:44
Speaker
I think there should be a podcast that reads out APL code loud. That'd be amazing. So I think that's it from us for episode number 51. Ray, any closing thoughts?
01:23:59
Speaker
No, it's been a really great conversation. It's amazing to meet... I've talked to Sean occasionally in Slack once in a while and always super chill and friendly. So it's really nice to have a personal conversation and we'll do a bit more of this in Slack as well.
01:24:20
Speaker
I love using your code and your bytes. So it was great to get some new experiences today as well, because there were some things you were talking about that I didn't know about. So I'm pretty sure the listeners will have got that as well. So thank you very much, John. Thank you. Thank you. Thank you. So goodbye, and then we'll see you in episode number 52.
01:25:09
Speaker
you