October 09, 2014
Steve Miner's talk at the conj is about automatically creating test.check generators from a data-driven schema.
Background
Steve Miner is the author of the Herbert schema library. In Herbert, schemas are presented as plain EDN. They describe the structure and type of data. You can take a value and validate that it conforms to the schema. He is going to present a way to generate test.check generators from the schema. This way, you can do runtime checks and test-time checks. A good intro to Herbert is Steve Miner's lightning talk from Clojure/conj last year. Reid Draper gave a talk about test.check at Clojure/West.
Why it matters
test.check contains a set of combinators to create new generators from existing generators. But combinators are not very easy to read or write when the data they are generating is fairly complex. Being able to generate them automatically from a declarative, data-driven style is one way to make it easier.
Besides being easier, it also unifies the contracts (schema validation in function preconditions) with generative testing. The next domino would have to be building core.typed type signatures from the same data.
Github - Twitter
This post is one of a series called Pre-conj Prep, which originally was published by email. It's all about getting ready for the upcoming Clojure/conj, organized by Cognitect. Conferences are ongoing conversations and explorations. Speakers discuss trends, best practices, and the future by drawing on the rich context built up in past conferences and other media.
That rich context is what Pre-conj Prep is about. I want to enhance everyone's experience at the conj by surfacing that context. With just a little homework, we can be better prepared to understand and enjoy the talks and the hallway conversations, as well as the beautiful venue and city of Washington, DC.
Clojure/conj is a conference organized and hosted by Cognitect. This information is in no way official. It is not sponsored by nor affiliated with Clojure/conj or Cognitect. It is simply me curating and organizing public information about the conference.
You might also like
October 10, 2014
Steven Yi's talk at the conj is about music systems on the JVM, focusing on two systems he built, called Pink and Score.
Background
Pink is a library for signal generation and processing and event handling. It is designed as a low-level library to use to build your own audio system. It is written in Clojure.
Score is a library for composing musical scores. Those scores are generic, so that they can be played by a variety of backend systems. Score is written in Clojure.
Why it matters
Electronic music is an interesting field. It is one that Lisp has been applied to for many years. To paraphrase Sam Aaron, creator of Overtone, Clojure's high-level allows a programmer to leverage programming ability to create better music. Pink and Score join Overtone and Rich Hickey's Harmonikit as music systems developed in Clojure.
Github - Twitter - Blog
Steven Yi is the author of the Blue Integrated Music Environment. He is also a core developer of Csound.
This post is one of a series called Pre-conj Prep, which originally was published by email. It's all about getting ready for the upcoming Clojure/conj, organized by Cognitect. Conferences are ongoing conversations and explorations. Speakers discuss trends, best practices, and the future by drawing on the rich context built up in past conferences and other media.
That rich context is what Pre-conj Prep is about. I want to enhance everyone's experience at the conj by surfacing that context. With just a little homework, we can be better prepared to understand and enjoy the talks and the hallway conversations, as well as the beautiful venue and city of Washington, DC.
Clojure/conj is a conference organized and hosted by Cognitect. This information is in no way official. It is not sponsored by nor affiliated with Clojure/conj or Cognitect. It is simply me curating and organizing public information about the conference.
You might also like
October 12, 2014
Zach Oakes' talk at the conj is about making games in a dynamic programming environment.
Background
Clojure, and Lisps in general, are famous for dynamic programming. That means being able to modify the program as it is running without restarting it. Wouldn't it be nice to develop games in this way? It seems like the perfect fit, since video games are so visual, you'd want to see what your code changes look like very quickly. This talk will explore this. Nightmod is a development environment written by Zach Oakes to modify a game in one window while it is running in another. It is based on the play-clj library, which he also wrote.
Why it matters
Game programming is a huge industry dominated by static languages with long code-compile-run cycles. Games cost millions of dollars to make, so even small improvements in developer productivity can save lots of money.
But further, games are hugely complex systems that are often on the cutting edge of programming. Functional programming has a lot to say about complex systems, yet there has not been a lot of functional programming in commercial games. The domain is ripe for exploration and discovery.
Github
You can support Zach Oakes at Gratipay.
This post is one of a series called Pre-conj Prep, which originally was published by email. It's all about getting ready for the upcoming Clojure/conj, organized by Cognitect. Conferences are ongoing conversations and explorations. Speakers discuss trends, best practices, and the future by drawing on the rich context built up in past conferences and other media.
That rich context is what Pre-conj Prep is about. I want to enhance everyone's experience at the conj by surfacing that context. With just a little homework, we can be better prepared to understand and enjoy the talks and the hallway conversations, as well as the beautiful venue and city of Washington, DC.
Clojure/conj is a conference organized and hosted by Cognitect. This information is in no way official. It is not sponsored by nor affiliated with Clojure/conj or Cognitect. It is simply me curating and organizing public information about the conference.
You might also like
October 13, 2014
Zach Tellman's talk at the conj is about building composable software.
Background
People often boast of the composability of Clojure programs. Compojure claims that it "allows web application to be composed of small, independent parts." Ring itself is based on composing middleware and handlers to build a web server. In fact, you can compose pieces easily with Ring, if those pieces were designed to compose with Ring. But not all libraries compose well with the Ring ecosystem. This talk asks "How can we design libraries that compose well in general?" A good intro to composition in Clojure is Rich Hickey's talk Design, Composition, and Performance.
Why it matters
I often get asked why a certain library in Clojure doesn't have an easy interface like the one in Ruby. The answer, in many cases, is that the Clojure library was designed to compose with other code, while the Ruby library was meant for programmer convenience.
But if I leave it at that, this answer is unsatisfactory. Behind my answer is years of experience telling me that composition beats convenience in the long run. The asker of that question does not have that experience. I would love to have a way to explain why in an analytical way.
If this talk even so much as opens the conversation up about the design space of composition, it would be extremely helpful. But I'm expecting more from Zach Tellman. His talk could have a profound impact similar to Rich Hickey's talks on immutable values and simplicity.
Github - Twitter
This post is one of a series called Pre-conj Prep, which originally was published by email. It's all about getting ready for the upcoming Clojure/conj, organized by Cognitect. Conferences are ongoing conversations and explorations. Speakers discuss trends, best practices, and the future by drawing on the rich context built up in past conferences and other media.
That rich context is what Pre-conj Prep is about. I want to enhance everyone's experience at the conj by surfacing that context. With just a little homework, we can be better prepared to understand and enjoy the talks and the hallway conversations, as well as the beautiful venue and city of Washington, DC.
Clojure/conj is a conference organized and hosted by Cognitect. This information is in no way official. It is not sponsored by nor affiliated with Clojure/conj or Cognitect. It is simply me curating and organizing public information about the conference.
You might also like
April 03, 2015
Introduction
Alan Dipert and Micha Niskin generously agreed to do an interview about their talk at Clojure/West. The background to their talk is available, if you like.
Interview
LispCast: How did you get into Clojure?
Micha Niskin: I watched the SICP lectures from MIT and was blown away by the simplicity of Lisp. At the time I was programming in Perl, C, and Java, mostly (I was actually on a programming hiatus building boats in Maine, but you know, you never just stop programming). So I started doing some things in Scheme (Racket) and I really enjoyed it. I was learning awesome new things at a rate I'd never experienced before. Then Alan recommended I try Clojure. I was initially skeptical of the syntax, but persistent collections were a real revelation and I quickly joined the cult.
Alan Dipert: When I learned about arrays in Visual Basic 4, someone told me that some language "LISP" was somehow made out of arrays, which I giggled at because it sounded so silly. Later, in college, my coolest professor challenged my Java class to complete assignments in alternate JVM languages. I took the opportunity to learn some Scala, and for the final assignment, Clojure. Clojure blew my mind - what didn't immediately click was somehow very obviously something I would need to learn and would unlock more awesome things. The Clojure, and the learning, haven't stopped since then.
LC: Last year you all released Hoplon. Everyone else was zigging toward React, while you zagged to a completely different paradigm. I can't help but see a parallel with Boot. Nearly all Clojure projects use Leiningen, and here you are zagging again. I think you've explained why already. What I want to know is the thinking that leads to two very zaggy approaches. Were the existing libraries not scratching your itches? Or do you have a deep desire to develop your own tools from scratch?
AD: Hoplon is a packaging of a vision we have for how to write and maintain Single Page Applications (SPAs). We had been developing this vision for about two years before Hoplon's release, and were driven to see the vision through because we needed practical tools for professional use and found nothing that existed to be suitable.
In the first year (2012) of pre-Hoplon exploration, it became clear we needed to either find or develop a model for state that could work in a browser. Of the technologies we evaluated, we explored FRP most thoroughly 1. We built a series of applications in ClojureScript using Flapjax 2.
Our experience with Flapjax informed our opinion that of the units of composition in FRP - behaviors and event streams - only behaviors are necessary for driving browser UIs. This is because UIs are views into memory/data, not into processes. For anything to appear in a UI, it must first appear in memory somewhere. We think behaviors, which are conceptually similar to cells in a spreadsheet, are the ultimate tool for coordinating change in data (NOT process) over time. We think core.async is probably the ultimate tool for coordinating process (NOT data) over time. FRP in its various formulations tries to do both, and not in a way that we find especially helpful.
We codified these opinions in early 2013 into Javelin 3, a ClojureScript library for modeling data in SPA UIs. What Javelin didn't solve -- or even imply -- was how to actually display the data being modeled.
If a UI is really just a stylized view into the heap, then any data structure is a kind of UI. If Lisp is the ultimate way to compose and manipulate data structures, then it must also be the ultimate way to compose and manipulate UIs. This is the thinking behind the second big piece of Hoplon, "the HLisp semantics", our answer to the question of display that Javelin leaves totally open. We worked on and around this concept in the 2nd year of pre-Hoplon (2013).
Concretely, HLisp is a set of semantics 5 that map HTML markup into the Lisp evaluation model. That is, the HTML expression <ul><li>one</li></ul> is identical to the ClojureScript expression (ul (li "one")). Both evaluate to a live Node object in heap that can be passed to and returned from functions. Under HLisp, a list might be constructed like this: (apply ul (map li ["one" "two" "three"])). Because these expressions evaluate to native browser objects, they can compose with a vast array of plugins and libraries available in the frontend ecosystem.
A big positive of HLisp is that HTML becomes a syntax for a subset of ClojureScript. We find this especially beneficial because it means any designer or UX expert familiar with HTML can easily contribute. We've never worked on a team that didn't include at least one designer/UX expert, and we believe this demographic is totally underserved by existing tools. Part of our vision is to empower designers to experience the same level of "flow" that we Lispers know comes with simple, clear models that we can infinitely extend.
Realizing fully HLisp pushed the limits of every build tool we tried to make it work in, because it was different than what anyone had ever wanted to do before. It was clear to us that the kind of transformation HLisp required needed to be accessible, and we began to imagine how a build system capable of these kinds of things could work. We dreamed of compiling Markdown, into HAML, into HTML, into ClojureScript, into JavaScript, reliably, simply, and accessibly.
We developed Boot1 to serve these needs, and shipped Hoplon atop it last year. We haven't had much reason to change Javelin, HLisp, or Hoplon over the past couple years, but we have rolled the set of ideas for improvement accumulated over a year of Boot1 use into the nascent Boot2. Today, Boot2 is capable of the Markdown -> JavaScript transformation and much more. We are really happy and excited that it is drawing enthusiasm from Clojure and ClojureScript users outside of Hoplon-world.
To finally answer your question: It's not that we think being different or building our own tools are virtues; we're just lucky to have had a series of opportunities -- starting with our friendship -- to experience, study deeply, and attempt to solve as definitively as possible the big programming challenges we've faced.
LC: In terms of Boot, what were those challenges that Leiningen did not solve? And how does Boot solve them?
AD:
- Leiningen does not supply a general file system watcher; every plugin must provide its own
- Leiningen does not coordinate filesystem access between plugins; the user must be mindful of every plugin's file use and weary of filesystem contention
- Leiningen plugins cannot easily be composed or invoked from the REPL, which requires the user to start a new JVM for every experiment
For these reasons I would say that Leiningen plugins must all duplicate essential functionality, don't compose well, and are cumbersome to develop and experiment with.
Hoplon existed for a short time as a Leiningen plugin, but like all ambitious Leiningen plugins it became its own build tool and didn't compose especially well with other plugins. Once your Leiningen plugin becomes essentially its own build tool, it's not hard to imagine taking the last step.
This is what we did and Boot was the result; Hoplon dissolved into a half-dozen Boot "tasks". Boot solves the problems we encountered in Leiningen:
- Boot tasks are "stateful middlewares" composed in a pipeline, similar to Ring middleware. Tasks can decide whether the tasks after them should run, the same way a Ring middleware can decide whether or not to invoke the next handler. With a reference to the next task, a task can invoke the next task once, multiple times, or not at all. With this ability, "watch" is no longer special, and it becomes a regular task. Library authors are empowered to write other watch-like tasks that initiate or prohibit builds depending on any condition, not just filesystem state.
- The value passed through the pipeline of tasks represents the file system, and is called a FileSet. It is an immutable snapshot of a filesystem. If a task needs to effect a change, addition, or deletion to the filesystem, it performs an operation on the FileSet -- returning a new FileSet -- NOT directly on the filesystem as a mutation operation. After the last task returns the final FileSet, Boot synchronizes the FileSet to the target directory. Access to the value of a FileSet doesn't need to be synchronized because it is immutable and the actual filesystem is not in contention. FileSet operations are efficient because Boot uses a content-addressed, hard-link backed structural sharing scheme to minimize actual file operations.
- A Boot task is a function, nothing more. Boot tasks can be created, tested, and composed in the REPL or in any Clojure program just like any Clojure function can. Facilitating task composition is a "unit of classpath isolation", the "pod", which is a Clojure runtime that can have dependencies independent of the rest of the build. So, these task functions can have dependencies independent of the project they might operate on. For instance, a task might supply typechecking using core.typed in a pod, but this doesn't imply the user know or care to add core.typed to their project's dependencies. Because tasks are functions, and because we have a unit of classpath, most builds can be orchestrated in a single JVM. Builds are easier to develop, and more efficient to run.
LC: This sounds great! Is there an efficient path you would recommend for switching a project from Leiningen to Boot?
AD: The best place to go after installing is definitely the wiki.
On the wiki there are many community-contributed tasks and projects to look at for ideas and examples. There is an active and helpful community that you can connect with on IRC (in #hoplon on freenode) and at http://hoplon.discoursehosting.net/
If you have an idea for a script or small program, this is a very nice introductory tutorial that demonstrates making a standalone, boot-powered script that can be called from the command line.
LC: Does Boot have dependency management? Does it work with Clojars?
MN: Sure, Boot uses Pomegranate, the same Aether library that Leiningen uses. Boot can also use Leiningen style wagons (like the S3 private wagon, for instance). The built-in tasks include tasks to install jars in your local Maven repo and to push to remote repos like Clojars. Dependencies can be loaded dynamically at runtime, and Boot has "pods" in which you can load dependencies that conflict with something in the current runtime.
Incidentally, I've been looking at Apache Ivy a bit, it looks really interesting. Maybe it's something we can use in the Clojure world.
LC: Where can people follow you and Boot online? How can they help?
MN: The Boot website is the main entry point into the weird world. We also hang out in the #hoplon channel on Freenode IRC where we provide support for all things tailrecursion but mostly just enjoy the interesting conversations that go on in there :) Help is always welcomed, people can check the open issues or create an issue here or on the associated kanban board here. We try to schedule RC releases weekly every Monday.
LC: Where can people follow you online?
AD: We can be followed at https://twitter.com/alandipert and https://twitter.com/michaniskin.
LC: If Clojure were a food, what food would it be?
AD: We both agree that Clojure is like anchovies: it's weird, relatively unpopular, but an essential ingredient in almost anything that's good. You should only ever need a small amount to make the dreariest meals magnificent. But never tell -- nobody needs to know exactly what they're so enjoying.
This post is one of a series called Pre-West Prep, which is also published by email. It's all about getting ready for the upcoming Clojure/West, organized by Cognitect. Conferences are ongoing conversations and explorations. Speakers discuss trends, best practices, and the future by drawing on the rich context built up in past conferences and other media.
That rich context is what Pre-West Prep is about. I want to enhance everyone's experience at the conference by surfacing that context. With just a little homework, we can be better prepared to understand and enjoy the talks and the hallway conversations.
Clojure/West is a conference organized and hosted by Cognitect. This information is in no way official. It is not sponsored by nor affiliated with Clojure/West or Cognitect. It is simply me (and helpers) curating and organizing public information about the conference.
You might also like
April 10, 2015
Introduction
Anthony Marcar generously agreed to do an interview about his talk at Clojure/West. The background to the talk is available, if you like.
Interview
LispCast: How did you get into Clojure?
Anthony Marcar: About 4 years ago, I decided that java wasn’t cutting it for me. I needed a new language, but I wanted to be on the JVM. So Scala and Clojure were the obvious contenders. I decided to spend 3 months building an online card game in both languages to see which I liked more. Scala at first was easier to get into, whereas Clojure was thoroughly alien. But over time, In Scala, I found I was spending more time building abstract Type graphs and waiting for compiles to finish, whereas in Clojure I was having a lot of fun and moving faster. I also loved the emphasis on immutability in Clojure. After that I was hooked.
LC: Clojure is relatively new, so you don't really get many experience reports of large production systems. When you hear someone talking about Clojure who has used it maybe only hobby projects or small projects, what are the common things that strike you as untrue?
AM: I don’t know if "untrue" is the right way to put it, but things people generally haven’t thought about before embarking on larger Clojure projects are things like how do you deploy your application, how do you go about logging and monitoring? How do you protect your application from going down if downstream dependencies start timing out? And how do you grow a code base across multiple projects? There still aren’t many resources in the Clojure space to answer these kinds of questions.
LC: Have you had experience bringing programmers who don't know Clojure onto your team? What were the challenges? What surprised you?
AM: Yes I have had rubyists, node.js and python people join the team. Not surprisingly the JVM was a big challenge. Things like the local maven repository, logging, and common java libraries can be hard to grasp. I was however surprised how easily everyone picked up on Clojure’s fundamentals such as immutability. I guess it’s because that’s what attracted them to the language in the first place.
LC: Do you think Clojure is a good fit for large companies with lots of software?
AM: Clojure is great for large companies. I think it’s greatest asset is its focus on data structures. In big companies, this is a big deal as there are layers and layers of legacy systems, each with their own outdated data formats and protocols. Clojure's focus on data transformations and concurrency makes it perfect for working with many different services to produce the right business outcome. That, combined with the the fact that it runs on the JVM makes it perfect for large companies.
LC: Do you have any advice for the folks out there working for big companies who want to introduce Clojure to their work?
AM: If you want to introduce Clojure at a large company, get ready for a very tough road ahead. Work from both the bottom and top of the organization. Try and find the engineers who are always looking at new technologies. The kind who get home and build side projects. Then infect them. At the same time, scour the organization for VPs, or SVPs who "get" technologists. Buy them a beer. Ask them to be a champion for you, to protect you every time a more "traditional" team tries to block your progress. You’ll need all the help you can get and will have to work well past your normal hours, but it’s worth it.
If you want to take a shortcut, build a company that does Clojure, and then get acquired by said big company ;)
LC: Is there anything else you'd like to add?
AM: All I would add is that working in Clojure is extremely fun. If you’re not already working in it full time, go and apply for a job somewhere where you can!
LC: If Clojure were a food, what food would it be?
AM: An ice cream sandwich. Because it’s awesome. That is all.
This post is one of a series called Pre-West Prep, which is also published by email. It's all about getting ready for the upcoming Clojure/West, organized by Cognitect. Conferences are ongoing conversations and explorations. Speakers discuss trends, best practices, and the future by drawing on the rich context built up in past conferences and other media.
That rich context is what Pre-West Prep is about. I want to enhance everyone's experience at the conference by surfacing that context. With just a little homework, we can be better prepared to understand and enjoy the talks and the hallway conversations.
Clojure/West is a conference organized and hosted by Cognitect. This information is in no way official. It is not sponsored by nor affiliated with Clojure/West or Cognitect. It is simply me (and helpers) curating and organizing public information about the conference.
You might also like
April 09, 2015
Introduction
Brandon Bloom generously agreed to do an interview about his talk at Clojure/West. The background to the talk is available, if you like.
Interview
LispCast: How did you get into Clojure?
Brandon Bloom: From 2009 to 2011, I encountered a couple of Rich's talks and writings. Each time I would look at Clojure briefly, but it never really clicked. When ClojureScript was released, my startup was heavily using CoffeeScript, so I decided to take a more serious peek at this new alternative. I immediately fell in love with Clojure and started contributing to ClojureScript. My startup never did get a chance to use ClojureScript, but Clojure on the JVM quickly became one of my favorite tools for prototypes and experiments, and I've lately, I've used it for serious business with some frequency.
LC: You will be talking about the CircleCI frontend, written in ClojureScript and Om. Om is less than 18 months old, and yet it is used in production systems and I assume replaced their previous frontend system. Can you speak to this decision? How was it evaluated?
BB: I honestly can't speak to the decision to use Om. That was made before I got involved. What I can say is that CircleCI was already a big Clojure user and their front end used to be CoffeeScript based. Daniel Woelfel deserves all the credit for choosing Om and delivering a production system with it. I got involved much later.
LC: What were some of the challenges that you faced when developing with such a new library as Om?
BB: Om is/was still evolving. It's got bugs, misfeatures, and other problems. Luckily, I've had the luxury of regular face time with David Nolen, Om's author, out at the Kitchen Table Coders studio in Brooklyn. I think that it's important for new library producers/consumers to interact regularly. Beyond that, the design patterns aren't established yet. It's difficult to simultaneously think deep thoughts about a challenging design space such as UI code, while also building a useful UI for your product. Sometimes, you just need to hack it and you can't be afraid to dig in to the library code while you're hacking it. After that, you need to reflect on whether your solution actually makes sense: Often it doesn't!
LC: What are some improvements to Om you would like to see?
BB: That's a tough question to answer constructively, since David has already picked all of the low hanging fruit that I've pointed out to him. Overall, Om is an absolute delight. That said, it's clearly a first real attempt at the React style of UI development in Clojure. Some parts of Om, like cursors, just never made much sense. Other parts feel like missed opportunities to truly capitalize on ClojureScript's strengths. At this point, my feedback could be rolled in to notes for a second attempt at this style of UI framework in Clojure.
David has made the very pragmatic decision to assume React.js as a long term dependency. However, once you really get in to the weeds hacking on a UI, it becomes clear, at least it did to me, that less layers is always a good thing. Overall, a virtual DOM implementation is pretty easy, although getting it to perform well is tricky. I'd really like to see a ClojureScript library that drops the React.js dependency in favor of a more direct mapping to Clojure idioms.
The dichotomy between primitive elements and Om components (created via om/build) has got to go. It hurts modularity and refactorability. But I also don't particularly like some users' insistence on hiccup forms for a variety of reasons.
The "no local state" descriptors thing should definitely be the only way Om operate.
The "world in an atom" model isn't quite structured enough. We need something more database-like to manage client/server synchronization. Facebook's Relay is impressive and, if you squint right, their GraphQL looks a lot like Datomic's Pull API. I know that Sean Grove has been experimenting with a DataScript-backed UI. I think that somebody needs to ship a prescriptive framework here that integrates a client-side database with the view layer.
I've also got extensive notes for an alternative events system.
Beyond that, toolability is critical. The framework needs a way to design and test an individual component in the browser. You should have to go out of your way to break that, not go out of your way to enable it.
LC: Where can people follow you online?
BB:
- https://twitter.com/BrandonBloom
- http://www.brandonbloom.name/
LC: If Clojure were a food, what food would it be?
BB: Certainly not a burrito.
This post is one of a series called Pre-West Prep, which is also published by email. It's all about getting ready for the upcoming Clojure/West, organized by Cognitect. Conferences are ongoing conversations and explorations. Speakers discuss trends, best practices, and the future by drawing on the rich context built up in past conferences and other media.
That rich context is what Pre-West Prep is about. I want to enhance everyone's experience at the conference by surfacing that context. With just a little homework, we can be better prepared to understand and enjoy the talks and the hallway conversations.
Clojure/West is a conference organized and hosted by Cognitect. This information is in no way official. It is not sponsored by nor affiliated with Clojure/West or Cognitect. It is simply me (and helpers) curating and organizing public information about the conference.
You might also like
April 05, 2015
Introduction
Colin Fleming generously agreed to do an interview about his talk at Clojure/West. The background to the talk is available, if you like.
Interview
LispCast: How did you get into Clojure?
Colin Fleming: Several years ago I was working in Java on online transaction processing systems. I was interested in the promise that Clojure had to make such systems easier to work with, in particular the concurrency aspects. I also liked Clojure philosophically, a lot of the ideas behind it really resonated with me.
I really wanted to use IntelliJ since I use it all the time and love it, but the existing plugin for it was fairly immature. I ended up porting a lot of it from Java to Clojure and that became Cursive, which is still the main Clojure project I've worked on.
LC: This year you're talking about debugging in Cursive. I never run an interactive debugger in Clojure, mostly because I don't have one readily available. I do remember using one in Java all the time. What am I missing?
CF: I use the debugger in Cursive pretty much every day, probably in a similar way to which you used to in Java. Cursive's debugger is basically IntelliJ's JVM debugger so it works in very much the same way with some Clojure-specific extensions. So you can stop at breakpoints, step, evaluate Clojure expressions, have conditional breakpoints where the conditions are Clojure expressions and all that. I'm working on some more Clojure-specific functionality like having a REPL running when stopped at a breakpoint too, which I think will be pretty nice. That said, the current expression evaluation works pretty well, and you can interactively inspect the returned objects and so on.
An argument I hear a lot is that a debugger is not required when you have a REPL, since you can interactively test parts of your application more easily. I think it's definitely the case that the REPL allows some of the exploration of a live system that previously required a debugger, but I've never understood why you wouldn't want both. All my work is on Cursive, where I'm integrating with a massive framework that I don't understand well, it's written in Java and is totally stateful so it's actually pretty tough to test at a REPL like that sometimes. The debugger is critical to being able to see what the framework is doing, working without it would be much harder than it is.
LC: Is the debugger ready for prime time? If not, what is left?
CF: Yes, definitely - it's all working pretty well now. That said, nothing is ever totally done, I still have improvements I'd like to make to it. Performance is sometimes an issue, because the JDI really likes you to know the exact name of the class you're working with. That's basically impossible to predict from source code in Clojure so you end up having to filter through a lot of classes. I hope to be able to improve that somewhat. Recent versions of IntelliJ also added functionality which displays the results of evaluated expressions right in the editor while debugging, similar to Light Table's inline REPL evaluation. Cursive doesn't support that for Clojure code yet, but I'll fix that soon. And a fair amount of Java leaks through in the UI since it's based on IntelliJ's Java debugger - variables are displayed with their mangled names, and so on. JetBrains are actually in the process of migrating their Java debugger from an old proprietary framework to a new language-agnostic one that they use to develop debuggers for other languages. Once that's complete hopefully I can tidy that up.
LC: You're really making me want to jump into Cursive. I used to use the debugger all the time. Basically, I'd write code unsure of what it would do, and just jump in and see. That was in Java, so there was still a long compile step. Is that better in Cursive since it's an interactive compiler?
CF: Sure, using Cursive you can debug an arbitrary script which will just have the standard Clojure script startup time, or even better you can debug a REPL session. This means that you can put breakpoints in your code, and when that code is hit by whatever you're executing in your REPL it'll stop. I use this a lot when running tests and trying to figure out why a particular test isn't working. Cursive takes care of disabling locals clearing when running like this, and there's also a toggle button in the REPL toolbar for it which you can use when connecting to a remote JVM.
LC: Where can people follow you online?
CF: The best way to get updates about Cursive is on Twitter or on the mailing list. I also have a personal Twitter handle, but that mostly serves to collect fans of the Scottish tennis player. They must be quite confused by my occasional tweets.
LC: If Clojure were a food, what food would it be?
CF: I'm going to go with blue cheese. It's a taste that you have to acquire, but once you do there's nothing better!
This post is one of a series called Pre-West Prep, which is also published by email. It's all about getting ready for the upcoming Clojure/West, organized by Cognitect. Conferences are ongoing conversations and explorations. Speakers discuss trends, best practices, and the future by drawing on the rich context built up in past conferences and other media.
That rich context is what Pre-West Prep is about. I want to enhance everyone's experience at the conference by surfacing that context. With just a little homework, we can be better prepared to understand and enjoy the talks and the hallway conversations.
Clojure/West is a conference organized and hosted by Cognitect. This information is in no way official. It is not sponsored by nor affiliated with Clojure/West or Cognitect. It is simply me (and helpers) curating and organizing public information about the conference.
You might also like
April 15, 2015
Introduction
James MacAulay is the next interview participant. He is giving a talk at Clojure/West about Functional Reactive Programming with the clojure library Zelkova. The background to his talk is available, if you like.
Interview with James MacAulay
Nola: How long have you been doing clojure and how did you get into it?
James: I've been writing Clojure in my spare time on-and-off for about three years.
In late 2011 I was on a small team developing a JavaScript MVC framework, and we had this problem of managing state in the browser over long periods of time. Our response was to let mutation happen all over the place and keep track of it all with a network of observed properties. It felt fun and empowering at first, but unfortunately it resulted in systems that were very difficult to reason about.
At some point I looked at the system and realized that all it needed to do was handle external events one at a time, and render some views based on those events. It was all starting to look like one big function to me...so I figured I should give a serious look at what functional programming was all about. Clojure had some really compelling answers to the questions I had, and soon I was hooked.
Nola: Any suggestions for someone wanting to dive into clojure?
James: If you're coming from an Object-Oriented background, take your time just getting used to writing different kinds of functions without relying on mutable state. The more you do it, the more fun it is, and it ends up being a really valuable habit to have when writing software in any language.
Nola: What languages did you do before clojure?
James: Mainly Ruby and JavaScript. In university it was Java more than anything else, but we were exposed to a number of other languages in smaller doses: Scheme, Prolog, C, x86 Assembly are the ones I'm most thankful for. When I first got interested in functional programming I dug into Haskell for a bit before Clojure really grabbed me.
Nola: Your talk is about Zelkova which is heavily inspired by Elm. Have you done much with Elm or implemented Functional Reactive Programming in other languages?
James: I first really got the Elm bug at Strange Loop 2013, where I saw Evan Czaplicki live code the Mario demo first-hand. I started playing with both Elm and Bacon.js, a JavaScript FRP library. Last summer I decided to try my hand at implementing FRP in Clojure, and figured I should read Evan's thesis to see how Elm works. I hadn't implemented any kind of FRP before, but Clojure seemed like a great language to do it in.
My experience with the Elm thesis was very similar to the one Eric Normand described having at around the same time – the code in the paper was just begging for a core.async implementation. I started hacking away, and learned a ton about both Elm and core.async in the process.
At Strange Loop 2014, I got to meet Evan and we had a really great chat about Elm and my work on porting its FRP system to Clojure and ClojureScript. He encouraged me to share my work and clarified a lot of things for me, and I've been poking away at Zelkova ever since.
Nola: What is the average airspeed velocity of an unladed Clojure REPL?
James: I try not to throw my laptop across the room when I get frustrated :)
Nola: Thanks for the interview. It was very informative.
This post is one of a series called Pre-West Prep, which is also published by email. It's all about getting ready for the upcoming Clojure/West, organized by Cognitect. Conferences are ongoing conversations and explorations. Speakers discuss trends, best practices, and the future by drawing on the rich context built up in past conferences and other media.
That rich context is what Pre-West Prep is about. I want to enhance everyone's experience at the conference by surfacing that context. With just a little homework, we can be better prepared to understand and enjoy the talks and the hallway conversations.
Clojure/West is a conference organized and hosted by Cognitect. This information is in no way official. It is not sponsored by nor affiliated with Clojure/West or Cognitect. It is simply me (and helpers) curating and organizing public information about the conference.
You might also like
April 14, 2015
This interview was graciously conducted by Nola Stowe. She's a programmer, the co-founder of DevChix, and a prolific teacher. She recently ran ClojureBridge Austin. Please shout out to her and say thanks!
Introduction
John Hume is the next interview participant. He is giving a talk at Clojure/West about Clojure internals. The background to his talk is available, if you like.
Interview with John Hume
Nola: How long have you been doing Clojure and how did you get into it?
John: I started playing with Clojure in late 2008—the fairly early days. It was interesting to me because I'd always heard that Lisp was amazing, but I'd never spent any time with one. Since Clojure runs on the JVM and has simple Java interop, it was far more accessible to me than any other Lisp. Since it was a new language and community, there seemed to be a lot of other people going through the same learning process I was, so the mailing list was very helpful. And back then it was low-traffic enough that I could actually keep up, which hasn't been the case for a long time.
Nola: What languages did you do before Clojure?
John: I'd been doing Ruby full-time for a few years before getting interested in Clojure—and continued to spend most of my time working in Ruby until 2012. Previous to that I'd done Java for about 5 years. Ruby really opened my eyes to how much power and expressiveness Java had been keeping from me. But after an exciting learning period with Ruby, I'd gotten a bit bored. Clojure came into my life at just the right time!
Nola: Any suggestions for someone wanting to dive into Clojure?
John: That's a tough one. A background in Java and Ruby made it easy for me to deal with some of what can make Clojure difficult for newcomers: Java helped with the JVM, the API, and the ecosystem, while Ruby had already made me comfortable with strong but dynamic typing and some functional concepts. For someone with a similar background, I'd definitely recommend giving Clojure a try.
My advice:
Start with tools you're comfortable with, rather than learning a tool you don't find intuitive while also learning a new language.
Start with a problem space you're familiar with, whether that's web, graphics, or data analysis, and find libraries that don't hide away too much magic.
Read the code! Lots of clojure.core and most other standard and contrib libraries are implemented in straightforward, idiomatic Clojure. Hopefully your tool of choice makes it seemless to jump into that code from your own. The only caveat with that advice is that sometimes—and it's not always obvious when this will happen—a library fn will be implemented in an unidiomatic way for reasons that aren't clear.
When in doubt, lean on the mailing list or IRC to find out from more experienced Clojurists whether what you're reading or writing is idiomatic or idiosyncratic code.
For someone with a different background, that advice might all be good, but there are probably aspects of the learning curve that I underestimate, so I'd recommend trying to find Clojurists with a similar background and getting their advice.
Nola: Thanks for the interview. It was very informative.
This post is one of a series called Pre-West Prep, which is also published by email. It's all about getting ready for the upcoming Clojure/West, organized by Cognitect. Conferences are ongoing conversations and explorations. Speakers discuss trends, best practices, and the future by drawing on the rich context built up in past conferences and other media.
That rich context is what Pre-West Prep is about. I want to enhance everyone's experience at the conference by surfacing that context. With just a little homework, we can be better prepared to understand and enjoy the talks and the hallway conversations.
Clojure/West is a conference organized and hosted by Cognitect. This information is in no way official. It is not sponsored by nor affiliated with Clojure/West or Cognitect. It is simply me (and helpers) curating and organizing public information about the conference.
You might also like
