For a while I considered the possibility of attending Clojure/West 2016, but frankly I’d grown tired of technical conferences. At one point in my life I loved every moment of every conference that I’d ever attended, but over time I’ve grown tired of the whole experience. First, I’m quite shy by nature and have never felt terribly comfortable putting myself out there and engaging in the typical hallway and post-conference festival of affectations. I’ve always felt more at home with a small gathering of friends and so I didn’t really consider going to the conference this year. However, I’d never visited Seattle before, so I decided that I would take a few days to go with my family and explore the city during the after-conference hours. This exploration of that beautiful city was spectacular, but it was during the conference hours that I found myself pleasantly surprised.
The first talk of the conference was “Specter: Powerful and Simple Data Structure Manipulation” by Nathan Marz. Specter is a library that provides fast path-based data access and transformation utilities. I’ve not had the privilege to dig deep into it, but it seems like an impressive piece of engineering. That is, while the basic concept takes 40 lines of code to implement, the real challenge is making the concept fast, which Nathan was able to do. I can’t wait to really try it out. That said, I want to make a quick point. The library is billed as “Clojure’s missing feature” and numerous times in conversation with others the point was made that they’d love to see Specter integrated into Clojure’s core. While I can see the justification for this sentiment, one of the reasons that we use a Lisp is that we don’t need Specter in core — it works perfectly well as a library. Indeed, the beauty of Lisp is such that libraries are fully privileged with regard to any other language construct (save for special forms), including those found in the core. Therefore, my rebuttal is that Lisp in general and Clojure in particular enables the perspective: more libraries / less core.
Every conference needs at least one case-study and “Managing One of the World’s Largest Clojure Code Bases” by Donevan Dolby was a pretty good one. He discussed some of the sticking points around managing a large codebase (~16K LoC) all of which are true and real and I encourage you to watch the video for the precise details. The most interesting part of the talk for me however was the mention that Clojure is on Boeing’s list of approved languages. That was a nice surprise.
One of my favorite talks of the conference was “Creating DSLs – A tale of spec-tacular success and failure” by Claire Alvis. In the presentation Claire talks about a library named spec-tacular that she and her company SparkFund created that adds some static and run-time guarantees to their Datomic database access via some hardcore macrology. The most interesting thing about the talk was that Claire took time to define the characteristics of a good Clojure (though the criteria applies generally) library and then graded spec-tacular against them. Some characteristics were successfully met while others were not, but the real take-away from the talk was that she’s clearly thought long and hard about this topic and even still her library only partially meets the criteria. This really drives home the fact that while we may have idealized models of “good software” the realities of production needs often impinge on them in unexpected ways due to very real trade-offs. I traditionally despise “library talks” because they very seldom discuss the trade-offs involved in the development and use of said library, but Claire’s was a breath of fresh air. Spec-tacular is not an idealized library, but it solves a very real problem for SparkFund in a very specific way and Claire did a masterful job of highlighting the trade-offs inherent in its construction.
After lunch I attended a Cognitect Q&A in the anticipation that I might have something to contribute (I was wrong). There were a lot of good discussion around the practical use of Datomic and if you’re interested in using it then it’s a good video to check out.
“ClojureBridge in Practice” by Katherine Fellows and Anna Pawlicka was the first talk in a series of similarly themed talks around community growth and diversification. Let’s be honest, the diversity numbers in the Clojure community are not great. I hesitate to posit why this is the case, but I can say that there are many people1 putting a lot of effort into diversifying the current stark homogenous makeup of the community. There’s still a lot of work to do to build a community that can foster the creativity of people of varying perspectives, but things are better than they’ve ever been and look to continue along a positive trajectory. This is a great thing. Both Alex Miller and Lynn Grogan, the organizers of the conference, have worked tirelessly to ensure a wider representation of people across all demographics, including people with very diverse backgrounds, both cultural and professional. ClojureBridge is an amazing effort and absolutely an essential part of the Clojure ecosystem.
Speaking of which, another of my favorite talks of the conference was “Deepen and Diversify the Clojure Community with Jr Engineers” by Amie Kuttruff. In the talk she told anecdotes about her experience as a “junior engineer” and her growth as a Clojure programmer fostered by thoughtful mentorship. She made a fantastic point about the fact that very often what makes learning so difficult is that people come to a new topic without even a basic context needed to begin exploration. I can only speak for myself when I say that I sometimes forget what it was like to not know how to program. But looking back on the beginning, there were many times when I knew so little about the topic that I didn’t have the basic contextual vocabulary2 to even formulate questions. This is a bootstrapping problem that’s particularly pernicious in programming because from the outside it seems incredibly difficult and ponderously mathematical and appears to move fast and on top of all of that is collectively impatient (or downright repellent to) with people from non-technical backgrounds. This is incredibly intimidating. It takes patient and thoughtful mentorship to effectively guide people to become not only effective learners but also invaluable members of a programming community and workplace. There are many people in the world who’re drawn to programming for any number of personal reasons and we as a programming community would do well to tap into that interest to help grow and enable others to benefit, and benefit from, our industry.
The final talk of Day 1 was an entertaining and insightful talk by Stuart Sierra called “The Joys and Perils of Interactive Development.” It was an interesting juxtaposition with the prior talks because it was effectively a culmination scenario. In other words, Stuart described some of the ways that Clojure programmers trip themselves on a workaday basis. Congratulations, you’ve learned to program and found a Clojure job and now here’s a tool that will help you to shoot yourself in the foot on a daily basis. But it’s not all gloom and doom because Stuart’s been thinking about these problems for a long time and has created tools to help alleviate Clojure peril.
The second day started with a bang thanks to a talk titled “Web Development is Distributed Systems Programming” by Mikaela Patella. The basic premise was this: there is no longer “web programming, there is only distributed systems programming.” In my experience this is exactly right, all caveats acknowledged. I hate to summarize the talk so tersely because I’d hate for you to miss out on the delivery and style of the talk yourselves. Mikaela was cool AF.
Speaking of cool AF, the talk “From Fluxus to Functional: A Journey Through Interactive Art” by Allison Carter was probably my favorite of the conference. Indeed, my friend and amazing artist Michael Parenteau and I sat in the back awestruck by the talk. Allison gave a very nice multimedia presentation that at the end had me dying for more and ready to run out and explore creating drones with Overtone and/or Sonic Pi.
My friend Ghadi Shayban gave a sweet talk on “Parsing Text with a Virtual Machine” describing his pex parsing library. I’m still trying to wrap my head around the talk, but the approach in pex is a mixture of PEGs with a stack machine — two great tastes that go great together.
Finally, the keynote was given by the always entertaining and eminent Matthias Felleisen. There was so much to unpack in this talk, but I’ll try to do my best in a few sentences. First, Dr. Felleisen is a pioneer in the Scheme programming language space having authored or co-authored many seminal papers on the topic. Additionally, he’s also a pioneer in language type systems. However, unlike many researchers that I’ve encountered, Dr. Felleisen’s research is rooted in solving real problems. That is, for a large portion of his career he wrote a literal mountain of untyped Scheme code, but over time he began to realize that type systems could have helped him gain a large measure of certainty and rigor all along. However, the mountain still existed and wasn’t likely to go anywhere anytime soon. Therefore, the bulk of his research and the implementations thereof centered around the premise:
Imagine you have a mountain of untyped code and now want to apply types to it.
The talk therefore was about this viewpoint. There was no proselytization in his keynote, it was just a story and a punchline (or two maybe) and I urge you to check it out.
Clojure/West has reinvigorated my interest in attending technical conferences and the 2016 show was well worth the cost of admission. Rather than a mass display of posturing, Clojure/West felt like a gathering of friends. This is a feeling that I’ve not gotten from a conference in a long time and I already miss it. I love the way that the Clojure community is growing and embracing this growth and I look forward to see what happens next.
See you next year. :F
People including, but certainly not limited to: The two speakers Katherine Fellows and Anna Pawlicka, other ClojureBridge organizers and supporters like Yoko Harada, Bhaskar Mookerji, David Chambers, and Malwine Gier, sponsors and organizers of the LGBTQIA Lunch and Lambda Ladies Dinner, and of course those in the Clojure community who have supported these efforts. ↩
Amie Kuttruff’s talk has really gotten me thinking about how to help people establish a basic context around programming. Things like ClojureBridge absolutely help, but there is a need to address even before that point. How can someone help others to understand even the most basic things like how to even start learning to program, or what roles exist in the workplace and what they do, or something even more basic like what it even means to program a computer. Helping people to build a context by answering their questions and building a vocabulary would be incredibly useful. Interestingly enough, I’m not even sure how to get started addressing this need. ↩