Clojure Gazette 1.62
Dynamic, changes, niceness
Clojure Gazette
Issue 1.62
December 14, 2013 ==============================
Editorial
Hello, Clojurfarians!
This week was kind of busy for me. Lots of travel. Please excuse the short issue. As always, this is a personal endeavor, totally unpaid, and I'm thankful that anyone at all is reading.
I am experimenting with the format again. At first, I was very focused on a philosophical style of issue. Then I moved to simply linking to cool stuff. Now I want to focus on quality. Of course, it's an ongoing process, but that's what makes it interesting!
Enjoy!
Sincerely,
Eric Normand
P.S. I love hearing from readers. Just reply to this email!
P.P.S. My videos are still available!
The Library to Watch
om
David Nolen has been experimenting with a ClojureScript wrapper library to the React JS library. It's still very early, but already exciting. By taking advantage of persistent data structures, several great optimizations are possible. I mentioned last week that the immutability of Clojure's data structures allows a very fast comparison (pointer equality) in the common case. That saves you from re-rendering and re-checking the virtual DOM. But there is a further optimization: because of the structural sharing between modified versions of a data structure, it is very cheap to save the entire history of the state. This means unlimited undo is trivial.
Keep an eye on this repo. It already has 20 watchers and could be the final piece in the ClojureScript frontend puzzle.
The Developer to Watch
Alex Miller
If there's anyone influential in the Clojure community, it's Alex. He runs three exciting conferences (Clojure/West, Lambda Jam, and Strange Loop). At Cognitect, he is addressing Clojure issues on Jira like nobody's business. On top of it all, he's a super nice guy. I was amazed to see him duri ng the three conferences hanging out, having conversations, and riding the wave of chaos. I would have been stressed out of my mind. Keep an eye on him!
Language hacking
Fast and Dynamic
Maxime Chevalier-Boisvert talks about some interesting dynamic optimizations. These things interest me. It's easy to define semantics that are very fast for the computer to run. It is harder to find fast semantics that are also convenient for the programmer (read: create fewer bugs). The common wisdom is that convenient languages are necessarily slow. But Javascript proves that wrong. Time and time again, information about the actual runtime behavior of the program can be used to dynamically speed up a running program. This tendency gives me hope that while designing languages we can focus more on the programmer and less on how efficiently programs in the language run. Methods will be developed to make them more efficient later.