Lambda Abstraction

May 17, 2015

Summary: Lambda abstractions are always leaky, but some are leakier than others. Clojure programmers recommend keeping most of your functions pure and containing the leaks as much as possible.

Lambda abstraction refers to something we do all of the time. Let's say I have some code:

(+ 1 2)

I'm adding the number 2 to a number, in this case, 1. I could abstract that into a lambda:

(defn add2 [x] (+ x 2))

Now it's a function, which I can apply to 1. (add2 1). I can apply it to any number I want. The actual thing I am adding 2 to is abstracted away and replaced by the variable x. Lambda abstractions are just functions.

Functional programming is at its best when lambda abstractions are referentially transparent. That means that given the same arguments, a function will always return the same value. Being referentially transparent makes a software function more like a mathematical function. And that lets you reason about your code.

But there's a very real difference between software functions and mathematical functions: mathematical functions take no time or energy to "compute". They are defined abstractly, with no notion of computation. In contrast, software functions always take some time to compute. Sometimes the clearest way to write a function takes enough time that the illusion of mathematical functions is shattered. The abstraction is leaky.

So software functions are already a leaky abstraction, even if they are referentially transparent. Clojure (like most programming languages) opens the leak even further: you can put stuff that's not referentially transparent right in your function. For instance, you can write a "function" that reads from the disk or makes a web request. Making the same request twice can obviously return different values.

What most people programming Clojure recommend is to program mostly with pure functions (that means referentially transparent). You still have to deal with time, but that's way easier than dealing with the chaos of the world outside. That leaves a small bit of your code to deal with mutation, input/output, and the disk. It's still a lambda abstraction (function) but it's just leakier. Clojure simply leaves the decision up to you where to draw the line. Clojure tries to make pure functions easy, even when not everything fits into pure functions.

The takeaway of functional programming is the same recommendation: write most of your code as referentially transparent functions. The degree to which a language helps you do that is how "functional" the language is.

If you'd like to learn more about Clojure and pure functions, check out LispCast Introduction to Clojure. It's 2.5 hours of high quality video. You probably haven't seen anything like this! There's animations, exercises, characters, and screencasts. It takes you from no knowledge to a deep experience, all while having fun!

Learn Functional Programming using Clojure with screencasts, visual aids, and interactive exercises
Learn more

Infinite Application

May 17, 2015

Summary: Function application is a key concept in lambda calculus. While it is commonly expressed using parentheses in Clojure, it is also reified into a function which itself can be applied to another function.

Function application in Clojure is easily expressed with a couple of parentheses:

(foo 1 2 3)

That's the function foo applied to the arguments 1, 2, and 3. But let's say we have those numbers in a vector somewhere, and we want to call foo on them.

(def some-numbers [1 2 3])

We could manually pull out the arguments from the vector like this:

(foo (some-numbers 0) (some-numbers 1) (some-numbers 2))

Great! That should work. But more commonly you see this:

(apply foo some-numbers)

apply means take the function (the first argument) and apply it to the arguments which are in the list (the last argument). apply pulls out the values from the list internally so you don't have to.

apply is a function you'll see in many Lisps. It plays a key role in the meta-circular evaluator as defined in The Structure and Interpretation of Computer Programs (SICP). In the meta-circular evaluator, eval and apply are defined in terms of each other.

The way eval is defined classically, (foo 1 2 3) gets turned into (apply foo [1 2 3]) internally. This means that you can replace (foo 1 2 3) with (apply foo [1 2 3]) in the program without changing the meaning.

But! Since apply is a function, (apply foo [1 2 3]) is equivalent to (apply apply [foo [1 2 3]]), which is equivalent to (apply apply [apply [foo [1 2 3]]]). And you can expand that out forever. (Please don't!).

apply is something I really love about Lisp. It takes one of the main parts of lambda calculus (function application) and reifies it. Function application is available as a function, which can be passed around, composed, etc, just like any other value. I love it!

If you're in love with this idea, too, you might want to check out LispCast Introduction to Clojure. It's my video course about, you guessed it, Clojure. It takes you from absolute parenthesis-phobe to I-never-knew-it-could-be-this-way lisper by using animations, exercises, and screencasts.

Learn Functional Programming using Clojure with screencasts, visual aids, and interactive exercises
Learn more

You might also like

But the World is Mutable

May 11, 2015

Summary: The world may be mutable, but people have been using the notion of immutability to build reliable systems for a long time.

Immutability is a hard topic to breach. As a programmer used to modeling the world, you might object to immutable data structures. How do you model a changing world? Why would you choose to use immutable data structures when everything in the world is changeable?

Let's do a little thought experiment. Let's look at a nice mutable system: paper and pencil. You can write, erase, and write again. It's very convenient. It lets you correct mistakes. And when you don't need something anymore, you can easily erase it.

Now answer this: would you trust a bank that used pencils to record transactions? It would be easy: whenever you would withdraw money, they would erase the old balance and write the new balance. And if you transferred money from one account to another, they'd erase two balances and write the new ones in. It may sound great, but there's a reason banks don't use pencils: they want to be sure nothing has changed. That sounds like immutability.

Bank ledger (photo credit)

Bank ledger (photo credit)

This is a bank ledger. Each transaction gets its own line. Always done in pen. It's an example of an append-only data structure. You can answer questions about the past like "How much money was in the account at the close of last Tuesday?" by going up lines until you find the last entry for Tuesday. And you can do that because you never modify existing entries. You only add new entries on blank lines.

Medical record system (photo credit)

Medical record system (photo credit)

This is another example of an append-only data structure in the real world: medical records. Each patient gets a file that everything is added to. You never modify old records. That way, everything is recorded, even the wrong diagnoses (mistakes) of the doctor.

It turns out that traditional systems that need a high degree reliability create immutable records out of mutable paper. Even though you could in theory scratch out some data and write it again, or white it out, or find some other way to mutate the document, a mark of professionalism in the job is to discipline yourself to adhere to strict append-only behaviors.

Wouldn't it be nice if the machine took care of the discipline for us? Even though RAM and disk are mutable like paper and pen, we can impose a discipline inside of our program. We could rely on the programmer to never accidentally overwrite existing data. But that's just shifting the burden. Instead, we can build in immutability into our data structures and make a paper that cannot be overwritten.

That's how immutable data structures work. All new pieces of information are written to new locations in memory. Only when it is proven that a location is never going to be used again is it reused.

Reliable paper-based systems use immutable data. There was a time when computer memory was expensive when we had to reuse storage, so we couldn't make immutable systems. But RAM is cheap now! We should be using immutable data, just as banks have done for hundreds of years. Ready to join the 13th century?1

If you're interested in a language with a very cool set of powerful immutable data structures, probably the most cutting edge immutable data structures in any language, you're in luck! You can get LispCast Introduction to Clojure. It's a video course with animations, exercises, and screencasts that teaches you Clojure so you'll learn it and remember it.

Learn Functional Programming using Clojure with screencasts, visual aids, and interactive exercises
Learn more

You might also like


  1. The Double-entry method of accounting can trace its history back to 13th century Florence.

clojure.test cheatsheet

May 03, 2015

Summary: I made a clojure.test cheatsheet that you can get for free.

Cheatsheets are a great way to bootstrap new skills. Because at first there is so much to learn, we need all the support we can get. Instead of asking a beginner to scour through docs, hand them a good cheatsheet and they can get something accomplished. They'll remember the details eventually, with practice.

And as part of my campaign to rock the Clojure world with cool stuff, I made a cheatsheet for clojure.test, the built-in and oh-so-popular testing library for Clojure. Just sign up for the email list and it will be yours for free, along with the core.async reference sheet and the one-page Ring Spec.

You might also like

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