Pre-West Interview: Ron Toland

April 21, 2015

Introduction

Ron Toland was gracious enough to agree to an interview. He is giving a talk at Clojure/West about building large systems in Clojure. The background to his talk is available, if you like.

Interview with Ron Toland

LispCast: How did you get into Clojure?

Ron Toland: I got into Clojure through Scheme.

There was a senior engineer at my first programming gig that kept raving about Scheme and the book Structure and Interpretation of Computer Programs (SICP). After several months of listening to him, I finally bought a copy and read through it. I was blown away by how very simple building blocks could be used to do very complicated things.

In particular, it struck me that the authors covered the map-reduce paradigm in only chapter 2 of their book; given that at the time I was reading (2009-2010) hadoop was all the rage, and the book was written in the 1980s, I started wondering "what else does lisp have that we're only now re-discovering"?

After doing some digging into currently used Lisps, I came across Clojure. Since I was already familiar with Java, it seemed like a perfectly pragmatic Lisp to me: stealing all the thunder of the JVM, but stacking on top of that the beauty and power of Lisp. It's been my favorite programming language ever since.

LC: You've been using Clojure at Sonian for 6 years. When you started, Clojure was very new. What made you choose Clojure at such an early point?

RT: I wasn't at Sonian when the decision was made to use Clojure, but I do know the background.

Basically the first version of everything was written in Ruby, which worked fine until they needed to scale things out and up to handle a larger volume of email.

They knew they needed to rebuild it in a different language, so they looked at several contenders: JRuby, Java, Clojure, Scala, even Erlang. They held a big meeting of all the devs to decide which one to go with, and it came down to Clojure or Erlang. Clojure, because several of the devs were familiar with Common Lisp or Scheme and liked it, and Erlang, because the architecture they were designing around is actually pretty close to the way you'd build it in Erlang.

Clojure won because of the JVM. It turns out that email is terrible, with multiple standards used by different programs at different times over the decades, and so processing it into something searchable is a nightmare. Java has a lot of libraries for processing email that have been built up over the years to handle most of email's craziness. Erlang doesn't (or at least didn't at the time).

Since with Clojure they could use those Java libraries directly, while if they used Erlang they'd have to write their own, they went with Clojure.

LC: What is the SAFE codebase?

RT: SAFE is the primary application we use at Sonian for email ingestion. archiving, and indexing into Elasticsearch.

LC: What is the most important thing to get right early when writing a large Clojure system?

RT: I wasn't part of the team that originally wrote SAFE, so I can't speak much about what to get right at the start of building a large system in Clojure.

I can say that a lot of large systems don't start out that way; they begin as smaller applications that grow over time, as needs arise. The trick is to keep it from becoming a mess by constantly revisiting how it's put together and looking for better -- usually more abstract, but not always -- ways to express what it needs to do.

LC: What do you wish could be better in Clojure for large systems?

RT: I'm not sure there's anything in the language itself I wish was better about Clojure for building large systems. Getting logging configured correctly always seems to be a pain; it'd be nice to have a single logging library that could hide the ugliness of the underlying java libs from us.

LC: Is there anything else you'd think would be useful for people to know before they watch your talk?

RT: I think that pretty much covers it. I'd encourage people to attend the Trapper Keeper talk today, so they can compare the two approaches.

LC: Where can people follow you online?

RT: I blog at mindbat.com, and my twitter handle is @mindbat.

LC: If Clojure were a food, what food would it be?

RT: If Clojure were a food, it'd be coffee. Once you use it long enough you can take it for granted, but when you don't have it you can't seem to get anything done.


This post is one of a series called Pre-West Prep.

For more inspiration, history, interviews, and trends of interest to Clojure programmers, get the free Clojure Gazette.

Learn More

Clojure pulls in ideas from many different languages and paradigms, and also from the broader world, including music and philosophy. The Clojure Gazette shares that vision and weaves a rich tapestry of ideas from the daily flow of library releases to the deep historical roots of computer science.

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

Pre-West Interview: Nathaniel Smith and Ruth Linehan

April 21, 2015


Introduction

Nathaniel Smith and Ruth Linehan generously agreed to do an interview about their talk at Clojure/West. They will be talking about Trapperkeeper. The background to their talk is available, if you like.

Interview

LispCast: How did you get into Clojure?

Ruth Linehan: I started using Clojure about a year and a half ago, when my team at Puppet Labs started working on a new project in it. Previously I had mostly worked in Ruby and Javascript, and while switching to Clojure required a bit of a mind shift, I really enjoy it!

Nathaniel Smith: I had never used it, but was offered a job at Puppet Labs two years ago to write it full time. I thoroughly enjoyed learning it on the 5 hour flight to my first interview there and have loved writing it ever since (in other words, I got the job :) )

LC: What does Trapperkeeper offer the Clojure developer?

RL: Great question! Trapperkeeper is great for complicated Clojure applications. It allows you to easily break up your code into modular pieces (what we call "services"), and it serves as a binder for these pieces of code. Any state a service needs can be stored in a map in the service context, rather than kept globally. It provides a consistent way for expressing the lifecycle of these services - what happens at startup and shutdown - and for managing dependencies between services. It has built in config file parsing, and it initializes a logging system using logback for you, so that you don't have to worry about this. It also has some useful test helpers that allow you to start up a Trapperkeeper application in code and test the whole system.

NS: A better way to compose the various services (Database, job queue, web server, logging, configuration...) that one has in a large, long running Clojure application. Trapperkeeper leads to more maintanable and reusable code.

LC: How does breaking everything into small services help build a large application?

NS: You have well-defined, protocol-enforced APIs for you various services and get to leverage TK's dependency management to ensure clean statups/shutdowns of all of your JVM infrastructure bits.

RL: Frequently, some of the code that's necessary to build a large application is code you (or someone else) had to write to build a different application. Breaking it down into smaller, more modular services means that you can more easily reuse that code across multiple applications. Furthermore, each service manages the state that it needs, so you don't end up with a huge mess of global state. It also makes testing much easier - you can test a service on its own, rather than having to set up the entire system to test it.

LC: Are there any similar systems in Clojure or elsewhere?

NS: A few, but none of them met our needs at Puppet Labs. We think that Immutant and Components and other similar projects are great, but they weren't a good fit for our needs.

RL: Trapperkeeper was heavily influenced by Stuart Sierra's "Clojure, Reloaded" workflow, and it has a number of similarities with other frameworks motivated by this, such as Jig and Component. Our way of turning on and off services and managing service dependencies borrows a lot from OSGi's service registry.

LC: Where can people follow you online?

RL: Nathaniel and I are both on twitter: I'm @ruthlinehan, he's @nate_smith. If you want to follow Trapperkeeper, we ("we" meaning many of the folks at Puppet Labs who work on or with Trapperkeeper) hangout on IRC on freednode in #trapperkeeper. We'd love to see folks there!

NS: I publish poetry and other esoterica at http://chiptheglasses.com.

LC: If Clojure were a food, what food would it be?

RL: Hm... maybe a melon? From the outside it seems hard and impenetrable, but once you get inside it's awesome and delicious! Also, a slice of melon looks like a parenthesis. :)

NS: Delicious whole wheat bread (ooh, or oat bread) used to make function sandwiches.


This post is one of a series called Pre-West Prep.

For more inspiration, history, interviews, and trends of interest to Clojure programmers, get the free Clojure Gazette.

Learn More

Clojure pulls in ideas from many different languages and paradigms, and also from the broader world, including music and philosophy. The Clojure Gazette shares that vision and weaves a rich tapestry of ideas from the daily flow of library releases to the deep historical roots of computer science.

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

Pre-West Interview: Leon Barrett

April 19, 2015

Introduction

Leon Barrett was gracious enough to agree to an interview. He is giving a talk at Clojure/West about parallel programming in Clojure. The background to his talk is available, if you like.

Interview with Leon Barrett

LispCast: How did you get into Clojure?

Leon Barrett: Actually, I wasn't even aware of Clojure until I started at The Climate Corporation 2.5 years ago. I had used Lisp a number of times in school, so it wasn't too foreign, but I'd never imagined that I'd write Lisp for a living.

LC: Clojure is great for shared-memory parallelism. Is it good for distributed programming?

LB: It can be; the same set of abstractions that are helpful locally can be helpful when distributed. For instance, there are some nice Hadoop MapReduce tools (though I happen to dislike Cascalog--it doesn't mesh with my mental model of mapreduce). Of course, you have to do some extra work to support distributed computing, but all in all it's relatively pleasant.

LC: What are your preferred distributed Clojure abstractions?

LB: You know, I don't feel qualified to opine on this too much. I mostly end up working on tasks that are fairly embarrassingly parallel, and I spend more of my time worrying about single-machine parallelism (hence my need for Claypoole). The core idea in the better Clojure distribution work I've done was, for both Storm and Hadoop, to just write simple, functional data transformations and then let the distribution framework worry about everything else.

LC: Where should someone get started with distributed programming in Clojure?

LB: I think both Parkour and Storm are very nice, though I had some issues using Parkour on Amazon's EMR. Just working with those, it's pretty easy to write distributed tools without worrying about the hard distributed parts (data movement, reliability, etc) yourself.

LC: What makes Clojure great for parallel programming?

LB: Clojure is great for parallel programming because of three things: Immutability, good core libraries, and macros.

First, the bane of parallel programming is mutable state; state makes parallel programs much harder to reason about. While it's possible to avoid shared state by writing functional programs with immutable data even in other languages, it's much easier in Clojure because all the standard libraries support it, so Clojure is easier to do parallelism with from the very beginning. Also, Clojure's parallelism features, such as future and deref, are well-designed and easy to use, making it very easy to get started with parallelism. Finally, macros make it possible to write parallel things without so much fuss; for instance, Clojure's futures (built with macros) are easier to use than Java's futures because they don't require any boilerplate. Similarly, the library core.async uses macros to add amazing parallel and asynchronous features as a library, whereas in other languages such features would need to be designed into the core language.

LC: Can you briefly explain Claypoole? What does it do? Why did you write it?

LB: I wrote Claypoole because I was dissatisfied with Clojure's built-in pmap for several reasons, including 2 in particular: First, I wanted to control the degree of parallelism, but core pmap's parallelism is determined only by the number of CPUs. Second, I wanted my pmaps to get things done as fast as possible, but core pmap is lazy and may be inefficient when the individual tasks have a high variance in duration.

Claypoole's core feature is a pmap that meets my demands--it's eager, and I can control the degree of parallelism, even across multiple simultaenous pmaps. As a bonus, it turns out that once one has good control over sharing threadpools in pmaps, it's easy to add other such features, so Claypoole also does a number of related, handy things, such as parallel for (pfor), unordered pmaps that return results in the order they're completed (upmap), and so on. I see Claypoole as a tool to provide an advanced degree of control over parallelism.

LC: Those sound really handy! Do you use reducers in your work? Where have you found them most helpful?

LB: I don't actually use reducers a lot. I used them while working with Parkour, and they were very cute there. However, in my own work I've tended to prefer Claypoole. Reducers is good because it has much less overhead than chained maps, which is great for functionally combining small tasks. However, I find that I tend map bigger tasks, so I benefit more from fine-grained control of parallelism in Claypoole than I would from the efficiency of reducers.

LC: Do you have any good background materials for people who want to do a little pre-reading/watching?

LB: Nope. My talk will start with some basics to make sure that everyone's on the same page, and my initial test audiences seemed to indicate that my intro works well for both beginners and more advanced programmers.

LC: How can people help with Claypoole?

LB: I love pull requests, and I appreciate bug reports (obviously, repeatable test cases make my life easier). But mostly, my goal with open-sourcing Claypoole was to have the community do this stuff right once, rather than having lots of people making partial reimplementations that work on just their case. So, just use it! I want people to use Claypoole rather than reimplementing it.

LC: Where can people follow you online?

LB: I'm not terribly vocal online. I guess I post to the Climate Corp engineering blog every so often.

LC: If Clojure were a food, what food would it be?

LB: One could claim that it'd be Cajun blackened catfish, because it's lean and full of flavor.


This post is one of a series called Pre-West Prep.

For more inspiration, history, interviews, and trends of interest to Clojure programmers, get the free Clojure Gazette.

Learn More

Clojure pulls in ideas from many different languages and paradigms, and also from the broader world, including music and philosophy. The Clojure Gazette shares that vision and weaves a rich tapestry of ideas from the daily flow of library releases to the deep historical roots of computer science.

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

Pre-West Interview: Priyatam Mudivarti

April 19, 2015

Introduction

Priyatam Mudivarti was gracious enough to agree to an interview. He is giving a talk at Clojure/West about building layout grid systems using Garden in Clojure. The background to his talk is available, if you like.

Interview with Priyatam Mudivarti

LispCast: How did you get into Clojure?

Priyatam Mudivarti: I read Chris Granger’s essay on LightTable in the fall of 2012. I remember that day: I got a new gig in Boston and my first task was to re-architect the ui stack using “Java” and “Responsive Design”. Rewriting apps in big companies meant migrating enterprise libraries and tag soups from the server to client, and most of that failed flat on your face. I had little control over the frontend, let alone design. While I was going through this—a block of no creativity—Granger’s prototypes showed an open canvas filled with code, floating around, their results shown inline, blurring the difference between an editor and a browser.

I was blown away.

What followed were his blogs, Paul Graham’s essays, Rich Hickey’s videos and other lispers blogging about enlightenment and such, but none of that made any sense. How can programming give you enlightenment? I believed in literature! Keep reading, I told myself, learn this language and it will change the way you think. The best writers, I believe, change the way you think of the world. Naturally, I am seduced by the same possibility with a programming language.

So I quit my job in the summer of 2013 to write my novel and teach myself Clojure and Clojurescript. I went to Clojureconj the same year and met Chris, and heard Alan Dipert, Stu, David Nolen, Rich Hickey and some of the best clojure hackers speak. After the talks I felt like one of the dumbest programmers in the room. And the more I learned about Clojure the less I knew about programming. It was an odd, beautiful feeling, something that made me a twelve-year old again.

I knew right away it was time to go into the rabbit hole.

LC: Where does your interest in grids come from?

PM: Typography and Typesetting found in Fiction & Literary Magazines (print). Often I found their layouts and typography superior to that on the web, and I always wondered why their websites suck.

When I spoke at ClojureWest 2014, I did a demo of a poetry app written in five languages. It was a great learning experience, but I also knew that the app wouldn’t scale and was a ticking bomb. Worse, my css was entangled in two DOMs: a virtual Dom and a real Dom, and events to change styles were bound and mounted on some lifecycle protocols of Om. One of my goals was to typeset poems and pages declaratively based on the content, and dynamically change their styles when their related ‘components' mounted. I didn’t know how to separate these concerns.

That led to me take a break from coding to deep dive into learning Typography. Typesetting has been around for centuries, after all. Now, design is not my core skill—I have worked in agencies and interacted with designers to understand their process. I went to TypoConf in SF and was surprised to see three hundred typographers—who don’t code css—talk about Kerning and typeface design. Met a typographer (who is now a good friend) and collaborated with him on several hobby projects to understand his process. At Sumner Stone’s workshop in SF, I saw one of the world’s oldest and most respected Typographer speak about Typography.

What followed was a natural discovery of Grids: a visual communication framework for graphic designers and typographers. I bought half a dozen books, downloaded and worked through a several grid libraries in Sass and Less and began to get a sense of how web designers think. Most confirmed to the traditional Grid theory within the limited syntax available in CSS.

I was convinced that Garden and Clojurescript had more power to express grids (and beyond) more fluidly, and dynamically, over CSS.

LC: What is Garden?

PM: Garden expresses CSS as associative data structures, the same way Hiccup expresses HTML. Vectors are used for selectors, and maps are used for declarations. They can be nested. CSS rules are simply vectors wrapping the nested vectors and maps.

Vectors can be passed around as data, composed through functions, and have the full power of Clojure/Clojurescript to express and organize stylesheets.

LC: If Garden compiles to CSS, how does it have more power?

PM: Joel Holdbrooks wrote Garden in Clojurescript, a real programming language, and in order to understand the power of Garden let us revisit the notion of abstractions in CSS.

Abstraction is at the center of most work in Computer Science and User Interface Design. It encompasses finding the right interface for a system as well as finding an effective design for implementing a system. CSS is arguably a simple language. It packs power by abstracting the entire stylesheet in concise, declarative syntax of rules.

However, over the years websites and apps have grown in complexity and pre-processors have proven that programming constructs like variables, mixins, and ‘pseudo’ functions can help designers organize code and structure their patterns. In order to facilitate a two-way communication with Dom, designers have also started using jQuery—a good example of what happens when you provide new abstractions to interact with a page. The proliferation of frontend frameworks have paralyzed even the best designers because it’s impossible to work within the same abstraction in isolation with the frontend team.

What remains is a spaghetti of Sass, client and serverside Markup, jQuery, and a dozen Javascript libraries and build tools. Designers are no longer in control of the page, and that’s a shame.

It is time we bring back that control with new abstractions. Garden is just Clojurescript— you don’t even need to learn the whole language. It provides a uniform syntax to express HTML, CSS, and Javascript from a designer’s point of view. It has namespaces to modularize styles, first-class functions, and sound data structures to organize them. It works on the server and client and can generate static css files. It has the potential to go beyond pre-processors and express designs in new creative ways. I’m more excited of this possibility than anything else, because if done right, it is possible to talk to print designers and graphic designers—in a language they understand.

I’m currently working on a Garden library and plan to show a few examples in my talk at ClojureWest. I have a long way to go, but it’s a start.

LC: What is the most common mistake programmers can fix with their typography?

PM: Vary contrast on the page by using the CSS font-xx and text-xx properties. For instance, take a plain html of your blog and practice typesetting header, body copy, certain subheadings, blockquotes, menu, and code blocks using different font weights and sizes and variants. See what happens. And please—don’t stick a default Helvetica into your body. Use a professional font, preferably in pairs. If in doubt, buy a print magazine. Steal.

LC: What resources would you point someone to to learn typography, grid layouts, and CSS?

PM: There are many resources.

My favorite typography book is Mathew Butterick’s Practical Typography; he’s a typeface designer and a lisp hacker. Ellen Lupton’s Thinking with Type is an excellent book that covers both the history and an in-depth discussion on designing with Type. Grid Systems in Graphic Design is considered a classic.

There are plenty of CSS books: HTML5 & CSS, CSS3 for web designers, and anything written by Chris Coyler at csstricks.com.

Shameless plug—I’m writing a book on UI Design from a self-taught designer and programmer's perspective, and plan to publish it this summer.

LC: Where can people follow you online?

PM: My website and twitter.

LC: If Clojure were a food, what food would it be?

PM: Clojure would be an Herb you would combine with others and drink, like good Oolong tea.


This post is one of a series called Pre-West Prep.

For more inspiration, history, interviews, and trends of interest to Clojure programmers, get the free Clojure Gazette.

Learn More

Clojure pulls in ideas from many different languages and paradigms, and also from the broader world, including music and philosophy. The Clojure Gazette shares that vision and weaves a rich tapestry of ideas from the daily flow of library releases to the deep historical roots of computer science.

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

Pre-West Interview: Elango Cheran

April 19, 2015

Introduction

Elango Cheran was gracious enough to agree to an interview. He is giving a talk at Clojure/West about using Clojure in other human languages. The background to his talk is available, if you like.

Interview with Elango Cheran

LispCast: How did you get into Clojure?

Elango Cheran: I got into Clojure on the suggestion of a friend. At that point, I had been writing scripts in Python and some Ruby. I was setting off to create a cross-platform GUI desktop program using SWT, a Java UI framework. I had recently read press about Clojure, read a few Paul Graham essays, and had seen initial Clojure attempts at work, but after that, I was more skeptical about Clojure / Lisp than interested. I was thinking of using JRuby since Ruby was the most high-level language I had used by then, and I enjoyed it, entirely outside of Rails. A good friend suggested that I try Clojure instead for its elegant memory usage (via persistent data structures) and design for concurrency. As I started writing more Clojure code, the old fears faded, and I started surpassing my own expectations. I attribute the success to Clojure gently nudging me by design towards simpler, better code. It's been great fun and learning ever since.

LC: Your talk is about adapting Clojure to work in foreign languages with different scripts. I can imagine it's very important to someone who doesn't speak English, but you probably have more insights into it. Can you speak to the difficulties someone might have with programming if they don't read/write English?

EC: Certainly, a lot of the tech world operates and communicates in English. I can explain the difficulties in 2 ways. First, if you can't read/write English, and want to learn programming, then you're limited to whatever resources exist in your mother tongue. From what I've seen for the Thamil language in my visits to India, even non-English resources rely on English eventually. Coining new words in another language to translate new English terms, in a fast-changing field like technology, is challenging enough. But if you want to teach coding, you have to revert to English for the source code examples regardless.

The other way of looking at it is from a native English speaker perspective: how old were we when we learned programming for the first time, and how hard was that? How old were we by the time we were fluent in a second language -- and fluent enough to use a computer and write code in it? I would bet that for many English speakers, programming fluency came first, and that would make sense to me. Computers and programming are tricky enough without the overhead of filtering the ideas through a second human language.

Currently, non-native speakers of English who learn technology are eventually bottlenecked by their ability to learn English, and learning English isn't uniformly accessible, either. Being able to write code in their first language could open up new doors, and I also think that Clojure currently would make for the easiest path to getting there.

LC: You mention that Clojure is well-suited to adapting to another human language. Why is that so?

EC: The things that make Clojure great for adapting to another human language are some of what make Clojure great as a programming language to begin with. Specific to another human language, the simplicity in the syntax is helpful in that there are less terms to translate, and the regularity of the syntax makes it easier as a beginner to wrap your head around. And more importantly, being able to extend the language without having to edit and re-compile the compiler is empowering. However, I wouldn't make any linguistic arguments in this regard -- 80+% of languages' sentence word order are either Subject-Verb-Object (e.g. English, Chinese) or Subject-Object-Verb (e.g. Thamil, Japanese), but Lisp puts the function (verb) at the beginning. Clojure targets popular runtimes (especially JVM and JavaScript), and the Clojure compiler and its target runtimes all support Unicode, which is the universal character set to represent the text of any language.

LC: What is the most interesting thing you have done with clj-thamil?

EC: I've written functions to implement various, basic Thamil language processing steps, like splitting a string into a seq of Thamil letters or phonemes, alphabetical sorting of strings, basic suffix-adding rules, and transliteration/character set conversions. Among other things, I've used clj-thamil along with Enlive to convert the Thamil text in an XHTML doc from a pre-Unicode character set to Unicode. I have ideas for wider-appeal applied uses in the future.

LC: Are people writing Clojure in Thamil?

EC: It's just me at the moment, but I hope that improves! The simplicity of Clojure has made something that has been viewed up until now as tricky and largely unimplemented, like lexicographic Thamil text sorting, into 30 lines of Clojure. And Clojure targets Java (JVM) and JavaScript. Clojure's benefits are tremendous and speak for themselves.

LC: How can people help? What would be most helpful for you?

EC: The biggest help in terms of translating Clojure would be to figure out how to iron out a few details: how to get the reader to understand the translation for ns (or require, use, etc.), how to support translated literals (e.g. true, false, :else, numerals), and get the underlying JavaScript compiler to successfully run optimizations when identifiers are non-English. In terms of education, if we could modify clojail (used in tryclj.com) to use a JavaScript console widget that supports Unicode characters, it would provide an immediate way to experience Clojure in the language of your choice. After that, if we could translate turtle-based teaching languages, we can provide a platform for kids to learn programming in their own language.

But at the same time, it would be great to get help in refactoring and extending this project for other languages. Although each language has its own unique characteristics, many languages will share solutions, even in ways we don't necessarily expect.

LC: Where can people follow you online?

EC: I'm @echeran on Github, +ElangoCheran on Google Plus, and my blog is at www.elangocheran.com/blog.

LC: If Clojure were a food, what food would it be?

EC: If Clojure were a food, it would be Sambar, a South Indian curry. It's tasty, has a lot of different good-for-you ingredients, it goes well with a lot of things, and I can eat it all day.


This post is one of a series called Pre-West Prep.

For more inspiration, history, interviews, and trends of interest to Clojure programmers, get the free Clojure Gazette.

Learn More

Clojure pulls in ideas from many different languages and paradigms, and also from the broader world, including music and philosophy. The Clojure Gazette shares that vision and weaves a rich tapestry of ideas from the daily flow of library releases to the deep historical roots of computer science.

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

Pre-West Interview: Robert Krahn

April 19, 2015

Introduction

Robert Krahn was gracious enough to agree to an interview. He is giving a talk at Clojure/West about building Smalltalk-like features into Clojure. The background to his talk is available, if you like.

Interview with Robert Krahn

LispCast: How did you get into Clojure?

Robert Krahn: I am interested in Lisp generally because of the inherent simplicity in most Lisps mixed with rich meta-programming facilities. I followed the development of Clojure over the last few years and always felt compelled to do a project in it. For me the most interesting aspect is the clear distinction between identity and state handling and how the core language is designed around it.

In the beginning of this year I finally had the chance to start my first "real" Clojure project -- cloxp. So far it has been a great learning experience and a lot of fun.

LC: What are you bringing from Smalltalk with cloxp and why?

RK: The ideas and concepts behind Smalltalk exceed what is considered to be a programming language in most contexts. Just looking at the syntax tells you very little.

The goals that Alan Kay and his colleagues at Xerox Parc had in mind when creating Smalltalk actually go a lot deeper than just "better programming". Together with the Xerox Alto it was one of the first serious attempts to make "personal computing" real. A lot of it is summarized in "The Early History of Smalltalk".

However, I'm mostly focussed on the programming system aspects. So far the best description I've found that captures how it feels to work in a Smalltalk environment is "Swimming with the fish" by David Buck. The directness and immediacy you experience comes out of several properties: The programming environment can be explored and modified from top to bottom. Your code is not different from library code and "system-level" code. The system and the tools are made to inspect runtime state and processes. A debugger in Smalltalk is not just used for debugging, you actually write code in it (and have access to the runtime state while doing that). The entire system is changed incrementally. Not just as in you evaluate expressions like in a repl. The state of the system can be captured entirely, running processes and all. You literally start in the morning with what you had the day before.

All this makes programming more effective and fun. This is what I'm interested in and what, at least in part, I want to transfer into Clojure with cloxp. I think Clojure can offer a fresh perspective when designing an interactive programming system. I have, for example, David Nolan's om and other approaches to create "functional-style" graphical systems in mind.

LC: What are the main tools you're trying to build for Clojure?

RK: cloxp currently offers tools for exploring and modifying code. The main tool you work with is a system browser that lists namespaces and vars, somewhat similar to a Smalltalk browser that lists classes and methods. You can drill into code, modify individual definitions or the code associated with an entire namespace.

Apart from that, cloxp allows to instrument individual expressions in functions to capture data as it flows through. Captured data can later be viewed and inspected. Additionally to that you can also trace expressions and the subsequent function invocations entirely, similar to what clojure.trace offers but integrated in the tooling. Also, code can be evaluated everywhere you see it. Whether it is in the system browser, an inspector, or a workspace to do scratch programming.

All tools focus on using the Clojure runtime and meta programming facilities as much as possible. You have one or multiple Clojure VMs running most of the time that cloxp will connect to. By making extensive use of runtime data cloxp tries to achieve that "Swimming with the fish" experience.

LC: Do you recommend people learn Smalltalk? Where should they start?

RK: I certainly do. On a personal level, Smalltalk has fundamentally influenced me in how I think about programming and how I approach developing a software system. Both in terms of tools and software design.

There are two open source Smalltalk distributions available, Squeak and Pharo. They both come with "one-click" installers that let you start without much installation hassle. The free books Squeak by Example and Deep into Pharo explain the fundamentals. More documentation, screencasts and example programs are available as well here and here.

LC: Does cloxp have to modify the Clojure compiler? Or is it using already available constructs?

RK: So far all features rely solely on what Clojure has to offer. Non-core projects that proved to be useful are clojure.tools.nrepl, clojure.tools.reader, and clojure.tools.namespace. The abstractions around those are packaged into various sub-projects and can be found on github and clojars 11.

The runtime state of applications developed with cloxp are not saved. In this regard cloxp differs from Smalltalk. There is a clear distinction between tooling level and application, allowing you to load existing projects into the environment and just using it as a normal IDE.

The user interface of cloxp and the networking and persistence middleware are based on the Lively Web construction kit. Lively Web is in itself an interpretation of Smalltalk, mixing programming tools and serializable state with a wiki-like workflow.

The graphics are implemented with a re-implementation of Morphic, the graphics system of Self. For cloxp it provides a simple yet flexible way of implementing tools. And this is a crucial aspect: The implementation of typical IDEs are usually set in stone. They might provide hooks for plugins and extensions, but writing those is usually a major effort. And if there is not the right hook you are out of luck. In cloxp you can literally click on a tool to see and modify its implementation. This allows for the kind of customizability that Emacs users (rightfully) value so much.

And to come back to the first part of your question: Workspaces with the cloxp (and maybe your own) tools can be saved, basically using Smalltalk's image idea.

Now to the "bad" part: Currently, cloxp is a mix of Clojure and JavaScript. Modifying the frontend of the tools means that you have to deal with JS. Going forward I am interested in transitioning to a more "functional-style" implementation of Morphic using ClojureScript. Cloxp actually has just taken a ClojureScript (and cljx) class. So the way should be paved :)

LC: What features are you working on now? Where do you see it going?

RK: Right now I'm preparing a first release to allow everyone who is interested in the project to try it out. There already is an installer available but a few things need to be cleaned up.

Feature-wise I'm currently focusing on ClojureScript and work on getting the existing Clojure tooling to work with it. This will make interactive evaluation, code browsing and writing via the system browser and debugging via captures and traces possible. When this is done I want to figure out if it is feasible to combine the concepts of an interactive graphics system like Morphic with a more functional programming style. This will either bring the best of both worlds together or be a horrible disaster :)

If I'm able to continue with development of cloxp then there are (at least) two other upcoming topics: I'm really interested in a source-level stepping debugger and to bring cloxp and content created with it to a broader audience. The interesting aspect of cloxp and Lively Web is that those systems allow a) to author content and do programming at the same time, allowing e.g. the creation of interactive essays and b) are only requiring users to visit a web page. As an example, I've prototyped a "4clojure solver" that pulls down the exercises from 4clojure.com and let's users solve them with the live eval and doc features. If this could be hosted, maybe with some additional content, it would be a start and might form an innovative community resource.

However, to make this happen, help is definitely needed: Dear reader if you are interested in these projects, think that cloxp is a good idea and can help to move it forward, please get in touch!

LC: Where can people follow you and cloxp online?

RK: The cloxp site is at http://cloxp.github.io/. I'm a bit behind with updates but there will be more content documenting cloxp and explaining the ideas behind it. Whenever I feel like boasting about the newest hack I've written I post it on twitter @robertkrahn.

LC: If Clojure were a food, what food would it be?

RK: That one is easy. Chocolate pudding of course. Once you get started you can't stop.


This post is one of a series called Pre-West Prep.

For more inspiration, history, interviews, and trends of interest to Clojure programmers, get the free Clojure Gazette.

Learn More

Clojure pulls in ideas from many different languages and paradigms, and also from the broader world, including music and philosophy. The Clojure Gazette shares that vision and weaves a rich tapestry of ideas from the daily flow of library releases to the deep historical roots of computer science.

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

Pre-West Interview: Tom Faulhaber

April 18, 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

Tom Faulhaber is the next interview participant. He is giving a talk at Clojure/West about using Clojure to create Excel spreadsheets. The background to his talk is available, if you like.

Interview with Tom Faulhaber

Nola: How did you get into Clojure?

Tom: Rich Hickey did a talk called “Clojure for Lisp Programmers.” I bookmarked that talk but avoided it because I was scared of it. The idea seemed too interesting and I was afraid I’d get sucked in.

But over Thanksgiving weekend 2009, I had some time and I watched the video. I was sucked in and I’ve been an active member of the Clojure community ever since.

Nola: What other languages did you do before?

Tom: I’ve done them all. I’m a creature of the dark ages so I started with Basic, Cobol, Fortran and early Lisps. In the early part of my career, I worked on operating systems, data bases, and networking. This was all C and later C++. Nowadays, I do primarily Clojure and R along with some Python and Scala. One of the things I’ve learned is that there’s no silver bullet language: a clear understanding of of goals and good communication trump language choice every time.

Nola: What do you like best about Clojure?

Tom: I love Clojure, the language, but what I like even better is Clojure, the community. From the very beginning, Rich has worked hard to make sure it was a community of people that was positive towards each other.

Since then, more people have taken up the mantle of making Clojure more inclusive with initiatives like ClojureBridge and diversity scholarships. In addition to the folks using their own energy to make this happen, I have been very happy with the overall supportive tone in the community with respect to these efforts.

Like all tech communities, we clearly have a long way to go, but it’s hard not to be pleased that the community is receptive to these goals and always looking for ways to be better.

Nola: What advice do you give new clojure developers?

Tom: This would be my advice for anyone learning a new language: human or computer. Take the language on its own terms and don’t try to enforce your own previous assumptions on it. For example, in Spanish the adjective usually comes after the noun. This causes a reaction in English speakers, who often think that Spanish gets it “wrong.” That’s not a productive approach to embracing the language (and, in fact, one reason to learn foreign languages is to experience those differences and thereby gain perspective).

In the case of Clojure, parenthesis, prefix notation, and lack of built-in typing come to the top of that list. When you’re learning Clojure, try really hard not to have negative opinions about these things. Accept what the experienced folks say is “best.” Later when you’re more familiar with the language, you’ll probably agree with the experts. But even if you don’t, it won’t be because you let yourself be blinded by where you came from.

Having said all that: Do use paredit. It makes dealing with the parentheses fade into the background and is available in most dev environments now.

Nola: What does your tooling look like? emacs or vim or ?

Tom: I’m an emacs user from way back. I’ve been very thankful for the work that Bozhidar Batsov, Phil Hagelberg and others have done over the years to make the Emacs Clojure environment so nice.

Nola: Your talk is about creating spreadsheets in Excel, have you spent alot of time creating spreadsheets in other languages? what benefits do you get over using clojure?

Tom: Yeah, a friend told me recently that I’ve been obsessed with Excel for a long time. I have used Excel natively and Excel from .Net (mostly through IronPython) to create live dashboards of systems and businesses in action without the overhead of building a website or buying an expensive tool.

I want to be able to use Excel for the things it’s good at and use Clojure for the things it’s good at. It turns out that they can go really well together.

For more on that, you’ll have to come to my talk which will involve live coding in both Clojure and Excel!

Nola: How would you use clojure to defeat the Kobayashi Maru ?

Tom: That’s easy - use destructuring to get the Kobayashi Maru out of the neutral zone without entering it myself:

(defn rescue-kobayashi-maru
  [neutral-zone]
  (let [{:keys [kobayashi-maru]} neutral-zone]
    kobayashi-maru))

Back in the real world, I’ve found that Clojure’s capabilities to handle super-complex deeply nested data structures gets me out of scrapes that users of other languages thought were almost impossible to deal with.

Nola: Thanks for the interview. It was very informative.


This post is one of a series called Pre-West Prep.

For more inspiration, history, interviews, and trends of interest to Clojure programmers, get the free Clojure Gazette.

Learn More

Clojure pulls in ideas from many different languages and paradigms, and also from the broader world, including music and philosophy. The Clojure Gazette shares that vision and weaves a rich tapestry of ideas from the daily flow of library releases to the deep historical roots of computer science.

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

Pre-West Interview: Tyler Tallman

April 18, 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

Tyler Tallman is the next interview participant. He is giving a talk at Clojure/West about Clojure to do real-time communication in the healthcare industry. The background to his talk is available, if you like.

Interview with Tyler Tallman

Nola: How did you get into Clojure?

Tyler: I had read much about it before, but Stephan Richter's demonstration of Clojure on app engine led me to binge listen to every Rich Hickey talk I could find. He had me at "epochal time model".

Nola: What languages did you do before Clojure?

Tyler: C++ python and a bit of php

Nola: What advice do you have for beginner Clojure programmers?

Tyler: Read lots of other peoples code and take the time to make at least one design as simple as you possibly can.

Nola: What is your tooling like? emacs or vim or ?

Tyler: I started on vim moved to emacs for it's clojure support and now mostly use Cursive.

Nola: You mention React in your talk description, are you using it in ClojureScript? What flavor of React are you using? (ie Om, Reagent, etc)

Tyler: We use a modified version of Quiescent. I think all the React from Clojure work will eventually grow together into a set of functions and a common macro used to generate the react class directly.

Nola: How would you use Clojure to defeat the kobayashi maru?

Tyler: Persistent data structures of course

Nola: Thanks for the interview. It was very informative.


This post is one of a series called Pre-West Prep.

For more inspiration, history, interviews, and trends of interest to Clojure programmers, get the free Clojure Gazette.

Learn More

Clojure pulls in ideas from many different languages and paradigms, and also from the broader world, including music and philosophy. The Clojure Gazette shares that vision and weaves a rich tapestry of ideas from the daily flow of library releases to the deep historical roots of computer science.

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

Pre-West Interview: Bruce Hauman

April 18, 2015

Introduction

Bruce Hauman was gracious enough to give me an interview. He is giving a talk at Clojure/West about Figwheel, the ClojureScript autoreloader. The background for his talk is available, if you like.

Interview with Bruce Hauman

LispCast: How did you get into Clojure?

Bruce Hauman: I was doing Rails work and I was really burnt out. I had heard of Clojure and ClojureScript through HN and I have always been a big lisp fan. My favorite programming books were the Little Schemer series, PAIP, and SICP. I rewrote the pattern matching macro in PLTScheme (now Racket) as a hygenic macro and was its maintainer for a brief time.

My friend Tobias Crawley (of Immutant) was using Clojure as well and speaking its praises.

Yeah so I was already a crazy lisp fan and the idea that I could develop front end stuff in ClojureScript absolutely captivated me, so I started with it.

I also have to credit Simple made Easy and Rich Hickey's other inspiring talks.

LC: Why did you create Figwheel?

BH: A year ago, I was doing a lot of exploring with ClojureScript and at the time the REPL really didn't work. I would work really hard to get a REPL working and that work would be rewarded with an unstable REPL that just would freeze up at the worst time, so I gave up on it.

My motivation to write Figwheel was all about feedback. The process of repeatedly reloading the browser and manipulating a ClojureScript program into a certain state to test/verify wether a certain code section was behaving as expected was becoming absolutely intolerable. I really don't know how front end developers put up with this.

So I asked myself "Well what is the ideal experience here?." The answer was pretty clear: I want to see the effects of my code changes as soon as I save a file.

I started by doing a simple test. I reloaded whole files into the browser when they finished compiling. This brute force method worked surprisingly well. I had to think about the load time side-effects of my code more, but the feedback especially for GUI programming was absolutely awesome.

I look back now and realize I was really lucky. The Google Closure module system is very amenable to hot patching, this and ClojureScript's awesome incremental compilation made this process very straightforward. Lots of things could have made this much more difficult/impossible but everything was in place just waiting for me to put the pieces together.

LC: What were some of the challenges creating Figwheel?

BH: The hardest part initially was hooking into lein-cljsbuild to get a fast reliable after compile hook. At the time, I didn't have any experience writing Leiningen plugins and also very little time working with Clojure itself, so the going was a little rough.

Iterating on the plugin was very time consuming because I didn't how to tap into the running process with nREPL. I ran "lein figwheel" over and over again and waited for the process to boot way too many times before I decided to learn a better workflow.

I feel like this stuff is arcane knowledge in the Clojure world. Folks talk about REPL driven workflows but as a newcomer its tough to ferret out the actual workflows themselves. Once you get it, you get it, but before then it's kinda hard to discover.

The next hardest thing was hacking the Google Closure module system defined in goog/base.js to accommodate live module loading. The hooks were there but I had to do a bunch a searching to find them. It turned out that a two line hack enabled live reloading with proper downstream dependency handling. Again, I felt like I got really lucky that things were designed this way.

After that it was smooth sailing until I got fed up with how editing macros (or any clj file on a cljs path) caused lein-cljsbuild to do a complete project recompile. This caused all kinds of havoc. I had to fix this. I wanted macro editing to be just as responsive as editing cljs files. This took a bunch of time but I am super happy with the result. Whenever I edit a macro live and think about the downstream changes being made, I'm damn impressed by the power that ClojureScript offers modern front end developers. Code "transformations" that you are defining live are being applied to your running code base live in the browser!!! Dang! Think about all the design decisions that came together to make that possible. Impressive!

LC: Anything else you'd like to share?

BH: I am really looking forward to ClojureWest, if people see me walking by please don't hesitate to hit me up.

There is hopefully going to be a Figwheel Unsession that will be more interactive and more technical, if people are interested they should add their twitter handle to the unsession page.

LC: Where can people find you online?

BH:

LC: If Clojure were a food, what would it be?

BH: Foie gras corn dog.


This post is one of a series called Pre-West Prep.

For more inspiration, history, interviews, and trends of interest to Clojure programmers, get the free Clojure Gazette.

Learn More

Clojure pulls in ideas from many different languages and paradigms, and also from the broader world, including music and philosophy. The Clojure Gazette shares that vision and weaves a rich tapestry of ideas from the daily flow of library releases to the deep historical roots of computer science.

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

Pre-West Interview: Christopher Small

April 16, 2015

Introduction

Christopher Small was gracious enough to agree to an interview. He's giving a talk at Clojure/West about automating a chicken coop with Clojure. The background to his talk is available, if you like.

Interview with Christopher Small

LispCast: How did you get into Clojure?

Christopher Small: I actually wrote a blog post about this.

In short, I was evaluating languages with which to implement the machine learning engine for my startup, pol.is. After having done some tinkering with Haskell and OCaml, I’d come to love functional programming, and thought it would be fun to use a functional language for this project. At the time, I wasn’t aware of FP’s strong concurrency story, but learning of it pretty naturally led me to Clojure, which we went with for a number of reasons.

Since using it, I’ve fallen more and more in love with it every day. To me Clojure is the best of two worlds: the elegance and power of functional programming combined with the relaxed, fun atmosphere of python or ruby.

I’m now thoroughly addicted.

LC: How did you get into raising chickens? And what led you to try automating some of the tasks involved?

CS: My family raised chickens when I was growing up, so I've been around them since I was little.

More recently, when I moved to Seattle I lived in a housing co-op called the Ballistic Chicken Coop, so called because we took care of half a dozen chickens. The chicken run was fully enclosed, but every now and again the raccoons would find a way in and we'd loose a chicken or two. We'd patch it up, but they'd eventually find another way in. At times we'd try closing the coop door at night and opening in the morning, but that became an orchestration nightmare for the house. Also, chickens like getting up early, and we... didn't. It occurred to me that the only way to make sure they were safe -- aside from completely redoing the run, a major project -- would be to set up an automatic door for the coop. I spent some time coming up with plans and door designs, but sadly never made the time to actually build it.

There was this chicken there we called Black Chicken. She's one of the sweetest birds I've ever seen. She would sit on my lap and let me pet her, rolling her eyes back and clucking gently. We became BFFs. But at the BCC, when chickens stop paying rent, the get "evicted". Which is to say, turned into soup. While I was there, I was able to stay the hand of death, but I knew that if I moved, I would have to take her with me.

Fortunately, my wife and I were able to find a place very close by being vacated by a friend of ours who had a small flock she needed to leave behind. However, at the new place, the top of the run wasn't fenced in like at the BCC, so we had to lock them and let them out each night and morning.

As a lazy, functional programmer, this could not stand, so I finally went to work building the automatic door.

LC: What made you choose the BeagleBone Black?

CS: The short answer is that I already had one. The long answer is the reason I had one already.

The world of physical computing boards breaks down into the microcontroller and full computer camps. The former is best exemplified by the Arduino, while the Raspberry Pi is the most popular of the latter.

Microcontroller boards are nice because they draw a lot less power, but don't come with the creature comforts of a fully fledged operating system, meaning you're stuck writing in C or C++. There is a program called Firmata one can install on their Arduino which makes it possible to control the board remotely, but that would have required an 80 ft USB cable going out to the coop. Since I wanted to try hardware programming in Clojure, this class of boards was ruled out.

While the Raspberry Pi is the most popular full computer board, the BBB has some distinct advantages. The BBB has more pins, and in particular has analog input pins built in, which I needed for this project. At the time anyway, it was also more powerful and had more RAM than the existing Pi, which is a plus for Clojure/JVM programming. However, the Pi released just this Feb 2015 has upped the ante a bit, at a lower price; I'm sure there will be some tit for tat for some time here. There are a whole host of other boards out there with their ups and downs, but without getting too far in the weeds, I chose the BBB.

LC: Where can people follow you online?

CS: I'm on Twitter and GitHub as @metasoarous, and my blog/home page is metasoarous.com.

LC: If Clojure were a food, what food would it be?

CS: Had to think about this one for a while. But I'm going to go with one of my favorite fruits: the mangosteen. It's modular, elegant, and delicious :-)


This post is one of a series called Pre-West Prep.

For more inspiration, history, interviews, and trends of interest to Clojure programmers, get the free Clojure Gazette.

Learn More

Clojure pulls in ideas from many different languages and paradigms, and also from the broader world, including music and philosophy. The Clojure Gazette shares that vision and weaves a rich tapestry of ideas from the daily flow of library releases to the deep historical roots of computer science.

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