Learn Clojure – Clojure Koans Walkthrough in Light Table IDE
You have heard of Clojure and no doubt the Clojure Koans.
Now there are videos solving the Clojure Koans using the Light Table IDE.
I first saw this at Clojure Koans by Christopher Bare.
April 18, 2014
April 17, 2014
Clojure Procedural Dungeons
From the webpage:
When making games, there are two ways to make a dungeon. The common method is to design one in the CAD tool of our choice (or to draw one in case of 2D games).
The alternative is to automatically generate random Dungeons by using a few very powerful algorithms. We could automatically generate a whole game world if we wanted to, but let’s take one step after another.
In this Tutorial we will implement procedural Dungeons in Clojure, while keeping everything as simple as possible so everyone can understand it.
Just in case you are interesting in a gaming approach for a topic maps interface.
Not as crazy as that may sound. One of the brightest CS types I ever knew spend a year playing a version of Myst from start to finish.
Think about app sales if you can make your interface addictive.
Suggestion: Populate your topic map authoring interface with trolls (accounting), smiths (manufacturing), cavalry (shipping), royalty (managment), wizards (IT), etc. and make collection of information about their information into tokens, spells, etc. Sprinkle in user preference activities and companions.
That would be a lot of work but I suspect you would get volunteers to create new levels as your information resources evolve.
Comments Off on Clojure Procedural Dungeons
April 16, 2014
Hitchhiker’s Guide to Clojure
From the webpage:
The following is a cautionary example of the unpredictable combination of Clojure, a marathon viewing of the BBC’s series “The Hitchhiker’s Guide to the Galaxy”, and a questionable amount of cheese.
There have been many tourism guides to the Clojure programming language. Some that easily come to mind for their intellectual erudition and prose are “The Joy of Touring Clojure”, “Touring Clojure”, “Clojure Touring”, and the newest edition of “Touring Clojure Touring”. However, none has surpassed the wild popularity of “The Hitchhiker’s Guide to Clojure”. It has sold over 500 million copies and has been on the “BigInt’s Board of Programming Language Tourism” for the past 15 years. While, arguably, it lacked the in-depth coverage of the other guides, it made up for it in useful practical tips, such as what to do if you find a nil in your pistachio. Most of all, the cover had the following words printed in very large letters: Don’t Worry About the Parens.
To tell the story of the book, it is best to tell the story of two people whose lives were affected by it: Amy Denn, one of the last remaining Pascal developers in Cincinnati, and Frank Pecan, a time traveler, guidebook researcher, and friend of Amy.
There isn’t any rule (that I’m aware of) that says computer texts must be written to be unfunny.
I think my only complaint is that the story is too short. 😉
Enjoy!
Comments Off on Hitchhiker’s Guide to Clojure
April 13, 2014
Clojure and Storm
Two recent posts by Charles Ditzel, here and here, offer pointers to resources on Clojure and Storm.
For your reading convenience:
Storm Apache site.
Building an Activity Feed Stream with Storm Recipe from the Clojure Cookbook.
Storm: distributed and fault-tolerant realtime computation by Nathan Marz. (Presentation, 2012)
StormScreenCast2 Storm in use at Twitter (2011)
Enjoy!
Comments Off on Clojure and Storm
April 10, 2014
Using Datomic as a Graph Database
Using Datomic as a Graph Database by Joshua Davey.
From the post:
Datomic is a database that changes the way that you think about databases. It also happens to be effective at modeling graph data and was a great fit for performing graph traversal in a recent project I built.
I started out building kevinbacon.us using Neo4j, a popular open-source graph database. It worked very well for actors that were a few hops away, but finding paths between actors with more than 5 hops proved problematic. The cypher query language gave me little visibility into the graph algorithms actually being executed. I wanted more.
Despite not being explicitly labeled as such, Datomic proved to be an effective graph database. Its ability to arbitrarily traverse datoms, when paired with the appropriate graph searching algorithm, solved my problem elegantly. This technique ended up being fast as well.
Quick aside: this post assumes a cursory understanding of Datomic. I won’t cover the basics, but the official tutorial will help you get started.
….
If you are interested in Datomic, Clojure, functional programming, or graphs, this is a must read for you.
Not to spoil any surprises but Joshua ends up with excellent performance.
I first saw this in a tweet by Atabey Kaygun.
Comments Off on Using Datomic as a Graph Database
Binary Search Trees (Clojure)
Data Structures in Clojure: Binary Search Trees by Max Countryman.
From the post:
Trees Everywhere
So far we have talked about two fundamental and pervasive data structures: linked lists and hash tables. Here again we discuss another important data structure and one that you will find is quite common: trees. Trees offer a powerful way of organizing data and approaching certain problems. In particular, searching and traversal. Whether you know it or not, you no doubt use trees in your programs today. For instance, Clojure’s vectors are backed by a special kind of tree!
Here we will construct our own tree, just like with our linked list and hash table implementations. Specifically, our tree will be a kind of tree known as a Binary Search Tree (BST). Often when someone says tree, they mean a BST.
We will look the basic structure of our tree, how we insert things into it, and how we find them again. Then we will explore traversing, and finally, removing nodes. At the end of this tutorial you will have a basic, functioning Binary Search Tree, which will be the basis for further explorations later on in this series.
…
Another installment by Max on data structures in Clojure.
Enjoy!
Comments Off on Binary Search Trees (Clojure)
April 9, 2014
clortex
clortex – Clojure Library for Jeff Hawkins’ Hierarchical Temporal Memory
From the webpage:
Hierarchical Temporal Memory (HTM) is a theory of the neocortex developed by Jeff Hawkins in the early-mid 2000’s. HTM explains the working of the neocortex as a hierarchy of regions, each of which performs a similar algorithm. The algorithm performed in each region is known in the theory as the Cortical Learning Algorithm (CLA).
Clortex is a reimagining and reimplementation of Numenta Platfrom for Intelligent Computing (NuPIC), which is also an Open Source project released by Grok Solutions (formerly Numenta), the company founded by Jeff to make his theories a practical and commercial reality. NuPIC is a mature, excellent and useful software platform, with a vibrant community, so please join us at Numenta.org.
Warning: pre-alpha software. This project is only beginning, and everything you see here will eventually be thrown away as we develop better ways to do things. The design and the APIs are subject to drastic change without a moment’s notice.
Clortex is Open Source software, released under the GPL Version 3 (see the end of the README). You are free to use, copy, modify, and redistribute this software according to the terms of that license. For commercial use of the algorithms used in Clortex, please contact Grok Solutions, where they’ll be happy to discuss commercial licensing.
An interesting project both in terms of learning theory but also for the requirements for the software implementing the theory.
The first two requirements capture the main points:
2.1 Directly Analogous to HTM/CLA Theory
In order to be a platform for demonstration, exploration and experimentation of Jeff Hawkins’ theories, the system must at all levels of relevant detail match the theory directly (ie 1:1). Any optimisations introduced may only occur following an effectively mathematical proof that this correspondence is maintained under the change.
…
2.2 Transparently Understandable Implementation in Source Code
All source code must at all times be readable by a non-developer. This can only be achieved if a person familiar with the theory and the models (but not a trained programmer) can read any part of the source code and understand precisely what it is doing and how it is implementing the algorithms.
This requirement is again deliberately very stringent, and requires the utmost discipline on the part of the developers of the software. Again, there are several benefits to this requirement.
Firstly, the extreme constraint forces the programmer to work in the model of the domain rather than in the model of the software. This constraint, by being adhered to over the lifecycle of the project, will ensure that the only complexity introduced in the software comes solely from the domain. Any other complexity introduced by the design or programming is known as incidental complexity and is the cause of most problems in software.
Secondly, this constraint provides a mechanism for verifying the first requirement. Any expert in the theory must be able to inspect the code for an aspect of the system and verify that it is transparently analogous to the theory.
Despite my misgivings about choosing the domain in which you stand, I found it interesting the project recognizes the domain of its theory and the domain of software to implement that theory are separate and distinct.
How closely two distinct domains can be mapped one to the other should be an interesting exercise.
BTW, some other resources you will find helpful:
NuPic – Numenta Platform for Intelligent Computing
Cortical Learning Algorithm (CLA) white paper in eight languages.
March 28, 2014
Clojure/West 2014 Videos
I first saw this at: Clojure/West 2014 Presentations : A Wonderful Stack Now Available by Charles Ditzel.
I cleaned up the listing at Youtube and put the authors in order by last name.
Don’t you think it is odd that Youtube has such poor sorting options?
Or am I missing a “secret” button somewhere?
- Timothy Baldridge – Data All The ASTs
- Aaron Bedra – clojure.web/with-security
- Brandon Bloom – Dendrology
- Matt Bossenbroek – PigPen: Map-Reduce for Clojure
- Aaron Brooks – lein-voom: Projects Want to Be Values
- Alan Dipert & Micha Niskin – Web Programming with Hoplon
- Reid Draper – Powerful Testing with test.check
- Chas Emerick – Targeting Clojure & ClojureScript from a Single Codebase
- Mark Engelberg – Instaparse
- Ian Eslick – Probe: Program Traces as First Class State
- Daniel Glauser & Denise Zimmerman – Beginner’s Luck
- Dave Golland – Wiring Prismatic's API with fnHouse and Coax
- Daniel Solano Gomez – How Clojure Works: Understanding the Clojure Runtime
- Aysylu Greenberg – Loom and Graphs in Clojure
- David Greenberg – Building Interactive Query Tools on Datomic
- Bridget Hillyer – ClojureBridge | Jennifer Eliuk – Apprenticeships, I Implore You
- John Hughes – Testing the Hard Stuff and Staying Sane
- Alice Liang – How to grow your own distributed array database
- Alex Miller – State of Clojure
- Nelson Morris – Extending Leiningen to Make it Do What you Want
- Priyatam Mudivarti – The Poem as Value
- David Nolen – The Functional Final Frontier
- Andrew Nguyen – Healthcare "big" Data from Data Management to Web Apps
- Vincent Rivellino: DevOps Done Right – Room Key’s Datomic Deployment in AWS
- Stuart Sierra – Components Just Enough Structure
- Zach Tellman – Predictably Fast Clojure
- Travis Vachon – cljs All The Things: Full Stack Apps with ClojureScript
Comments Off on Clojure/West 2014 Videos
A Practical Optional Type System for Clojure [Types for Topic Maps?]
A Practical Optional Type System for Clojure by Ambrose Bonnaire-Sergeant.
Abstract:
Dynamic programming languages often abandon the advantages of static type checking in favour of their characteristic convenience and flexibility. Static type checking eliminates many common user errors at compile-time that are otherwise unnoticed, or are caught later in languages without static type checking. A recent trend is to aim to combine the advantages of both kinds of languages by adding optional static type systems to languages without static type checking, while preserving the idioms and style of the language.
This dissertation describes my work on designing an optional static type system for the Clojure programming language, a dynamically typed dialect of Lisp, based on the lessons learnt from several projects, primarily Typed Racket. This work includes designing and building a type checker for Clojure running on the Java Virtual Machine. Several experiments are conducted using this prototype, particularly involving existing Clojure code that is sufficiently complicated that type checking increases confidence that the code is correct. For example, nearly all of algo.monads, a Clojure Contrib library for monadic programming, is able to be type checked. Most monad, monad transformer, and monadic function definitions can be type checked, usually by adding type annotations in natural places like function definitions.
There is significant future work to fully type check all Clojure features and idioms. For example, multimethod definitions and functions with particular constraints on the number of variable arguments they accept (particularly functions taking only an even number of variable arguments) are troublesome. Also, there are desirable features from the Typed Racket project that are missing, such as automatic runtime contract generation and a sophisticated blame system, both which are designed to improve error messages when mixing typed and untyped code in similar systems.
Overall, the work described in this dissertation leads to the conclusion that it appears to be both practical and useful to design and implement an optional static type system for the Clojure programming language.
Information retrieval that relies upon merging representatives of the same subject would benefit from type checking.
In XTM we rely upon string equivalence of URIs for merging of topics. Leaves you will visual inspection to audit merging.
I could put:
http://www.durusau.net/general/background.html, and
http://en.wikipedia.org/wiki/Lion_king
as subject identifiers in a single topic and a standard XTM processor would merrily merge topics with those subject identifiers together.
Recalling the rules of the TMDM to be:
Equality rule:
Two topic items are equal if they have:
- at least one equal string in their [subject identifiers] properties,
- at least one equal string in their [item identifiers] properties,
- at least one equal string in their [subject locators] properties,
- an equal string in the [subject identifiers] property of the one topic item and the [item identifiers] property of the other, or
- the same information item in their [reified] properties.
Adding data types to subject identifiers could alert authors to merge errors long before they may or may not be discovered by users.
Otherwise merge errors in topic maps may lay undetected and uncorrected for some indeterminate period of time. (Sounds like software bugs doesn’t it?)
I first saw this in a tweet by mrb.
Comments Off on A Practical Optional Type System for Clojure [Types for Topic Maps?]
March 25, 2014
Is Parallel Programming Hard,…
Is Parallel Programming Hard, And, If So, What Can You Do About It? by Paul E. McKenney.
From Chapter 1 How To Use This Book:
The purpose of this book is to help you understand how to program shared-memory parallel machines without risking your sanity.[1] By describing the algorithms and designs that have worked well in the past, we hope to help you avoid at least some of the pitfalls that have beset parallel-programming projects. But you should think of this book as a foundation on which to build, rather than as a completed cathedral. Your mission, if you choose to accept, is to help make further progress in the exciting field of parallel programming—progress that should in time render this book obsolete. Parallel programming is not as hard as some say, and we hope that this book makes your parallel-programming projects easier and more fun.
In short, where parallel programming once focused on science, research, and grand-challenge projects, it is quickly becoming an engineering discipline. We therefore examine the specific tasks required for parallel programming and describe how they may be most effectively handled. In some surprisingly common special cases, they can even be automated.
This book is written in the hope that presenting the engineering discipline underlying successful parallel-programming projects will free a new generation of parallel hackers from the need to slowly and painstakingly reinvent old wheels, enabling them to instead focus their energy and creativity on new frontiers. We sincerely hope that parallel programming brings you at least as much fun, excitement, and challenge that it has brought to us!
I should not have been surprised by:
16.4 Functional Programming for Parallelism
When I took my first-ever functional-programming class in the early 1980s, the professor asserted that the side- effect-free functional-programming style was well-suited to trivial parallelization and analysis. Thirty years later, this assertion remains, but mainstream production use of parallel functional languages is minimal, a state of affairs that might well stem from this professor’s additional assertion that programs should neither maintain state nor do I/O. There is niche use of functional languages such as Erlang, and multithreaded support has been added to several other functional languages, but mainstream production usage remains the province of procedural languages such as C, C++, Java, and FORTRAN (usually augmented with OpenMP or MPI).
The state of software vulnerability is testimony enough to the predominance of C, C++, and Java.
I’m not real sure I would characterize Erlang as a “niche” language. Niche languages aren’t often found running telecommunications networks, or at least that is my impression.
I would take McKenney’s comments as a challenge to use functional languages such as Clojure and Erlang to make in-roads into mainstream production.
While you use this work to learn the procedural approach to parallelism, you can be building contrasts to a functional one.
I first saw this in Nat Torkington’s Four short links: 13 March 2014.
Comments Off on Is Parallel Programming Hard,…
March 24, 2014
Understanding Clojure’s Persistent Vectors, pt. 1
Understanding Clojure’s Persistent Vectors, pt. 1 by Jean Niklas L’orange.
From the post:
You may or may not heard about Clojure’s persistent vectors. It is a data structure invented by Rich Hickey (influenced by Phil Bagwell’s paper on Ideal Hash Trees) for Clojure, which gives practically O(1) runtime for insert, update, lookups and subvec. As they are persistent, every modification creates a new vector instead of changing the old one.
So, how do they work? I’ll try to explain them through a series of blogposts, in which we look at manageable parts each time. It will be a detailed explanation, with all the different oddities around the implementation as well. Consequently, this blog series may not be the perfect fit for people who want a “summary” on how persistent vectors work.
For today, we’ll have a look at a naive first attempt, and will cover updates, insertion and popping (removal at the end).
Note that this blogpost does not represent how PersistentVector is implemented: There are some speed optimizations, solutions for transients and other details which we will cover later. However, this serves as a basis for understanding how they work, and the general idea behind the vector implementation.
….
The sort of post that makes you start wondering why we don’t have a persistent data model for XTM based topic maps?
With persistent we get to drop all the creating new identifiers on merges, creating sets of identifiers, determining if sets of identifiers intersect, to say nothing of having persistent identifiers for interchange of data with other topic maps. A topic’s identifier is its identifier today, tomorrow and at any time to which it is persisted.
To say nothing of having an audit trail for additions/deletions plus “merges.”
While you are considering those possibilities, see: Understanding Clojure’s Persistent Vectors, pt. 2
Comments Off on Understanding Clojure’s Persistent Vectors, pt. 1
March 20, 2014
Clojure Cookbook has arrived!
From the webpage:
Over the past year, the Clojure community came together to write a wondrous tome chock full of their collective knowledge. At over 70 contributors, 1600 commits and nearly 200 recipes, this is something special, folks.
Clojure’s very own crowd-sourced cookbook, Clojure Cookbook, is available now.
The author’s are accepting pull requests at: https://github.com/clojure-cookbook/clojure-cookbook.
Must be already planning on a second edition! 😉
Don’t be shy!
Enjoy!
Comments Off on Clojure Cookbook has arrived!
March 8, 2014
Building a Database-backed Clojure Web App…
Building a Database-backed Clojure Web App On Top of Heroku Cloud App Platform by Charles Ditzel.
From the post:
Some time ago I wrote a post about Java In the Auto-Scaling Cloud. In the post, I mentioned Heroku. In today’s post, I want to take time to point back to Heroku again, this time with the focus on building web applications. Heroku Dev Center recently posted a great tutorial on building a databased-backed Clojure web application. In this example, a twitter-like app is built that stores “shouts” to a PostgreSQL database. It covers a lot of territory, from connecting to PostgreSQL, to web bindings with Compujure, HTML tempting with Hiccup and assembling the application and testing it. Finally, deploying it.
…
If you aren’t working on a weekend project already, here is one for your consideration!
Comments Off on Building a Database-backed Clojure Web App…
February 23, 2014
Architecture Matters…
Architecture Matters : Building Clojure Services At Scale At SoundCloud by Charles Ditzel.
Charles points to three posts on Clojure services at scale:
Building Clojure Services at Scale by Joseph Wilk.
Architecture behind our new Search and Explore experience by Petar Djekic.
Evolution of SoundCloud’s Architecture by Sean Treadway.
If you aren’t already following Charle’s blog (I wasn’t, am now), you should be.
Comments Off on Architecture Matters…
February 17, 2014
Introduction to Clojure – Modern dialect of Lisp (Part 1)
Introduction to Clojure – Modern dialect of Lisp (Part 1) by Ricardo Sanchez and Karsten Schmidt.
A tutorial with lots of references is a good sign. The authors are not afraid for you to look elsewhere for information. They know you will be back.
To give the authors time to write part 2, there is a healthy selection of further reading and other resources at the end of part 1.
Enjoy!
Comments Off on Introduction to Clojure – Modern dialect of Lisp (Part 1)
February 14, 2014
Clojure 1.6.0-beta1
Clojure 1.6.0-beta1 by Alex Miller.
From the post:
Clojure 1.6.0-beta1 is now available.
Try it via
– Download: http://central.maven.org/maven2/org/clojure/clojure/1.6.0-beta1
– Leiningen: [org.clojure/clojure “1.6.0-beta1”]Highlights below or see the full change log here:
https://github.com/clojure/clojure/blob/master/changes.mdWe expect Clojure 1.6.0-beta1 to be close to a release candidate; no other big changes are planned. Please give us your feedback and final issues if you find them so we can do the final release!
Just in time for the weekend, particularly if you like checking beta releases for “issues.”
Enjoy!
Comments Off on Clojure 1.6.0-beta1
February 13, 2014
Reasoned Programming
Reasoned Programming by Krysia Broda, Susan Eisenbach, Hessam Khoshnevisan, and Steve Vickers.
From the preface:
Can we ever be sure that our computer programs will work reliably? One approach to this problem is to attempt a mathematical proof of reliability, and this has led to the idea of Formal Methods: if you have a formal, logical specification of the properties meant by `working reliably’, then perhaps you can give a formal mathematical proof that the program (presented as a formal text) satisfies them.
Of course, this is by no means trivial. Before we can even get started on a formal proof we must turn the informal ideas intended by `working reliably’ into a formal specification, and we also need a formal account of what it means to say that a program satisfies a specification (this amounts to a semantics of the programming language, an account of the meaning of programs). None the less, Formal Methods are now routinely practised by a number of software producers.
However, a tremendous overhead derives from the stress on formality, that is to say, working by the manipulation of symbolic forms. A formal mathematical proof is a very different beast from the kind of proof that you will see in mathematical text books. It includes the minutest possible detail, both in proof steps and in background assumptions, and is not for human consumption &emdash; sophisticated software support tools are needed to handle it. For this reason, Formal Methods are often considered justifiable only in `safety critical’ systems, for which reliability is an overriding priority.
The aim of this book is to present informal formal methods, showing the benefits of the approach even without strict formality: although we use logic as a notation for the specifications, we rely on informal semantics &emdash; a programmer’s ordinary intuitions about what small, linear stretches of code actually do &emdash; and we use proofs to the level of rigour of ordinary mathematics.
A bit dated (1994) and teaches Miranda, a functional programming language and uses it to reason about imperative programming.
Even thinking about a “specification” isn’t universally admired these days but the author’s cover that point when they say:
This `precise account of the users’ needs and wants’ is called a specification, and the crucial point to understand is that it is expressing something quite different from the code, that is, the users’ interests instead of the computer’s. If the specification and code end up saying the same thing in different ways &emdash; and this can easily happen if you think too much from the computer’s point of view when you specify &emdash; then doing both of them is largely a waste of time. (emphasis added, Chapter 1, Section 1.3)
That’s blunt enough. 😉
You can pick up Miranda, homesite or translate the examples into a more recent functional language, Clojure comes to mind.
I first saw this in a tweet by Computer Science.
Comments Off on Reasoned Programming
February 9, 2014
Introducing PigPen: Map-Reduce for Clojure
Introducing PigPen: Map-Reduce for Clojure by Matt Bossenbroek.
From the post:
It is our pleasure to release PigPen to the world today. PigPen is map-reduce for Clojure. It compiles to Apache Pig, but you don’t need to know much about Pig to use it.
What is PigPen?
- A map-reduce language that looks and behaves like clojure.core
- The ability to write map-reduce queries as programs, not scripts
- Strong support for unit tests and iterative development
Note: If you are not familiar at all with Clojure, we strongly recommend that you try a tutorial here, here, or here to understand some of the basics.
Not a quick read but certainly worth the effort!
Comments Off on Introducing PigPen: Map-Reduce for Clojure
February 8, 2014
Clojure: Programming with Hand Tools
Clojure: Programming with Hand Tools by Tim Ewald.
From the description:
For most of human history, furniture was built by hand using a small set of simple tools. This approach connects you in a profoundly direct way to the work, your effort to the result. This changed with the rise of machine tools, which made production more efficient but also altered what’s made and how we think about making it in in a profound way. This talk explores the effects of automation on our work, which is as relevant to software as it is to furniture, especially now that once again, with Clojure, we are building things using a small set of simple tools.
Tim Ewald designs and builds software systems. After 20 years using object oriented languages, he embraces Clojure because it provides the closes connection to the work and most directly expresses his intent. Tim works on the Datomic team at Cognitect, where he is a Vice President.
If Simon St. Laurent didn’t see this presentation live, he will appreciate this video.
I suspect you will come away with a new appreciation for how our tools and expectations shape the solutions we “see.”
But more than that, with time and effort, you may start to notice the edges of our present tools and expectations, so you can roll them back.
What lies beyond remains for you to discover.
Comments Off on Clojure: Programming with Hand Tools
February 7, 2014
Making Music with Clojure – An Introduction to MIDI
Making Music with Clojure – An Introduction to MIDI by @taylodl’s.
From the post:
This post takes a break from Functional JavaScript and has a little fun making music. We’re going to be using Clojure, a Lisp language for the JVM, so that we can utilize the JVM’s MIDI implementation. No experience with music or MIDI is required though a familiarity with Clojure or any other Lisp is helpful.
I’m using Clojure for its functional similarities to JavaScript—the syntax of the languages are different but the underlying programming philosophies are similar. For this post I’m assuming you already have Clojure and Leiningen installed on your system. See Clojure Quick Start for everything you need to get Clojure and Leiningen installed and running on your system.
Once you have everything installed you can create a new midi-sequencer project by executing:
…
Accessibility, that is what I like about this post. Being innocent of any musical playing ability, the history of music remains silent for me unless I can find a recording. Or program a computer to perform it.
MIDI production isn’t the same thing as a live or recorded performance by a real musician, but it is better than a silent page.
Enjoy!
PS: Not all extant music is recorded or performed. Some resources to explore:
Digital Image Archive of Medieval Music
Music Manuscripts (British Library)
Music Manuscripts Online (The Morgan Library & Museum, 42,000 pages)
Comments Off on Making Music with Clojure – An Introduction to MIDI
February 6, 2014
Datomic R-trees
Datomic R-trees by James Sofra.
From the description:
Slides for a talk given at Melbourne Functional Users Group on an R-tree based spatial indexer for Datomic.
The slides do a good job explaining the advantages of Datomic for spatial data and using R-trees with it.
References from the slides that you will find helpful:
R-TREES. A Dynamic Index Structure for Spatial Searching. A. Guttman (1984)
Sort-based query-adaptive loading of R-trees, Daniar Achakeev, Bernhard Seeger, Peter Widmayer. (2012)
Sort-based parallel loading of R-trees, Daniar Achakeev, Marc Seidemann, Markus Schmidt, Bernhard Seeger. (2012)
The R*-tree: an efficient and robust access method for points and rectangles (1990), by Norbert Beckmann , Hans-Peter Kriegel , Ralf Schneider , Bernhard Seeger. (1990)
OMT: Overlap Minimizing Top-down Bulk Loading Algorithm for R-tree, Taewon Lee, Sukho Lee. (2003)
The Priority R-Tree: A Practically Efficient and Worst-Case Optimal R-Tree, Lars Arge. (2004)
Compact Hilbert indices, Christopher Hamilton. (2006)
R-Trees: Theory and Applications, Yannis Manolopoulos, Alexandros Nanopoulos, Apostolos N. Papadopoulos and Yannis Theodoridis. (2006)
See also: https://github.com/jsofra/datomic-rtree
Comments Off on Datomic R-trees
February 4, 2014
Data Structures in Clojure:…
Data Structures in Clojure: Singly-Linked Lists by Max Countryman.
From the post:
This series is about the implementation of common data structures. Throughout the series we will be implementing these data structures ourselves, exploring how they work. Our implementations will be done in Clojure. Consequently this tutorial is also about Lisp and Clojure. It is important to note that, unlike the standard collection of data structures found in Clojure, which are persistent, ours will be mutable.
To start with, we will explore a linked list implementation using
deftype(more on this later) to define a JVM class from Clojure-land. This implementation will be expanded to include in-place reversal. Finally we will utilize Clojure’s built-in interfaces to give our linked list access to some of the methods Clojure provides.
…
If you aren’t going to invent your own computer language, why not learn an existing one better?
The next post is on hash tables.
Enjoy!
Comments Off on Data Structures in Clojure:…
February 2, 2014
Clojure for the Brave and True Update
There is now a Clojure for the Brave and True Update list.
You can either subscribe there or wait for me to post about the latest chapters. 😉
BTW, Daniel has a post with the title: Book Cover Concept, Revisions & Free Books. As you can guess from the title there is a book cover “doodle,” plans for the coming weeks and a short listing of pubic resources on Lisp.
Enjoy!
Comments Off on Clojure for the Brave and True Update
January 24, 2014
Clojure In Small Pieces
Clojure In Small Pieces by Timothy Daly (editor)
From the Foreword:
Rich Hickey invented Clojure. This is a fork of the project to experiment with literate programming as a development and documentation technology.
Every effort is made to give credit for any and all contributions.
Clojure is a break with the past traditions of Lisp. This literate fork is a break with the past traditions of code development. As such it is intended as an experiment, not a replacement or competition with the official version of Clojure.
Most programmers are still locked into the idea of making a program out of a large pile of tiny files containing pieces of programs. They do not realize that this organization was forced by the fact that machines like the PDP 11 only had 8k of memory and a limit of 4k buffers in the editor. Thus there was a lot of machinery built up, such as overlay linkers, to try to reconstruct the whole program.
The time has come to move into a more rational means of creating and maintaining programs. Knuth suggested we write programs like we write literature, with the idea that we are trying to communicate the ideas to other people. The fact that the machine can also run the programs is a useful side-effect but not important.
Very few people have seen a literate program so this is intended as a complete working example, published in book form. The intent is that you can sit and read this book like any other novel. At the end of it you will be familiar with the ideas and how those ideas are actually expressed in the code.
If programmers can read it and understand it then they can maintain and modify it. The ideas will have been communicated. The code will be changed to match changes in the idea. We will all benefit.
I’ve tried to make it as simple as possible. Try it once, you might like it.
Well, with 1,801 pages, I’m just glad the next Game of Thrones novel is some time off in the future. 😉
This version is dated November 14, 2013.
It’s not Clojure in 140 characters or in 30 seconds but if you learn a language that way, you have 140 characters and/or 30 seconds of understanding.
I suspect working through this text will slow the reader down enough to appreciate Clojure as a language.
It will take a while before I know. 😉 The northern side of 600 pages of different drafts are due to be reviewed by this time next month.
While I find time to read Clojure in Small Pieces, enjoy!
Comments Off on Clojure In Small Pieces
January 21, 2014
Why Clojure?
From the post:
On 1/14 Brandon Bloom stopped by Axial HQ to teach us all a little bit about his favorite functional language: Clojure. Brandon’s “slides” are available via github.
One of the coolest parts of the Lyceum was Brandon’s discussion of Clojure’s entirely immutable data-structures through structural sharing, along with his practical shopping cart demonstration. This type of data-structure seems particularly adept for modeling problems with many possible trees, such as constraint satisfaction problems.
If you’re ready to start using structural sharing in your own programming language, check out Brandon’s thread on StackOverflow.
Have you ever thought about “merging” as a constraint satisfaction problem? 😉
Bring strong coffee and find a comfortable seat.
Comments Off on Why Clojure?
January 16, 2014
Leiningen Install, The Missing Bits
Quite recently I installed Leiningen following the instructions from the homepage:
- Download the lein
script (or on
Windows lein.bat)- Place it on your $PATH where your shell can find it (eg. ~/bin)
- Set it to be executable (chmod a+x ~/bin/lein)
Well, actually not.
Installing using sudo:
- Download the lein script (or on Windows lein.bat)
- sudo mv lein.txt /bin/lein (changes the file name and moves it to ~/bin) or sudo mv lein /bin *
- Set it to be executable: sudo chmod a+x ~/bin/lein
- Execute lein, $lein **
* If you save the lein script without a file extension, use the second command. Chrome on Ubuntu would only save the file with an extension.
** When you execute lein, leiningen-(version)-standalone.jar will be installed in your home directory under .lein.
You can always type: lein -h to see your options or check this lein 2.3.4-cheatsheet.pdf.
January 9, 2014
Clojure for the Brave and True
Clojure for the Brave and True by Daniel Higginbotham.
From the webpage:
For weeks, months — no! from the very moment you were born — you’ve felt it calling to you. Every time you’ve held your keyboard aloft, crying out in anguish over an incomprehensible class hierarchy; every time you’ve lain awake at night, disturbing your loved ones with sobs over a mutation-induced heisenbug; every time a race condition has caused you to pull out more of your ever-dwindling hair, some secret part of you has known that there has to be a better way.
Now, at long last, the instructional material you have in front of your face will unite you with the programming language you’ve been longing for.
Are you ready, brave reader? Are you ready to meet your true destiny? Grab your best pair of parentheses: you’re about to embark on the journey of a lifetime!
You have to admit it is a great title!
Probably the start of a * for the Brave and True series. 😉
Comments Off on Clojure for the Brave and True
January 6, 2014
Clojure TV Channels
Stuart Sierra mentions ClojureTV in Clojure 2013 Year in Review.
As of today, I could some eighty-one (81) videos.
Once you finish there, there are one hundred and eleven (111) waiting for you at: InfoQ Clojure presentations.
I just spot checked but I am not picking up duplicates between these two video sources.
Say potentially one hundred and ninety-two (192) Clojure videos between these two sites.
You don’t have to wait for the new seasons to start on cable TV. 😉
Comments Off on Clojure TV Channels
January 5, 2014
Turning Cats into Dogs in Hanoi
Fun with Clojure: Turning Cats into Dogs in Hanoi by Justin Kramer.
From the post:
I’ve been having fun brushing up on basic graph theory lately. It’s amazing how many problems can be modeled with it. To that end, I did a code kata the other day that lent itself to a graph-based solution:
. . . the challenge is to build a chain of words, starting with one particular word and ending with another. Successive entries in the chain must all be real words, and each can differ from the previous word by just one letter.
One way to approach this is to think of all valid words as nodes in a graph, where words that differ from each other by one letter are connected. To find a path between one word, say “cat”, and another, “dog”, traverse the graph breadth-first starting at the “cat” node until you find the “dog” node.
The post caught my attention because of the “turning cats into dogs” phrase. Sounds like a good idea to me. 😉
The graph library mentioned in the post is Loom, which is now found at: https://github.com/aysylu/loom. (Yes, it is the same Loom mentioned in: Loom and Graphs in Clojure.)
Great visualizations including solving the Tower of Hanoi puzzle.
Do you think a Hanoi Tower with eight (8) disks would be sufficient for testing candidates for public office? Should the test be timed or least number of moves?
Comments Off on Turning Cats into Dogs in Hanoi
January 4, 2014
Loom and Graphs in Clojure
From the description:
Graph algorithms are cool and fascinating. We’ll look at a graph algorithms and visualization library, Loom, which is written in Clojure. We will discuss the graph API, look at implementation of the algorithms and learn about the integration of Loom with Titanium, which allows us to run the algorithms on and visualize data in graph databases.
Walks through the Bellman-Ford algorithm (shortest path) and its implementation in Clojure, interfacing with Titanium, and visualizing clojure.core.async.
Loom should be high on your list of projects with graphs using Clojure.