Interview and Q&A with David Nolen

[Music] [Music] um david david hello i hear me do you hear me i can hear you loud and clear yeah great great okay so i will leave you alone and please have fun good luck and have fun thank you so thank you david for joining us yeah yeah welcome to the show so yes uh uh we know you as a uh one of uh maintained developer of closure script but i think it's better if you introduce yourself because i think you're bigger than just a developer of closure script so please introduce yourself hi my name is david nolan i'm a software engineer currently i work for a company called valgio and uh we're in the sort of um sort of cryptography digital key identity space um and uh it's a pretty interesting small startup the cool thing is that everything that we do is written in closure so every component of our stack um all the crypto bits and the back end services we're building two react native applications one's like a sample thing and one is in you know an android ios uh key application identity application um yeah so we just we just use clojurescript everywhere i mean there's i think the only place where we don't use it is like uh in our current line of work um we do have to write some c code which is unfortunate maybe writing a list um but for those of you that that might not know um is that closure is a functional programming language uh came out in 2007 uh it targets the java virtual machine you have a question go ahead yeah yeah let's let's move slowly so the i think the question how did you to the closure community how you joined it so can you tell this story and maybe probably why you picked the closure or something else yeah so let's start slowly we have a lot of time so let's yep uh i agree um so what happened was that i was doing software like i've been doing javascript since 2005. um you know ie6 at that point would still need to be supported so i remember the days before firebug um you know long before modern javascript was a thing script tags all this stuff browsers crashing because you wrote the wrong activex thing you know in your css file and uh you'd have to like you know go through your cvs history to figure out what happens so i've been doing a javascript a long time lots of iframes um i remember when ajax was like a new thing uh so i've seen i've seen javascript change a lot so you know it's a long story but to cut it short i did i was actually a ruby developer at and javascript developer the new york times for four years i'm actually my co-worker was um jeremy ashkenaz which some people might know because he worked on um and uh so it was funny so so we were doing a bit of javascript and coffeescript and at the time i had already gotten to list like lisp i had like read some list books i was like lisp is so weird it's so old but it's still cool you know it's like one of the oldest programming languages right there's um still in use and advisably similar to the original thing the only thing that's really like that today anymore i think is like fortran right like fortran looks pretty much the same as it did uh back in the day lis does in the you know there's different language features but uh most of john mccarthy's ideas about functional programs recursion the list data structure all this stuff repple the rebel was you know the original rebel was a typewriter was a network connected typewriter like before you know like screens were pervasive um so anyways i was into that and i was always like you know coffeescript showed that people weren't completely against compiling to drop right you have to remember back then people were like i will compile javascript like i'm not i'm never going to compile the javascript which is like you look now and like everybody's compiling the javascript it's just javascript to javascript but everybody's compiling javascript right but back then people were like i'm never going to compile and uh coffeescript paved the way and showed that there was an audience for uh people who didn't mind compiling the javascript and um what happened was in 2011 i had been at the new york times for one year rich hickey who created closure created a version of closure that could compile to javascript that was called closure script and um you know i like you know i've been open source for uh you know for a long time like a lot of developers are and i saw you know having done javascript for such a long time i was like oh finally like my passion plus my my line of work javascript so i started contributing to closure script so that's really how i got involved it was very much like a open source fun thing for quite some time and then in 2014 i actually went to work with richie's company cognitech and i got to do clojurescript full-time there i've since left but um and that you know i it was great i had a great time working at the sort of closure company and now it's pretty cool like you know clojurescript has a small but very loyal and active community and uh i get to use it for work so like it all worked out in the end so cool yep like okay so how did the closure script looked back then when you just uh approached it when you when you started uh trying stuff out like how did how how different it was from what it is now and uh what what you yeah like so that's a great question it's very it's very different now i mean one of the biggest differences to be honest was react so prior to the appearance of react you know closure and closure are functional so they are oriented around immutable data structures and most of the javascript frameworks that you would do serious work with whether it's back then it was very uh you had backbone um i think ember at that point was happening um marionette there are so many of these right there's so many of these mvc frameworks the problem was was that using uh an object or there's nothing actually wrong with the object-oriented part but using a traditional mvc framework meant that you were dealing with something mutable and stateful so using clojurescript to write uis it was cool but you know you felt like as i'm just writing javascript with clojurescript which was kind of missing the point um and in 2014 react had come out 2014 was it 2014. it had come out that summer to you know everybody was like this is the dumbest thing ever right and now we've come full circle now people are hating on react because this is so popular but but back then people hated it because it would have xml literals and i was like i don't really care that much because i didn't really understand it but my friend was a also doing brandon bloom he was dabbling in closure script and of course had followed react and was like actually there's this real really cool feature in that um i bet you could use this from a functional language and it would be a better integration than it would be with the traditional nbc and then um jordan walk the original creator of of of react on twitter was like i just replaced um in my and they were building a comments feature in facebook i just replaced the backing store of our comments feature with a persistent data structure and i got a 10x speed boost and i was like whoa they're using persistent data structures at facebook and then i was like well do you think do you think it would be i meant something directly i was like do you think it'd be easy to integrate that from a functional language he was like i think that'd be easy and then i met with peter hunt who was an evangelist for react at the time and we had uh we had a coffee across the street from the new york times it was brandon bloom and peter hunt and i was like sat down and i picked his brain for about an hour and a half and then i went home and it took me about two weeks and i was able to show that actually react with much more idiomatic integration that even though react had a object-oriented facade the semantics of it were better for functional programming languages and it was interesting because i gave a talk about it i think after i did ohm that was like my first react logoscript integration i gave a presentation about it uh three or three three months later at a closure conference and at the time i asked the audience there was about 400 500 developers how many people in this audience have heard of react this was early 2015. nobody no no nobody at your conference knew what even knew what react was uh six months after that um everybody knew what it was and re enclosure script it did like clojure script still is needs to grow its community base but overnight the closure community almost instantly impressed script right it went close your scripts that weird thing you have to be a little bit you know bananas to use it to being like wow i get i get to use all the things i love about closure and i can build functional uis that are easier to understand uh with respect to state i mean of course in the end yeah i remember really i remember your thoughts when you wrote the post about the uh react plus closure script which is uh uh beat the manually optimized uh uh backbone yeah and i think you you you help it react with the popularity because i think even not not closure script developers saw this post and they start thinking what is react at least it's about a story about me so when i read this post so the first question was what is react so your post was even before reacted i think it helped little bit react to get more popularity it was it was it's funny because i i i used to be an act a more active blogger and um that post was like the most popular post i ever wrote by like 10x so like it take all the all the page hits that all my other posts had ever gotten and that was 10 times more than all the others combined so yeah you're right in that um the impact was far beyond clojure script sure that convinced the closure community to embrace closure script and react but yeah for sure um that triggered i think the beginning of a lot of inside of you know in the javascript community it got people to look at react a second time i think it uh were it just worth it to reiterate how persistent data structures are actually become uh very useful when you doing stuff like react and that performance boost you just mentioned was it because of how easy it is to compare to mutable data structures if they are equal and then to decide to optimize something like just uh right so that's a good point um you know i talked to when i talked to jordan walk there's this feature called um should perform update i can't even remember it anymore like it's like it's hit like all the libraries i use hide that thing but yeah you're exactly right persistent data structures the way that they work is that um you know nothing has changed because the way that they work is that if the root reference is the same as it was before then it's not possible that anything was mutated underneath the root of the tree so you so what you could do is you could just do a pointer comparison you could be is this the same route as it was before the data just the data of your ui state if it's the same route we don't have to we don't have to do deep equality if the route hasn't changed you don't have to check anything and the cool thing is that as you render the tree if the root did change what's going to happen is that as you render the ui graph you're going to be checking each point well is it equal at this subtree is equal to subtree and it means that there was like huge um areas where react would never do anything if you use persistent data structures i mean again you know to be fair after a couple years i mean it turns out that there are other things you need to do but what the the point about what i was trying to say is that it was great how much performance you got with very little additional effort really new right because previous to that um when you were talking about something like backbone really to optimize it you have to keep that these sorts of optimizations in your mind you have to be like oh i don't want to trigger a bunch of domain dom updates i want to i want to i wanna uh combine the domains i wanna balance whatever there's all these tricks that become like things you have to remember and i found it very um interesting that with this sort of immutable standpoint you could get pretty good performance out of the box and then of course there's a there's just like as there is with any system there's a host of other tricks to get more performance uh i just thought it was really fascinating that with um some good choices that the performance could be quite good without caring about it i mean that i think is the most important thing right as a programmer you're like how can i get decent perf and not really sit around and have to think about that problem especially when you're doing a new effort or you're starting something new it's nice that when optimization is a detail it's an extra bit of work you do later rather than something that's sort of pervading your work so david can we make some technical introduction what is closure what is closure script because guys mostly from javascript land and can you try to convince them and give the reason why they should look into this area and uh what what's new they can get from the uh from the closure if they try to learn this language and why it works well so i mean if you like i mean so it's i mean there's a few things to talk about here because there's one pretty big trend in the javascript community which is typescript so typescript has gained a lot of um popularity so i think we should come to that but really clojurescript is you know if you're a javascript developer quotascript i think is not as big of a leap as you would think um i liked javascript back in the day because um javascript's dynamic it's flexible um it's fun um and i think to a large degree it's quite capable i mean people like to say i mean there's arguments on both sides whether you can build large software or not um with dynamically typed languages but i think the truth is is that there's so much javascript out there in many application whether that's mobile applications massive websites i think um it's still debatable um whether you whether it's important that you need types to write software i'm not saying that they're not useful they're certainly very useful but i think javascript has shown um that you can be very effective with dynamic programming languages so if you are if you believe that or you don't think that it's the deciding factor in whether software succeeds or fails which that i think is the most important question people want to say that there's some specific thing that causes a software project to fail and you know in truth it's almost never the technology it's you know people organizations and processes so if you uh buy into that then i think why clojure script over like javascript and i would say clojurescript is like javascript in that it's dynamic it has a small set of um really great data structures i think another thing about javascript that's great is that simple you have maps you have arrays really i'm sorry objects and arrays and there's some power in the simplicity of that and closure is also very similar it's data oriented um a good example of why this is cool is that you know you look at the javascript ecosystem and you say why did it explode why is there so much tooling why are there so many compilers and i would argue that one of the biggest reasons is that javascript defines its ast as javascript data right you don't have to have typed asts right you have a standard ast format any freaking tool can consume it and i don't have to share like a bunch of ast nodes in my with my specific types right that there's power in the fact that the ast is generic that it's represented at js as json you can read the specification and i can write a tool and i don't need to subsume too many other libraries to write a custom pass a tool and add a babble thing i mean that's something that that people really need to think about the reason the ecosystem is exploding there is because it's really easy to write tools around the shared asd representation script so that's like huge right data right of truly uh agnostic data format that you can move around it's great i mean that's a huge lesson from javascript and you see that json is still the advantages of over highly specified data exchange formats the flexibility of json um is here to stay so closure script says if it's good for every part of your system if you're already using json you know to deal with tooling to deal with your your data exchange enclosure says take that to another level we can write entire programs around that format um and they can be very effective and just to give you a sense uh you know we're this is not just me like you know we could say this and it would be like empty market speak if we didn't you know eat the dog close your script actually close your script itself um the ast closure actually to this day closure is the ast is modeled after java types and it will never escape the jvm so all these type java types it's like that compiler is not reusable and rich hickey when he did closurescript was like that wasn't great that's really not awesome and so he wanted a pure data representation for for the crypt ast so it's represented as eden so closure script is now some 50 000 lines of closure and the entire ast just like javascript represented as json a closure script represented as eden so where you know eden when you think eden all you have to think is that's closure's version of json it's a generic data representation that any closure program can consume um you know it's maps in fact instead of being objects and arrays um and so we've written we've maintained a piece of software now for almost a decade um and it's not hard to maintain right it's not hard to maintain we represent the ast as data and there's a lot of um power in that uh you know we and again when we build our systems are the programs we're writing you know for work again we use the same philosophy and i and i felt like i feel like still today that it has a lot of benefits hopefully that answers some of your questions yes so how you call it uh probably maybe data-driven development or metadata driven development i don't know we see that there is a there is a lot of use of uh data in enclosure so people create like data dsls and then write some uh interpreters enclosure closure street and this definitely reduced the size of the uh program because the part of the logic is pushed to the data land and i think that's this piece of this discussion between types and and closure because we can reduce the size of the program using the data driven development i mean beta dsl yeah i mean closure no i do i mean closure programs tend to be small and they tend to stay small i mean uh i mean i you could probably like i don't know how big typescript is or any of these other things are but i'm sure they're pretty big they're probably there the rate of growth is larger than clojurescript clojure scripts started as 500 lines of code and when i say 50 000 lines of code that's not really includes all tests that includes all the testing that we do for for um all the different environments browsers um node.js um it involves testing about build build tool testing we have a bunch of build tool functionality really in truth the the total core of the this is only about 20 000 lines of closure and we're only adding like maybe a couple hundred lines of important stuff every six months um so that's another thing that's really important can you explain it it's mystically why the closure programs are so small because it's definitely not syntax it's something different in approach how how you how we approach the program so i i saw that it can be ten times or even a couple of orders magnitude less than the similar code in java for example or even typescript or something like this but it you could not explain this just by syntax yes what the why is closure program are so small well so i mean i will say i mean something that i that's a great question the thing that i don't like about a lot of languages they often involve a lot of ceremonies so you know one of rich hickey's big criticisms about something like java and c sharp and even typescript or even javascript is that if you really continue to do like um object-oriented programming what happens is that you're going to write a class and you're going to declare your fields you're going to write getters and setters and you do a lot of bookkeeping and in the in the end what did you write you wrote a class that represents people and that thing is probably populated from a database table so you just you just wrote 200 lines of code and all it does is wrap a database object and that's the type of thing that i think closure programmers hate right why why why do i need to write a facade over a piece of data that i just got from the database i would say enclosure the reason i mean that's just 200 lines of code you never write i just write a thing that talks to postgres i get some data and i'm done i don't need to do anything else i just write some functions um and and and to be very clear like you can find people who write this style of code in javascript and python and other languages that support basic functional programming basic uh data trial programming um but the problem is is whether it's truly idiomatic in javascript and python my feeling is that is that the community around something like javascript and python and typescript they're still holding on to this class-oriented approach object-oriented approach to doing domain design and that just leads to more verbose programs and i would argue it's it's unclear as to whether those programs are less error-prone and free of bugs because you're you're literally adding more layers i think that's one of closure's true strengths is that as a community we believe that data-driven design is a first principle and that by sticking to it you can avoid a lot of these problems uh of course you know as if you're listening this you probably have lots of questions about that sounds great but how do you do things like validation how do you do things like um specification and fortunately closure and clojure script are pretty old now closure's 13 years old closure scripts coming up on a decade and we have a thing called spec so for people who are they like the data-driven design but they want more confidence about correctness there are tools that are continuing to improve that allow you to do a data-oriented approach without getting real rid of all your of your confidence about correctness and maintenance because those are important right that that i think is the critique of a data oriented approach with languages like javascript is that if you want to sort of scale it up and you want and you need to maintain the software um how can you how can you feel confident that you can make changes um and it's not going to be sort of arduous and well you know riddled with bugs i always in discussion with some statically typed guys i always ask them how the system could with the rest of the world which is always changing and there is no type notation and they could know could not share the type notation with the rest of the world and my first question how do you how do you parse json which potentially from some rest api coming from recipe which can change eventually and if you wrote all the scala or haskell or java classes and then you can get anything from the world so how you gonna deal with this and we are as the closure developers always say always expect anything but it just uh eats the json some generic data yeah the common i think yeah sorry no no go ahead okay thank you uh i guess there is a common misconception and uh misunderstanding uh about uh abstractions uh abstraction is a theme uh people tend to uh not think about the data as being abstraction by itself and when people say i need an abstraction for that and in the representation of this they always think about interfaces and code first when they come from object oriented land and that comes from the the main thing i think of data driven development is that is that uh instead of representing and simulating worlds within objects we represent not the the the things in the world directly but we represent our knowledge about these things and that is a big difference and from there you can understand that the data itself is an abstraction if you have a record which states like hashmap which states that the here's the person name here's the person address and here's the his friends and contacts and stuff like that this piece of data already is abstraction and you not necessarily need to wrap that into some code like i agree i definitely agree um yeah and you know again i don't i like personally you know i think that again my opinion is that i think one of the problems of the way that people talk about these things is that they have trade-offs like you know i think functional programmings are great if you want to use haskell or if you want to use scala or any of these things um i think it's totally fine typescript's cool um i think that you know i've been doing it long enough where you know i never worked on a you know for example like a good example examples like this like you know a lot of the stuff we have to do when we're doing closure we have to deal with java and you know a lot of times when when the java is painful like we don't care about the types right when the java is painful it's because the thing that we're using was badly designed right and that has nothing to do with types and this is something that i think that people don't talk about enough types are great because if you have a great design they give you confidence about that the fact that you made the right choices right but there's so many software projects where the types are working out but the software is unusable it's unusable nobody wants to use that thing it's too hard to use and that means that that the source of quality comes from somewhere else go ahead look alike yeah so i i think the one of the problem of type and type system that it's extremely hard to design the right type system so that's that's the real biggest problem because a classification is a is a real problem there can be multiple classifications and it's i think this it's still essence of the types that it's definitely very very hard to design the good type system and that's why most of the there's another problem which is that like here's the problem right so basically any any feature you create in a programming language will be abused it will be abused like i find it like like for a while i was dabbling in haskell and i found it very interesting because there's people in the haskell world that are like you know they're doing very fancy things with types it's very sophisticated i mean it's amazing i mean if you're if you're into that stuff it's really mind-blowing but then you like read you know simon payton jones comments simon simon simon payne jones maintains the standard the de facto standard haskell compiler the glasgow haskell compiler and he doesn't use any of that stuff as far as i can tell his his use of the types and haskell is it's like straightforward it's very clear and then i realized that like the problem with any powerful feature and this goes for closure closure also has powerful features that were abused especially in the early days macros are a good example of this we can talk about that later and i think it's really challenging to get programmers to not use things that they don't need right if you give somebody types and it's really sophisticated then they're going to over specify and right and then suddenly you're getting a different payload than you expected from a service that you can't control and your overall specification is not doing you any favors or a closure program and there's macros there's macros everywhere and now what's the point because you didn't want to use the dsl you just wanted to write functions you wanted to write data um i i would i would say that that's really something that people need to understand when it comes to a programming language choice is what is accepted what's idiomatic and what's relatively common and as an outsider haskell i can't tell you but the people that blog about it often try to do fancy type stuff when i look at the closure community i would say it's becoming more and more uncommon to see people writing about macros because macros are cool but they're not important they're not they're not critical to writing good software um i think that that's what i like about the closure community is that in closure even though there's a lot of powerful stuff the community as a whole and the libraries that you're going to use have aligned around the fact that there's a simple part of closure that you should use and most programs don't need anything more than that um and that's probably my criticism of if i had a criticism of javascript javascript you know i have to write javascript all the time still um is that again there's not much there's not much unity about what javascript is right javascript is kind of a multiverse and with all this sort of like build tools very fragmented now um as to what javascript really is do you see that uh javascript developers tend to pick these ideas uh of the database development tabs up since the did it change since the early days of uh closure script and uh how how big the the gap between what we do in closure and what we and what does the global js community particularly do in their service great point i would actually say when i compare the typical java program now like i have to do i have there are two types of integrations i have to do all the time so i'm a closure i'm a clojure script closure developer but that means i'm a java javascript developer there's no way right there's no way to do to use closure without knowing java there's no way to do clojurescript without knowing javascript and i would say it's really funny uh that i see two like java happinesses which is that often the api is extremely convoluted and it requires a lot of boilerplate to do anything effective javascript apis are often actually quite simple they're fun usually when they even if it's gnarly inside the javascript library presents a simple um interface there's only a few functions really they exchange data-oriented stuff so that's cool but there's a different pain point which is that when i use when i use javascript library when i use the java library it stinks because it's complicated but usually there's only a few dependencies and it doesn't really complicate my build story or my deployment story whereas in javascript yes i get a nice library but then i also got like 200 other dependencies that i don't care about and my build started failing so so there's you see that these two ecosystems have a very different set of values nikolai go ahead yeah so just funny story so that maybe like a half years ago i helped with some amazon startup and the guys set up the uh just empty project for the javascript node.js react stuff and it has one million of dependencies one million of dependencies oh i i don't know any other stopway which can have it was an empty project just apologize hi well i mean i just so i just want to add to that it's so funny because when i first started started doing clojurescript closurescript has a library a standard library that's 10 000 lines of code and when i started you know it was always like oh we have to compare ourselves to jquery jquery is like 35k gzipped and you know we were really struggling to be smaller than jquery that was that was our that was our benchmark we have to be competitive with jquery and and you know you you do any basic thing with javascript now and there's no way there's not 10 megabytes or more of javascript in your in your directory for for the simplicity so what's amazing is that we we continue to use actually jquery as our baseline and because we've you continue to say a trivial photogram should never be more than 25 kg zipped and it's been amazing to see javascript continue to explode in terms of the size of the basic project and um we we've we've stuck to our 2011 standard we should never be more than 25k g-zipped and it's and you know we can't control react right of course if you're going to start using react based um components you're going to have to take on the burden of of that dependency tree uh but we believe in that closure script is going to last beyond all these various fads and so one day we hope that the thing that gives us what react offers but it provides a more sensible dependency graph speaking of other value propositions of data-driven design is that when we separate our code from our data and we manipulate the very same data types like maps factors and sets and primitive stuff when we do that we actually free to perform hot reloading of that on jvm and you know both on global on javascript environment and stuff like that so maybe it's time to to to see the the how close your script actually looks like like what is it oh yeah isn't it for demo or something yeah yeah so but let's let's set it up for people who aren't familiar so um you know javascript says if javascript is dynamic and you know even though people you know there's there's no reason to use it in a normal programming java javascript because it had eval always supported this sort of like dynamic style programming and that supporting eval of course is old i mean list the list one of the earliest versions of the list um and actually back when lisp had it it was a shock because at the time um you really you know the most common way to do meta programming was to do like you know assembly and lisp demonstrated you could have run time meta programming um without being low level that you could be high level and have meta programming uh and pretty much any language that supports eval really owes it to list if it spell in a high level way what's happened though just to give set it up is that you know javascript always supported hot code reloading this is the nature of javascript but it turns out you know as andre was alluding to is that hot code reloading becomes harder in user land because that people write programs if your program is stateful if there's a lot of stateful resources if there's a lot of stateful data structures then reloading your program doesn't really work because how do you know you're going to end up in a good state um and it's quite a bit more effective in the like closure and closure script because again since the underlying application state is immutable um you're relatively and and state isn't hidden in some object or some class we're not hiding state right state has been decoupled from business logic you reload the program it just works you're you you have new functionality um and you have state and the state hasn't become corrupted uh so that's the benefit the other thing that i think is important is that um it's worth talking about the rebels so you know when you what so people like you use the javascript console but the javascript console is not really a live programming tool the way that people use the console is you write a bunch of code you run babel or you run typescript and you refresh a web page and then maybe you write you write a bunch of stuff in the developer console but you know closure comes from a list background where lisp traditionally what you would do is say i have a remote process that's running a list and i want to for my editor to connect to the remote process and then investigate the state of the program or write code in my source file and update the program on the fly that's a very basic value that list systems tend to um embrace and closure definitely does so the thing that i'm going to demo it i as a closure script developer i can be in the browser but from intellij you can use any you can use any text editor it doesn't really matter but i'm going to demo intelligent because that's what i use for work i can connect to a browser and investigate the state of the browser write new functions and keep programming and the browser is open i never have to refresh i'm just programming i can do that with node.js so in my work at value we do a lot of work in node.js for testing various other reasons and again i can run a node process i can have my editor open i can edit my source files i can reload those files and i never have to restart the state of my system the last demo i'm going to show is i can i can do react native and i don't i can i can actually have a repl connected in a react native and this is not just react native refresh i can change the ui and it won't blow away the application state whereas react makes this possible they have this thing something called fast refresh but you have to follow a bunch of rules and then close your script there's no rules to follow because again you're the way you're doing the ui programming just kind of works um but maybe before we dig in the demo is there something you know just you know i'm trying to explain this to an audience that may not have this sort of frame of reference uh maybe on are there other questions before i show that don't working maybe let's go to the demo and then we can get back and try to discuss some architecture okay so i'm gonna um so let me show let me show can you see my screen i hope so yeah okay so here i'm in intellij so i like intellij because actually um intellij has a really great plug-in by this person colin fleming it has all the things you expect um you know i can write you know i can write functions here you know this is silly i can save that but i get auto completion notice that it knows what what definitions there are whether they're private whether they're public i mean all the id stuff that you're used to uh from intellij it just works uh i can jump around right so that's the reason i use intellij is that all these sorts of things that these ide affordances are present you don't have to use intellij you can use vs code you can use vim emacs i was an emacs user for a long time i mean what i'm about to demonstrate the rebel driven stuff works anywhere but it works great uh first off i'm just going to show you can launch a node repel here um so what i've done is that here i have my source file open so this is not like what you're typically doing when you're doing node.js development here i have this open and then i can go i want to i want to load this file and here i can go i want to switch into this name this is a namespace it's an organization method for your code and i can write boo one two it's like i have a new definition i decide i want to change that definition to a multiplication i can redefine that and i can um like that and but i mean i think that you know this is not a typical javascript workflow right i'm showing you that i with the the sort of lisp approach to ripple you're always live programming you're always reloading and you're never stopping there's no i refresh something and then i try it out i'm just running the node process i write my code this is i mean if you're if you like testing this is beautiful for testing you can just be in a test file change your one test retry that test try all your tests and it's very very very interactive combine this with functional programming in the data driven design this is the type this is why people it's hard to get people to try closure enclosure scripts but the moment they try this and they get to some testing and they get to some data driven design and the rebel they never want to go back because i would i would say still to this day it does not matter what language you're talking about with the exception of other lists and maybe erlang you do not have this level of integration between the source code that you're that you're writing and the interaction model that you hear people have attempted it in javascript but as javascript has embraced es6 it's becoming harder and harder for that to work in a way that's like fun um and we've gone out of our way to make sure that this works with closure script so this is one this is one of the rebels and i'm going to close that one and i'm going to launch a different repel this is the browser repel it's going to automatically open up my preferred browser it will take a second so here i see a browser again i have a reply and i can again load that it printed hello and this is running in the browser i can go you know i can go let's switch in this namespace again i can make a definition um you know x5 right and if i go here and i go into the console is that it what is it hello sorry hello core right so this this is this is really a truly like the program is a living thing i mean this is again this is a very old idea it comes from small talk and lisp and so this is really how we work uh we want to have a live connection to the software that we're building um and it does not matter if it's in the browser it doesn't matter if it's in node.js and now i'm going to show you this is true for react native so here i have ios open this is a react native application and simulator this could be running on the device it works on the device it works for android um and i've defined a new definition so this is how this is actually running inside i've created this function called foo just like before um that's running right on the ios device i can change this definition just like i did and then i can go that just works and then this is live code like this is a state some state so i'm going to make a bit of state you know so this is some state right this is inside of the running ios application this state the value of that is crew bar now i'm going to change this to be blue and see that's not just a react refresh because nothing happened to the programming state there's that's been unchanged right so we are able to hot reload our own stuff you can edit the ui and we're never going to change this pure functional state that represents the state of your application so this is this is i'm demonstrating even though these all seem trivial these are these are exactly how i do my day-to-day work and i use all of these tools i'm programming closure script in the browser i'm programming closure script and react native and i'm programming clojurescript in node and we always have the replan we use it to write programs we use it to write tests [Music] hopefully that makes some sense i'm going to go ahead and stop this and go back to [Music] talking and maybe you all can give me some questions again thank you yeah i guess now we i guess now the the audience is convinced to at least to try to try closures could tell because the value proposition the way the way you the way you paint it is just tremendous like i used to write closure i used to write write a lot of closure but i tend to forget how how great it is yeah that's funny that mostly people who are doing like javascript is react to get that life reloading stuff they need to do some rituals i don't know do something special and with closure we get this for free just because closure program written in in that way which is compatible with the live reload and the ripple that's right so the thing you just show us it was called krell from what i know this is your the the the the last thing you've been working on lately is it some tooling for native enclosure script yes so the reason the reason my company ended up doing this uh supporting my development of this tool called krell is because so react native is now it's been around for five years and i would actually argue it's much better now than it was in the early days for a lot of reasons i mean there's more stability but auto linking really fixed one of the biggest problems about react native which would be producing a build um auto linking really just removes a major pain point but what happened was that the most popular tool in closure enclosure script was this thing called renetol which was written in coffeescript and it it controlled it controlled your integration with react native and it worked fine we built we built we built an application with it and it worked fine um but what happened was that we really wanted something a lot simpler um that allowed us to upgrade react native really and in fact a tool that doesn't know anything about react native so this tool that i built called krell it doesn't know it doesn't know anything about react native all it does is that it creates a very specific um root root view for your react application that ensures that there's a socket repo loaded and that hot hot code reloading works besides that it does not know what react native is it just provides the socket connection and the hot reloading functionality so it's a lot simpler that means we can upgrade react technique whenever we want and our tool since it it's very small um it's not a big deal it's become you know even a very short amount of time there's a good number of all users because people have been looking for a simple um around react native uh there are others don't get me wrong there are alternatives there's a thing called shadow which actually provides a really great experience there's another tool called fig wheel which i think is enhancing their react native experience but the point here is actually that there's actually a bunch of great simple tools all three of them in in the closure script world all three of these tools are geared around providing hot code reloading that's zero configuration when i say zero configuration um you know when you look at what it what you have to do for hot code reloading for um uh javascript you should be scared sorry yeah just share this screen real quick um this is this is the total confusion for the demo that i showed that's specific to clojurescript this is it this says that there's my main entry point is this file which you were looking at i generate a thing and there's output directory there's no other messing around there's no laner specific changes there's really nothing at all about hot code reloading there's nothing that you have to remember no special cases it just works and i think that's really huge when you look at the state of hot code reloading in javascript um generally there's a lot of caveats and enclosure script it does not matter tool you use really these days especially in the past again the past five six months uh they're all this bored the fun fact you didn't mention is that closuresclip detector is actually bootstrapped from like five years ago or so i guess so what you did manage to do is that you just you are able to compile close your script uh in closure script itself so you can write program that compiles closure script inside the browser or any other javascript runtime and uh i guess it even it is even possible to compile clojure street by closure script itself yeah that's an old that's all that's pretty old years ago now i think it was 2015. uh so you know when when closure first came out um you had to run closure you have to generally people run closure to run close your script you run closure closure runs close your script and you get you get the thing that you want in fact all the demos that i'm showing it's clojure script being run by closure but we do offer this thing called bootstrap which again is not the main way because um to include the compiler into the runtime it's actually fairly large gzipped it's 300k i mean five years ago i was like that's really big so with your average react application that it's not very big but that leads us but sorry go ahead go ahead andre go ahead so sorry yeah so all i was going to say is that we offer it you you can you can you can bootstrap closure script closure script can compile itself then you can use it inside the browser you can use it to make like you know sketch notebooks and you can use it to make interactive um like guides like a lot of people are building tools for beginners i mean and if we want to make a replica on like a long outstanding to do we want to make a closer script level for the clonerscript website so there's all these use cases which um bootstrap lets us do it's still not the main thing and it's unlikely to be the main thing because again um we believe that our sort of stance that played clojure script should be practical it should never be bigger than jquery that's something we've stuck by but we offer it for people this bootstrapping feature for people who want to do something different or that requires a different approach go ahead anyway you can com you can compile the closure script uh with closure script not with uh not with the enclosure and that leads me to another like uh a tricky question uh what do you think could clojure script uh after uh in in some future and make a better closure like given the fact that uh clojure script is written in in claudio script uh and uh that uh it eliminates some features of clojure like dynamic virus and namespaces and these things together can possibly lead to more lean closure run time and uh the the compiler you have can be universal can be used for compiling to jvm byte code and that would possibly lead to other targets like native or web assembly and stuff like that did you thought about this development of clojure like is it possible that closure will become the better closure let's see oh it's it's it's it's pot go ahead and nikolai maybe you have another thing to add go ahead yeah and that just some addition to this question because now we have a node gps time and if we were thinking about the closure script in a browser or on a mobile device yes we had this limitation we want to reduce the size and sacrifice some dynamic nature but now we have a node.js runtime and if we target in the closure script with the node.js i mean node.js runtime the things can change so maybe you know about the project like machiato and stuff like this and you said you're using node.js on the backend so yeah that's all no so there's there's a couple efforts there's there's a thing called lumo which is a bootstrap thing it's not super active but it does work it lets you run close your script programs directly in node and you don't need you don't need to use anything else and people are using it for stuff and it's very cool so you don't need the jvm with lumo uh there's another really cool thing called plock plock uses um apple's javascript core which compiles on all major operating systems windows linux and os 10 is a self-contained um thing where it uses javascript core it has the entire closure script runtime embedded in it so if you want to do shell scripting with clojurescript clock is another good option um but but it's tricky because the thing is the world is continuing to move and like one of the most interesting things in the jvm namespace is graul actually you know graul actually opened up a ton of doors you could do native binaries you could do a lot of interesting things with grawl that weren't possible before on the jvm so there are options now um to create small executables closure programs that start instantly um so i expect the jvm to continue innovating there and you know small executable and fast start off time is your primary concern there's already tools for that back to andre's question though i think a really great one which is that i think i've demoed that you know we've got we can do browser we can do node we can do react native and actually we're available on the jvm and the clr but of course there's other interesting targets you have things like art i mean also you have you know dino is just javascript but there's also dino maybe there's some things we would do there wasm is of course a thing we want to act on many times but it's just a matter of like time you know the time to work on that um i mean the cool thing about closure and closures they are pretty simple languages and um i suspect that if you're looking to do like target other things there's without a doubt that clojurescript is the easier place to get started um i don't think you know with closure there's enough users there's enough install base and the development cycle is pretty you know pretty slow um and it's in its titan to be honest it's tightly it's tightly managed by rich hickey which is totally his prerogative um if you're looking to target other things then clojurescript is a great starting point you know it's actually something that i want to see i i've been actually pretty curious about dart for example because i think flutter is pretty interesting it's another interesting way to target a lot of different uh environments whether that's desktop or browser or mobile with like a lot less like ecosystem complexity than javascript and i would love to see people uh tease apart the javascript parts from clojurescript so that it's easier to reuse a closure script in that way to hit other targets so so my answer is yeah a big yes closure script is actually a great way to get closure um in other places uh tangentially related i mean one thing that's really interesting but we've seen very little action on is um multi-threading you know that's one of the big differences between closure script and closure is that we don't support multi-threading because the javascript runtime does spreading but if you think about it actually closurescript has such an amazing discipline around immutability that we would be able to provide if javascript provides multi-threading and we don't care like if they if they just had locks and atomics we'd be like we'd be done we could have a fully multi-threaded reasonably safe run time uh where multi-threaded programming would be just as straightforward as an enclosure and you wouldn't have all the traditional jvm problems and it would be that would be just phenomenal so uh you know we're ready to go there if javascript goes there um so there's there's if you're taught i like if you were talking about how much untapped potential there is for a closure script i think it's huge and in a way that i think in the end because javascript has continued to embrace like sort of like traditional programming demands now you can do it you could do multi-threaded programming in it but it's not something to be excited about i think that it would be funny to compile close your script into jvm byte code because uh from my uh my experience of working with clojure closure compiler which is the closurelang compiler.java that is a file of 10 000 lines of code with just of java which just does the compilation the famous one with the huge blobs of commented out experiments and stuff like that from what i know the closure speed compiler is built with the culture uh library called analyzer which is uh which provides much more comprehensible and easier to hack classes of the compiler uh and stuff like that i think it does make sense to compile uh gorgeous grid into jvm and uh just start experimenting in better way because uh that would possibly lead us to aggressive code code elimination we should do on the browser we can do that in jvm we can get an instantaneous startup time compared to the old collegial implementation and stuff like that yep so maybe we are getting too technical for our auditory so let's uh we have not so much time so maybe uh uh david you you have a good feeling of something interesting in the future so can you share with us some trends you see in front-end development of mobile development which which you think is very interesting and you should put attention yeah i mean it's so um i mean i think the main thing i think you know the the javascript world the pendulum tends to swing back and forth and often often skipping like that maybe there's a better answer or um we could do it differently and we don't have to swing we can just actually take the thing we have we can make it better i mean so one of the things i like i mean there are two things some of these things are not actually not even like have nothing to do with technology it's completely just social behavior but something that i think that needs to happen in javascript because javascript is great i mean it's very i mean when i say it's great i mean the number of affordances that are available to javascript programs is fantastic i mean any problem you want to solve is a javascript library for it and that is good um but i think there is there like a social thing which is a purely social programming thing is um you know hoping that uh people begin to revisit their dependencies and when they build a thing i think it wouldn't be strange for somebody to start a new set of libraries that says we take on no dependencies and a new root a new route where the dependency graph is very is very shallow and then people can start building um stuff based off very shallow dependency graphs like that's a very easy thing to do because it has nothing to do with technology it's just behavior the other thing that es6 lets us do and i and it's like roll up sort of started it roll up uses imports and exports the fact you have static import and export even though people keep wanting dynamic imports which i'm like it's not that important it has it's not really not that important with with static import and export then you're able to consume a very large library right that library can be large think about this shallow dependency graph because you don't want it but then you also might have a bigger library it's es6 you use es6 export import and now webpack or rollup can deadcode eliminate all the functionality in the large library they're using that you didn't actually import right that's a very simple uh basic thing that i think needs to be done right the the people complain about react but has nothing to do with react i mean it really has nothing to do with react this is just a javascript problem uh if you fixed it um again by with a little bit of technology and a bit of social like social programming behavior um you could get all the benefits that people want without these react without these ridiculous payloads um i think that that is actually a very important interesting way to pursue and i think in the end uh would solve most of the sort of like bloat that you're seeing uh in this space uh that and of course this idea that i'm that i'm talking about it's not new we use clojurescript uses google closure well which uses deadcode elimination and it's been great and that's how that's how we can generate i think clojurescript the smallest closurescript application generates like 7580 maybe 90 000 lines of javascript um in the end we get a 25k gzip thing but that's because dead code elimination it works and it definitely works when we want to use large libraries and we need to eliminate something that's only true for sure but we use a lot of stuff from google closure whether that's internationalization or currency formatting there's all this stuff date formatting all this stuff you know think about moment.js it's so big once you bring in internationalization and the fact that google closure gives us internationalization but we get detonation we only get the pieces of internationalization that we need um we don't have that problem that javascript programs tend to have so i think that this is one of the biggest areas um javascript has clearly succeeded but i think there are things that could be done to make it uh better for everybody and of course it would make it better for us because we integrate with via bundlers like webpack so if javascript solves that problem it solves that problem for us too so we're definitely interested in that um but i think i'll leave it there i think i think hopefully that at least says some of the things that i would like to see happen which again it's not even framework things it's just write simpler programs have simpler dependencies and write better tools for dead code elimination and write libraries that support dead code elimination so thank you david so maybe some yeah some light questions i don't know do you have any books which professional life like just couple of them books i mean books i mean i mean the thing is i'm a big programming languages nerd so most of the books i like are not that practical right like um you know if you're like interested in in learning more about lisp and uh you know i i would say i would say i would say you know the structure interpretation of computer programs is quite it's quite good um sometimes people yeah structure interpretation computer programs i think if you have a little bit of a of a good math background and you're not afraid of math then um that might if whatever you think about programming that that book will just tear all your ideas about programming down and rebuild it so if there's one book and you're not afraid of a little bit of math book to read and you'll be like okay list i gotta try it uh other books paradigms of artificial intelligence programming so you know when i'm looking for a great book about data driven design and thinking about data program paradigms of artificial intelligence programming by peter norvig it's one of the greatest books about how you can write data to drive the program also a list book but you don't have to like list like you you can read that book and not care well i would say that it will change the way you write programs okay so yeah i thought that you haven't finished yet so we had i thought that we had a little bit more time but unfortunately we had to wrap up thank you very much uh for your david thank you very much for your in thoughtful answers thank you very much so there is a link to zoom below our experts so somewhere somewhere there uh please join us i hope that yeah somewhere there exactly exactly so thank you andre andrew and nikolai for your good questions you did a great job so see everybody in zoom later thank you very much

Channel: HolyJS

Views: 618

Rating: 5 out of 5

Keywords: javascript, holyjs

Id: yycOfcYpSVU

Length: 74min 0sec (4440 seconds)

Published: Tue Dec 08 2020