Pre-Conj Interview: Jeanine Adkisson

Introduction

Jeanine Adkisson was kind enough to answer some questions. Her talk at Clojure/conj will be about variants in Clojure. Read the background to her talk.

Interview

LispCast: How did you get into Clojure?

Jeanine Adkisson: Through work, actually. I'd seen clojure around and studied some of its features from a language design perspective, but I've never really been a lisper, so it hadn't occurred to me to actually use it until we started a migration to datomic at GoodGuide. I admit to being a bit skeptical - I often find that lisps are a bit oversold - but a coworker of mine (@bonkydog) started really gushing about generative testing, core.typed, and the awesomeness that is leiningen, so I decided to give it a closer look.

LC: Your talk is about Variants. Can you explain Variants and how they are useful?

JA: Sure! Variants are a functional design pattern that should be familiar to anyone who's worked in the Haskell/ML family of languages (and to a lesser extent, Erlang). Their main purpose is to provide a structured way to manage polymorphism. In lisps and other single-type languages, they're not that widespread because we don't have to convince a type-checker that our polymorphism works out in the end. But we still have to convice users of our libraries and our doc writers that our functions make sense!

The method of representing variants I'll be talking about came out of some frustrations I was having at porting part of a language over to clojure, and finding it difficult to represent and destructure the trees I needed to process. But I was really impressed at how quickly David Nolen and Ambrose BS got back to me and shipped patches that made this approach possible (and typeable!).

LC: You mean David Nolen patched ClojureScript and Ambrose BS patched core.typed?

I wonder what it means about dynamic languages like Clojure that you can add Variants as a library instead of making it an integral part like in Haskell. What do you think about that?

JA: Yeah, actually it was a bugfix the match macro and the way that core.typed handled vectors that were key. What's even more interesting about variants is that there is really no library to write - all the machinery is already there. The solution isn't even particularly clever or novel - it's already in use in, for example, instaparse. It's just not on people's radars, or they have misconceptions about the approach from their OO training.

I love the fact that you can backport this pattern into a language that's not explicitly built for it. I wouldn't necessarily count that as a strength for dynamic languages in general though - I find a language's strengths often come from ways in which semantics are restricted. Clojure is already a great example of this because it explicitly rejects the use of willy-nilly mutable structures, to great benefit. Sure, you can program that way in Ruby, but the tools are already there in Clojure.

What I find coolest about the Clojure case is the extent to which core.typed has been able to backport types onto a mostly untyped ecosystem. The general problems with dynamic languages are still there, but they have to be made explicit with union types. How many functions surprised you by outputting (U <thing> (Value nil))? But because it's powerful enough to support variants in a lightweight and usable way, I think we now have a tool to deal with one of the most common culprits of surprise nils.

LC: I think the approach is worthy of study. I flipflop between statically typed vs dynamically typed because there are obvious problems with both. How close does your core.match and core.typed solution come to a full-on ML/Haskell-style, integrated solution?

JA: It's pretty comparable, and actually has some advantages. Since it's just vectors and keywords, it's trivial to handle in a generic way, and as long as you're not putting functions or host objects in them it's trivial to serialize and send over the wire. (Haskell and ML can do most of this programming for you with various generic programming extensions, but it's not straightforward or obvious). But yeah, core.typed is capable of refining types based on the tag matching code generated by core.match - a little roundabout, but it gets the job done. The match macro can also match against more than one object at a time, something OO languages constantly struggle with. There's a little more macro work to be done in core.typed to make it really straightforward to do variants, but it's a relatively trivial syntactic transformation.

In terms of typed vs. untyped, I think there's lessons to be learned from both. My instinct is to say that we just haven't really figured out how to make typed systems all that usable. Haskell and ML went a long way towards this, and I think they kind of hit a wall because of their restriction that compilation be decidable. In other words, the compiler is not allowed to infinite-loop - which sounds like a good idea until you line up all the restrictions required to make that happen. In dynamic languages, we don't have a semantic separation between "compile-time" and "run-time", but we still talk about "load-time" vs "run-time". And at load-time you can wield the full turing-complete power of the language. That's why I'm also excited about projects like Agda and Idris, which, while still statically typed and compiled, blur the lines between runtime and compile time - moving away from strict decidability guarantees in exchange for a more expressive system.

LC: A lot of the audience is going to be new to Clojure or they have never heard of variants. Is there a resource that you think would help make the most of their time? Just a little pre-reading or pre-watching so they feel confident with the material?

JA: Yeah, there's unfortunately not a whole lot targeting clojure or other lisps, which is one of the reasons I wanted to give this talk. There's a great section in the ocaml tutorial about them, and Learn You a Haskell covers them as well (although they call them ADTs). The approach I'll be talking about is most like what's used in Erlang, as in the temperature example here.

LC: Where can people follow your adventures online?

JA: Probably the best way to keep up with me is on twitter at @jneen_ (note the final underscore), or on github as @jneen.

LC: One last question: If Clojure were a comic book superhero, what would its superpower be?

JA: Hahaha, I'd probably say a shapeshifter, like most lisps I suppose.

LC: Thanks for an excellent interview. I had fun.

JA: Awesome, thanks!


The Clojure/conj is going to be awesome. I've never been, but I have watched all of the videos from the prior conferences. I'm going this year, and you should, too! Go buy your tickets. There's some cool stuff happening there, including Opportunity Grants. Check out the Clojure/conj site and buy your tickets while they last. Clojure/conj is organized by Cognitect, the company behind Clojure.

This post is one of a series called Pre-conj Prep, which originally was published by email. It's all about getting ready for the upcoming Clojure/conj, organized by Cognitect. Conferences are ongoing conversations and explorations. Speakers discuss trends, best practices, and the future by drawing on the rich context built up in past conferences and other media.

That rich context is what Pre-conj Prep is about. I want to enhance everyone's experience at the conj by surfacing that context. With just a little homework, we can be better prepared to understand and enjoy the talks and the hallway conversations, as well as the beautiful venue and city of Washington, DC.

Clojure/conj is a conference organized and hosted by Cognitect. This information is in no way official. It is not sponsored by nor affiliated with Clojure/conj or Cognitect. It is simply me curating and organizing public information about the conference.

You might also like

Pre-Conj Interview: Lucas Cavalcanti

Introduction

I got in touch with Lucas Cavalcanti. He is giving a talk together at Clojure/conj with Edward Wible, who was unavailable. The background to their talk is available, if you like.

Interview

LispCast: How did you get into Clojure?

Lucas Cavalcanti: I've got into Clojure at Nubank, the company I currently work for, about a year ago. Nubank was already using Clojure, so I learnt it as we evolved the project. I was already familiar with Lisp syntax and knew functional programming very well, so the move to Clojure was not too hard.

LispCast: Can you explain a little about Nubank? And how do you use Datomic?

LC: Nubank is a tech company for financial services that just went public:

We use datomic as our primary database system, taking advantage of the free datomic transaction logs for auditing, and adding more data to improve auditing. We also use the datomic query language (based on datalog) to analyze data, often joining multiple databases, since we have a SOA with each service having its own database.

We also use some datomic capabilities to do database sync with mobile clients and cache management.

LispCast: Your talk's description mentions some "hidden superpowers of Datomic". You mention that the solutions to these problems are generic. Does that mean they can work for any problem?

LC: The solutions we'll provide will have some small assumptions to work, but these assumptions don't depend on the entities types we're saving, just something about the database structure. Thus we said the solutions are generic, and could work for any problem that matches these assumptions.

Also means that we can write just one function that will serve to implement one of that "superpowers" for all entities/endpoints of your system.

LispCast: So a lot of people are new to Clojure, and certainly to Datomic. Can you explain Datomic briefly for those of us who have never used it?

LC: If you know Git or any version control system, Datomic brings to a database many powers you have with Git: Think of each database transaction as a commit that generates another version of the database. So you can get the database value at any point in time, check the changes made by a specific transaction, all the history of a certain entity or even create "branches" of the database.

It works by collecting facts like "the entity 123 has the attribute :speaker/name with value "Lucas Cavalcanti"" and gives a query language based on datalog that, once you get the basic concepts, makes much more sense than any other query language I've worked with.

LispCast: So, is there anything else you think people should read up on to make the most of your talk?

LC: Read the docs: http://docs.datomic.com/index.html

Specially:

LispCast: Where can people follow your adventures online? Where do you socialize?

LC: I guess twitter @lucascs

LispCast: Ok. Last question: If Clojure and Ruby got together, what would they name their baby?

LC: http://en.wikipedia.org/wiki/Platypus

;)

"the (dis)functional duck typing" ;)

LispCast: Awesome! Thanks for a great interview. It was informative.


The Clojure/conj is going to be awesome. I've never been, but I have watched all of the videos from the prior conferences. I'm going this year, and you should, too! Go buy your tickets. There's some cool stuff happening there, including Opportunity Grants. Check out the Clojure/conj site and buy your tickets while they last. Clojure/conj is organized by Cognitect, the company behind Clojure.

This post is one of a series called Pre-conj Prep, which originally was published by email. It's all about getting ready for the upcoming Clojure/conj, organized by Cognitect. Conferences are ongoing conversations and explorations. Speakers discuss trends, best practices, and the future by drawing on the rich context built up in past conferences and other media.

That rich context is what Pre-conj Prep is about. I want to enhance everyone's experience at the conj by surfacing that context. With just a little homework, we can be better prepared to understand and enjoy the talks and the hallway conversations, as well as the beautiful venue and city of Washington, DC.

Clojure/conj is a conference organized and hosted by Cognitect. This information is in no way official. It is not sponsored by nor affiliated with Clojure/conj or Cognitect. It is simply me curating and organizing public information about the conference.

You might also like

Pre-Conj Interview: David Pick

Introduction

David Pick was kind enough to answer a few questions about himself and his upcoming Clojure/conj talk. You may want to read the background before you begin.

Interview

LispCast: How did you get into Clojure?

David Pick: A friend of my mine suggested I read Purely Functional Data Structures and told me the work in the book was the basis for Clojure's persistent data structures. I really enjoyed it and decided to give Clojure a try.

LC: Braintree must process a lot of very important data, since it's a payments service. What were you using before you developed the Clojure and Kafka system?

DP: I'd say for 98% of our systems we still use Ruby and Postgres, we're simply using Clojure and Kafka as a messaging platform to move data between systems.

LC: What is Kafka?

DP: Kafka is a system for doing publish subscribe messaging, that was built by LinkedIn to have extremely high throughput and replay ability of messages. It stores all messages sent through the system for a rolling window. So consumers simply say give me messages starting with offset n or whatever your most recent message is. This way if a receiving system goes down the consumer can just rewind the stream and replay messages that were missed.

LC: Could you describe the problem you were trying to solve? What were the requirements?

DP: There were actually two problems we were trying to solve. The first was to pull our search tool into a separate system that was more scalable than our current one (the current one just runs sql queries on main database). The second was to improve the accuracy and speed that our data warehouse is updated.

For the infrastructure part of the solution we ended up using Kafka, Zookeeper, and Elasticsearch which are all JVM based so that ended up heavily influencing our decision to use Clojure.

LC: You mentioned in the talk description that Clojure had certain advantages. What tradeoffs did Clojure, or your choice of technologies, bring about?

DP: The biggest tradeoff I think we made with Clojure is familiarity, I was the only one on the team who knew Clojure prior to starting this project. So that has certainly slowed us down. Other than that things have gone surprisingly well.

LC: I'm really fascinated by the engineering efforts to build very reliable and robust systems. Are you going to talk about that?

DP: Yep, that's the plan!

LC: Awesome.

Do you have any resources that would help someone new to Clojure or new to Kafka so that they can make the most of your talk? Some pre-reading or pre-watching materials?

DP: For Clojure I definitely recommend both the Clojure Koans and 4Clojure. For Kafka I'd recommend the introduction on their site.

LC: Where can people follow your adventures online?

DP: Twitter is probably the best place @davidpick.

LC: Who would win in a no-holds-barred fight to the finish, Clojure with an Arduino-controlled laser or a T-Rex?

DP: If Rich is writing the Clojure I give it a fighting chance, otherwise it's the T-Rex for sure.

LC: Awesome! Thanks for a great interview. I look forward to seeing you at the Conj.

DP: Awesome, thanks Eric!


The Clojure/conj is going to be awesome. I've never been, but I have watched all of the videos from the prior conferences. I'm going this year, and you should, too! Go buy your tickets. There's some cool stuff happening there, including Opportunity Grants. Check out the Clojure/conj site and buy your tickets while they last. Clojure/conj is organized by Cognitect, the company behind Clojure.

This post is one of a series called Pre-conj Prep, which originally was published by email. It's all about getting ready for the upcoming Clojure/conj, organized by Cognitect. Conferences are ongoing conversations and explorations. Speakers discuss trends, best practices, and the future by drawing on the rich context built up in past conferences and other media.

That rich context is what Pre-conj Prep is about. I want to enhance everyone's experience at the conj by surfacing that context. With just a little homework, we can be better prepared to understand and enjoy the talks and the hallway conversations, as well as the beautiful venue and city of Washington, DC.

Clojure/conj is a conference organized and hosted by Cognitect. This information is in no way official. It is not sponsored by nor affiliated with Clojure/conj or Cognitect. It is simply me curating and organizing public information about the conference.

You might also like

Pre-conj Prep: Zach Tellman

Talk: Always Be Composing

Zach Tellman's talk at the conj is about building composable software.

Background

People often boast of the composability of Clojure programs. Compojure claims that it "allows web application to be composed of small, independent parts." Ring itself is based on composing middleware and handlers to build a web server. In fact, you can compose pieces easily with Ring, if those pieces were designed to compose with Ring. But not all libraries compose well with the Ring ecosystem. This talk asks "How can we design libraries that compose well in general?" A good intro to composition in Clojure is Rich Hickey's talk Design, Composition, and Performance.

Why it matters

I often get asked why a certain library in Clojure doesn't have an easy interface like the one in Ruby. The answer, in many cases, is that the Clojure library was designed to compose with other code, while the Ruby library was meant for programmer convenience.

But if I leave it at that, this answer is unsatisfactory. Behind my answer is years of experience telling me that composition beats convenience in the long run. The asker of that question does not have that experience. I would love to have a way to explain why in an analytical way.

If this talk even so much as opens the conversation up about the design space of composition, it would be extremely helpful. But I'm expecting more from Zach Tellman. His talk could have a profound impact similar to Rich Hickey's talks on immutable values and simplicity.

About Zach Tellman

Github - Twitter


The Clojure/conj is going to be awesome. I've never been, but I have watched all of the videos from the prior conferences. I'm going this year, and you should, too! Go buy your tickets. There's some cool stuff happening there, including Opportunity Grants. Check out the Clojure/conj site and buy your tickets while they last. Clojure/conj is organized by Cognitect, the company behind Clojure.

This post is one of a series called Pre-conj Prep, which originally was published by email. It's all about getting ready for the upcoming Clojure/conj, organized by Cognitect. Conferences are ongoing conversations and explorations. Speakers discuss trends, best practices, and the future by drawing on the rich context built up in past conferences and other media.

That rich context is what Pre-conj Prep is about. I want to enhance everyone's experience at the conj by surfacing that context. With just a little homework, we can be better prepared to understand and enjoy the talks and the hallway conversations, as well as the beautiful venue and city of Washington, DC.

Clojure/conj is a conference organized and hosted by Cognitect. This information is in no way official. It is not sponsored by nor affiliated with Clojure/conj or Cognitect. It is simply me curating and organizing public information about the conference.

You might also like

Pre-conj Prep: Zach Oakes

Talk: Making Games at Runtime with Clojure

Zach Oakes' talk at the conj is about making games in a dynamic programming environment.

Background

Clojure, and Lisps in general, are famous for dynamic programming. That means being able to modify the program as it is running without restarting it. Wouldn't it be nice to develop games in this way? It seems like the perfect fit, since video games are so visual, you'd want to see what your code changes look like very quickly. This talk will explore this. Nightmod is a development environment written by Zach Oakes to modify a game in one window while it is running in another. It is based on the play-clj library, which he also wrote.

Why it matters

Game programming is a huge industry dominated by static languages with long code-compile-run cycles. Games cost millions of dollars to make, so even small improvements in developer productivity can save lots of money.

But further, games are hugely complex systems that are often on the cutting edge of programming. Functional programming has a lot to say about complex systems, yet there has not been a lot of functional programming in commercial games. The domain is ripe for exploration and discovery.

About Zach Oakes

Github

You can support Zach Oakes at Gratipay.


The Clojure/conj is going to be awesome. I've never been, but I have watched all of the videos from the prior conferences. I'm going this year, and you should, too! Go buy your tickets. There's some cool stuff happening there, including Opportunity Grants. Check out the Clojure/conj site and buy your tickets while they last. Clojure/conj is organized by Cognitect, the company behind Clojure.

This post is one of a series called Pre-conj Prep, which originally was published by email. It's all about getting ready for the upcoming Clojure/conj, organized by Cognitect. Conferences are ongoing conversations and explorations. Speakers discuss trends, best practices, and the future by drawing on the rich context built up in past conferences and other media.

That rich context is what Pre-conj Prep is about. I want to enhance everyone's experience at the conj by surfacing that context. With just a little homework, we can be better prepared to understand and enjoy the talks and the hallway conversations, as well as the beautiful venue and city of Washington, DC.

Clojure/conj is a conference organized and hosted by Cognitect. This information is in no way official. It is not sponsored by nor affiliated with Clojure/conj or Cognitect. It is simply me curating and organizing public information about the conference.

You might also like

Pre-conj Prep: Paul deGrandis

Talk: Unlocking Data-Driven Systems

Paul deGrandis' talk at the conj is about the design tradeoffs when building your system in a Data-Driven way.

Background

The recommended priority for choosing an implementation strategy is Data > Function > Macro. Macros are made for humans, not machines, so they are the least composable. Functions are composable, but opaque. Their only meaning is their side-effects and their return value. Data, however, can be interpreted in different ways, depending on the context. If one can design it right, a data-driven system can be both easy for a person to read and write and reusable for many problems.

This talk is part of an ongoing discussion about data-driven systems in Clojure. Data-driven design has been around far longer than Clojure has. Paradigms of Artificial Intelligence Programming is the book on the subject, showing its use in Common Lisp. Christophe Grand gave a talk at the Clojure/conj in 2010 that explained in depth why macros should not be the first choice when building DSLs.

Many systems use data as their primary interface. Datalog queries in Datomic are just Clojure data. Prismatic Schemas are data. Leiningen project files are data (with a small macro for human convenience). Data-driven system is related to code-as-data, that all Lisps share. If code is data, why can't data be code? Clojure makes data-driven solutions easy with its variety of literal data structures.

Why it matters

The conversation about how best to design data-driven systems is not over. Active Clojure developers are still experimenting and testing the approach. This talk will show data-driven systems taken to an extreme, where an entire ClojureScript application is represented as data. Many people already agree with the approach and are eagerly awaiting the deeper analysis this talk promises.

About Paul deGrandis

Github - Twitter


The Clojure/conj is going to be awesome. I've never been, but I have watched all of the videos from the prior conferences. I'm going this year, and you should, too! Go buy your tickets. There's some cool stuff happening there, including Opportunity Grants. Check out the Clojure/conj site and buy your tickets while they last. Clojure/conj is organized by Cognitect, the company behind Clojure.

This post is one of a series called Pre-conj Prep, which originally was published by email. It's all about getting ready for the upcoming Clojure/conj, organized by Cognitect. Conferences are ongoing conversations and explorations. Speakers discuss trends, best practices, and the future by drawing on the rich context built up in past conferences and other media.

That rich context is what Pre-conj Prep is about. I want to enhance everyone's experience at the conj by surfacing that context. With just a little homework, we can be better prepared to understand and enjoy the talks and the hallway conversations, as well as the beautiful venue and city of Washington, DC.

Clojure/conj is a conference organized and hosted by Cognitect. This information is in no way official. It is not sponsored by nor affiliated with Clojure/conj or Cognitect. It is simply me curating and organizing public information about the conference.

You might also like

Pre-conj Prep: Steven Yi

Talk: Developing Music Systems on the JVM with Pink and Score

Steven Yi's talk at the conj is about music systems on the JVM, focusing on two systems he built, called Pink and Score.

Background

Pink is a library for signal generation and processing and event handling. It is designed as a low-level library to use to build your own audio system. It is written in Clojure.

Score is a library for composing musical scores. Those scores are generic, so that they can be played by a variety of backend systems. Score is written in Clojure.

Why it matters

Electronic music is an interesting field. It is one that Lisp has been applied to for many years. To paraphrase Sam Aaron, creator of Overtone, Clojure's high-level allows a programmer to leverage programming ability to create better music. Pink and Score join Overtone and Rich Hickey's Harmonikit as music systems developed in Clojure.

About Steven Yi

Github - Twitter - Blog

Steven Yi is the author of the Blue Integrated Music Environment. He is also a core developer of Csound.


The Clojure/conj is going to be awesome. I've never been, but I have watched all of the videos from the prior conferences. I'm going this year, and you should, too! Go buy your tickets. There's some cool stuff happening there, including Opportunity Grants. Check out the Clojure/conj site and buy your tickets while they last. Clojure/conj is organized by Cognitect, the company behind Clojure.

This post is one of a series called Pre-conj Prep, which originally was published by email. It's all about getting ready for the upcoming Clojure/conj, organized by Cognitect. Conferences are ongoing conversations and explorations. Speakers discuss trends, best practices, and the future by drawing on the rich context built up in past conferences and other media.

That rich context is what Pre-conj Prep is about. I want to enhance everyone's experience at the conj by surfacing that context. With just a little homework, we can be better prepared to understand and enjoy the talks and the hallway conversations, as well as the beautiful venue and city of Washington, DC.

Clojure/conj is a conference organized and hosted by Cognitect. This information is in no way official. It is not sponsored by nor affiliated with Clojure/conj or Cognitect. It is simply me curating and organizing public information about the conference.

You might also like

Willy Wonka and the core.async Guidelines

Summary: There are a few conventions in core.async that are not hard to use once you've learned them. But learning them without help can be tedious. This article presents three guidelines that will get you through the learning curve.

Willy Wonka, inventor of CSP.

Willy Wonka, inventor of CSP.

Introduction

The more you use core.async, the more you feel like Willy Wonka. He knew how to maximize the effectiveness of the Oomploompa. And while core.async comes with a lot of functions built in, he knew exactly which ones to use at which time.

In this extremely rare glimpse into the functioning of his mysterious factory, we take a look at the guidelines Wonka himself follows when orchestrating the work of the Oompaloompas.

When to use go versus thread?

Willy Wonka with his Thread Pool.

Willy Wonka with his Thread Pool.

Background

Each Oompaloompa is a thread. Willy Wonka has a special group of Oompaloompas he calls a thread pool. Their assigment is simple: they manage a group of tasks that Wonka calls go blocks. Whenever Wonka has an appropriate task, he writes a go block and hands it to the Oompaloompas to work on.

As the Oompaloompas work, they take one task and do it until the task parks. When it parks, they put it down and pick up another task that isn't parked. Tasks become unparked when they get new input from the chocolate pipes. Then the Oompaloompas can continue working on them.

At one time, Wonka used to give the thread pool all sorts of tasks. He would give them very long calculation tasks, like weighing each chocolate bean in his chocolate bean mountain. He noticed that when they did this, lots of tasks were left undone, even though they were not parked, because all of the Ooompaloompas were busy doing something else.

So he came up with a guideline.

Avoid long calculations and blocking inside go blocks

Does your code do significant I/O, like downloading a file or writing to the network? Are you doing a very long calculation?

Then use a thread. If it will take a long time or block, you want a dedicated thread. It can work as long as it wants, and even block. That way it doesn't slow down the work of the thread pool.

Otherwise, you can use a go block.

When to use single- versus double-bang (!)

A couple of blocked Oompaloompas.

A couple of blocked Oompaloompas.

Background

Wonka also noticed that he needed to write different instructions for his two types of Oompaloompa. When he wrote a go block, he needed to say "park while you wait for input". But for the other Oompaloompas created with thread (or for his own work), he needed an instruction that said "block while you wait for input".

So he came up with a little notation convention. If you're just parking, so you're in a go block, use one bang. If you're outside of a go block, meaning you need to block, use two bangs.

These were his versions of his basic instructions:

>!, <!, and alts! versus >!!, <!!, and alts!!. The convention is easy.

Use single-bang versions in go blocks and double-bang versions outside.

The single-bang versions of these functions are meant to park a go block. Although they are defined as functions, they have special meaning to the go macro. In fact, if you actually run the functions (outside of a go block), they will throw an exception unconditionally, telling you they are meant to be inside a go block.

The double-bang versions are blocking. That means that the thread they are running on will block if the channel is not ready. They can be used outside of a go block (anywhere) or inside of a thread block. It's safe to block inside a thread block since it's a dedicated thread.

put!

Willy Wonka writing instructions for his mailman.

Willy Wonka writing instructions for his mailman.

Background

Like all factories, Willy Wonka's needs deliveries. When the UPS truck comes, there's plenty of boxes to unload. But Wonka is busy. So he leaves a note outside for the delivery guy.

The note tells the guy where to put everything so the Oompaloompas know where to find it. When he says where to put a box, he spells it put!. That is, it has a bang.

It's unfortunate because the other functions with a bang mean they park. But put! does not park. Wonka was just angry one day, and the convention stuck.

But the delivery guy knows that Wonka is eccentric, so he doesn't take it personally and does his job. He puts stuff in its places, without blocking.

Use put! to get stuff into your channels from outside.

put! is a way to get values from outside of core.async into core.async without blocking. For instance, if you're using a callback-style, which is very common in Javascript, you will want to make your callback call put! to get the value onto a channel.

Conclusion

That's it! Now to eat some chocolate!

core.async is really cool, but it has a learning curve. Once you learn these conventions, you will begin to feel the power they give you, whether you're making chocolate or building cars. If you'd like to learn core.async and feel like Willy Wonka, I recommend the LispCast Clojure core.async videos. They build up a deep understanding of the fundamental concepts in a fun and gradual way.

You might also like

Pre-conj Prep: Steve Miner

Talk: Generating Generators

Steve Miner's talk at the conj is about automatically creating test.check generators from a data-driven schema.

Background

Steve Miner is the author of the Herbert schema library. In Herbert, schemas are presented as plain EDN. They describe the structure and type of data. You can take a value and validate that it conforms to the schema. He is going to present a way to generate test.check generators from the schema. This way, you can do runtime checks and test-time checks. A good intro to Herbert is Steve Miner's lightning talk from Clojure/conj last year. Reid Draper gave a talk about test.check at Clojure/West.

Why it matters

test.check contains a set of combinators to create new generators from existing generators. But combinators are not very easy to read or write when the data they are generating is fairly complex. Being able to generate them automatically from a declarative, data-driven style is one way to make it easier.

Besides being easier, it also unifies the contracts (schema validation in function preconditions) with generative testing. The next domino would have to be building core.typed type signatures from the same data.

About Steve Miner

Github - Twitter


The Clojure/conj is going to be awesome. I've never been, but I have watched all of the videos from the prior conferences. I'm going this year, and you should, too! Go buy your tickets. There's some cool stuff happening there, including Opportunity Grants. Check out the Clojure/conj site and buy your tickets while they last. Clojure/conj is organized by Cognitect, the company behind Clojure.

This post is one of a series called Pre-conj Prep, which originally was published by email. It's all about getting ready for the upcoming Clojure/conj, organized by Cognitect. Conferences are ongoing conversations and explorations. Speakers discuss trends, best practices, and the future by drawing on the rich context built up in past conferences and other media.

That rich context is what Pre-conj Prep is about. I want to enhance everyone's experience at the conj by surfacing that context. With just a little homework, we can be better prepared to understand and enjoy the talks and the hallway conversations, as well as the beautiful venue and city of Washington, DC.

Clojure/conj is a conference organized and hosted by Cognitect. This information is in no way official. It is not sponsored by nor affiliated with Clojure/conj or Cognitect. It is simply me curating and organizing public information about the conference.

You might also like

Pre-conj Prep: Nathan Herzing and Chris Shea

Talk: Helping voters with Pedestal, Datomic, Om and core.async

Nathan Herzing and Chris Shea's talk at the conj is about using Pedestal, Om, Datomic, and core.async together. They promise to code systems live.

Background

Pedestal was the name for a frontend framework create by Cognitect. They deprecated that framework and used the name for a small piece of it that was libraries for backend web servers, which is now under development. So Pedestal now is a set of libraries for web development. Watch this Webcast for background.

Datomic is Cognitect's append-only database with Datalog queries. A nice introduction is this talk by Rich Hickey.

Om is a library in ClojureScript created by David Nolen. It is a wrapper around React, which is Facebook's library for manipulating the DOM in a functional way. Watch David Nolen's talk for a good introduction.

core.async is a library that brings Communicating Sequential Processes to Clojure and ClojureScript. A great talk on it is one by Rich Hickey.

Why it matters

I've said before that I like experience reports. This one will also combine it with live coding, which is exciting. Live coding is always a risk. This talk will combine four of the major components Clojure brings to the table, which are all very powerful in their own right. What will happen when their powers combine?

About Nathan Herzing

Github

About Chris Shea

Github


The Clojure/conj is going to be awesome. I've never been, but I have watched all of the videos from the prior conferences. I'm going this year, and you should, too! Go buy your tickets. There's some cool stuff happening there, including Opportunity Grants. Check out the Clojure/conj site and buy your tickets while they last. Clojure/conj is organized by Cognitect, the company behind Clojure.

This post is one of a series called Pre-conj Prep, which originally was published by email. It's all about getting ready for the upcoming Clojure/conj, organized by Cognitect. Conferences are ongoing conversations and explorations. Speakers discuss trends, best practices, and the future by drawing on the rich context built up in past conferences and other media.

That rich context is what Pre-conj Prep is about. I want to enhance everyone's experience at the conj by surfacing that context. With just a little homework, we can be better prepared to understand and enjoy the talks and the hallway conversations, as well as the beautiful venue and city of Washington, DC.

Clojure/conj is a conference organized and hosted by Cognitect. This information is in no way official. It is not sponsored by nor affiliated with Clojure/conj or Cognitect. It is simply me curating and organizing public information about the conference.

You might also like