I'm about a month late on this, but this morning I just watched the video of David Nolan's "Now What?" talk from the EuroClojure 2016 conference. I've been working a lot with classic JavaScript and also TypeScript recently, but he really got me excited again about ClojureScript, React, and functional programming. Definitely watch the video for yourself, but just for your own information I've distilled what I think are the key takeaways below.
Immutable, Persistant Data Structures Is Huge
The beauty of Clojure is that is was built on the simple, focused philosophy of immutable, persistent data structures. It's all about immutable data structures, those that cannot be changed once given a value. This may seem counterintuitive at first, but it works in the same way a Redux store works- you copy the data structure, make a change to the new one, and set the new one as the new value for the original. This sounds computationally expensive on the surface (what if our data structure is a huge array of more arrays? You're copying that whole thing on every change??), and that's where the persistency comes in. Persistent data structures means that the copies all share the same underlying data, and the new one is really just the old one plus some slight modification. I like to think of it as similar to how git versioning works where it doesn't save your whole project on every version but instead saves a series of diffs. These data structures are awesome, and they are often not available in OOP languages like JavaScript and Java. This is fundamentally what people love so much about Clojure, and you should use it and love it too. :)
The Redux Philosophy Is The King of State Management
It's awesome that David Nolan compares the idiomatic ClojureScript state management that uses regular immutable data structures with the "Redux" philosophy from the domain of other programming languages. Of course it originally started in React and continues to be pretty much the most popular Flux implementation. He also notes that Redux actually was inspired by the Elm language's state management system, which is also built on immutable, persistent data structures! Even in OOP Angular land I've been using Redux (more specifically, ngrx/store). Although Redux does have a learning curve to it and may seem overly complex to beginners, I'm seeing more and more top developers in across almost all front-end languages gravitating towards Redux-esque patterns and libraries. The key is the Redux flow of data and the immutable, persistent data structures!
ClojureScript Is A Mature, Conservative Technology
David Nolan tries to address the common argument against using ClojureScript in the workplace that it is too risky. He notes that ClojureScript is actually 5+ years old, it's actively being worked on, and it's not going anywhere. People who like Clojure love Clojure, and the tough part is really just getting over the initial "omg, that's weird!" speedbump right in the beginning. The thing is that some people just don't want to learn new technologies. They don't want to learn Clojure and just want to stay in their comfort zones. Of course I'm not like that, but sometimes you need to be a team player and don't have the luxury of telling people to either get with it or get out. At the same time, how do you find skilled ClojureScript devs? It's a catch 22 that's getting better, and I think the key is to try to just surround yourself by other people who love what you love, whether it's ClojureScript, TypeScript, React, or Angular.
Clojure.Spec Could Be Ultimate Balance of Dynamic Typing And Specification
I have read the docs and watched a few videos about Clojure.spec, but to be honest I have not yet gotten the chance to really play around with it and use it in a legit project. However, I think the idea of it is awesome. Clojure is pretty much the ultimate programming language in terms of conciseness and simplicity. However, some people bash Clojure because it is a dynamically typed language. This untyped nature can make refactoring large applications difficult, can make it harder for tooling and IDE's to guess what you mean, and can lead to some derpy issues where you want to call a function but need to stop and go research what arguments it actually takes! Most languages just take the cop-out solution and throw type annotations into the code. In the talk David says, "Types is really just a way to communicate 'What does this program mean and what does it do?'". Clojure.spec keeps the fantastic idiomatic lispy syntax we know and love while at the same time providing the benefits of static typing, Wow! Not only that, but Clojure.spec also has a features that allow you to basically do unit testing, and it can even generate example data to pass into your functions to exercise them, I'm very excited to start using this in Clojure, and I'm interested to see if something like this gets ported to other dynamic programming languages (cough cough, JavaScript).
Help Out On The Website
He ends by saying that anyone can help out with ClojureScript and contribute on Github, and he mentions that one great way to do this is by helping out on the website clojurescript.org. I'm definitely going to see if I can dig into this codebase (I'm assuming it's in ClojureScript) and see if I can add something useful. I definitely want to get more involved in the ClojureScript community. Especially since I'm based in NYC and David Nolan lives in Brooklyn, I'm hoping that the New York ClojureScript community will get stronger and stronger. Go Clojure!
RSS Feed