Welcome to 2015 (part 2)

Bloody hell! I just wrote a blog post and WordPress lost it.
Grrrr …
The short resume was :
– yes, I’m late (Feb) continuing my “Welcome to 2015” blog posts.
– last year I got the functional programming bug. Haskell is pretty damned good, but I’ve fallen for Clojure because a) dynamic types, b) Lisp syntax(lessness), c) Paredit.
– last year I did more Python, but not much OWL. This year, OWL is calling again. And as well as making me want to rethink Mind Traffic Control in light of it, is also seeming to demand some kind of pivot on GeekWeaver.
I’ll be coding and blogging more on this ongoing development in coming weeks / months.
I’ve also been playing a bit with remoteStorage, but nothing to show yet.


Well that was surprisingly painless.
I’m in the process of reorganizing the code for Patterning, my Clojure library that produces (visual) patterns.
Patterning was built using Quil, which is a Clojure wrapper around Processing. But I wanted to be able to call the library directly from Processing itself (Java version).
It seemed silly to create an uberjar file containing the whole of Quil and Processing, to be called from … er … Processing, so I decided to split the project into the core (pure Clojure, no Quil or Processing dependencies) and a Quil based wrapper.
I’m also, compiling the library using ClojureScript to run in the browser. (Called from Javascript). Once again this part doesn’t want any Quil / Processing dependencies.
But I was a bit stumped with how to manage some of this. My previous experience of projects that rely on other projects (git submodules) has been somewhat painful.
But it seems the Clojure (via Java) world has actually sorted this. All I needed to do was create an account over on Clojars and type :
lein deploy clojars
to put the JAR for my Patterning library there.
And so here it is.
Including it in a new project is as simple as referencing it in the project.clj file. There’s a simple test project which combines both Patterning and Quil. And here’s the very simple project.clj file. Note the patterning dependency.

(defproject com.alchemyislands/patterning_quil "0.1.0-SNAPSHOT"
:description "Quil Wrapper for Patterning library"
:url "http://alchemyislands.com"
:license {:name "Eclipse Public License"
:url "http://www.eclipse.org/legal/epl-v10.html"}
:dependencies [[org.clojure/clojure "1.5.1"]
[org.clojure/math.numeric-tower "0.0.4"]
[quil "1.7.0"]
[com.alchemyislands/patterning "0.3.0-SNAPSHOT"]]
:aot [patterning_quil.core]
:main patterning_quil.core

And that’s more or less it.
If you want to use Patterning in your own projects, just include it like that. If you still want to be using Quil, then use this as your example.
BTW: the new development for the core Patterning library is now at https://github.com/interstar/Patterning-Core

Clojure Multimethods

Wow! Now this is weird!

I honestly don’t know what to make of Clojure’s ad-hoc hierarchies. I have, I confess, been missing a little bit of the polymorphism I’m used to with classic OO class-hierarchies.

This looks like it’s the answer to that. But hmmmm …. if I start down this path am I going to find myself reinventing standard OO capacities with a weird syntax? Does adopting these things mean I’m falling back from my FP sophistication to “class-based” programming? Is it the equivalent of abusing do to make my Lisp more imperative?

Lazy Lists Are Late-Binding

A thought that struck me in the swimming pool today.
Lazy lists are another kind of late-binding.
Everyone hypes lazy lists by saying “wow! you can even have infinitely long lists!”
To which the natural response is, “So what? The universe is finite and my life and this program are certainly finite, why should I care?”
But, instead think about this. “Infinite lists” are really “unbounded lists” are really “when you create them, you don’t know how long you want them to be” lists.
It’s another part of the program, the “consumer” of the list, which knows how long you want them to be.
For example, I’m currently generating patterns in Clojure + Quil. Here’s one which is basically formed by filling a grid with a number of tiles.
The important thing here is that, although I know I want a repeated pattern of different tiles, I don’t need to know how many of these tiles in total I’m actually going to need to fill my grid, so I just create an infinite list, using
(cycle [tile1 tile2 tile3 tile4])
Then I have a function which zips the list of tiles with a list of positions to be filled. The list of tiles is infinite, but the list of positions on the grid isn’t, so the zipping ends up with a finite grid of tiles.
In a sense, this is yet another example of “late-binding” (ie. leaving decisions as late as possible). It allows the names of data-structures to stand for things (data-structure) whose shape and extent is determined much later.

Are Languages Still Evolving Towards Lisp?

My Quora answer to the question “Is it still reasonable to say mainstream languages are generally trending towards Lisp, or is that no longer true?

Based on my recent experiments with Haskell and Clojure.

Lisp is close to a pure mathematical description of function application and composition. As such, it offers one of the most concise, uncluttered ways to describe graphs of function application and composition; and because it’s uncluttered with other syntactic constraints it offers more opportunities to eliminate redundancy in these graphs.
Pretty much any sub-graph of function combination can be refactored out into another function or macro.
This makes it very powerful concise and expressive. And the more that other programming languages try to streamline their ability to express function combination, the more Lisp-like they will get.
Eliminating syntactic clutter to maximize refactorability will eventually make them approximate Lisp’s "syntaxlessness" and "programmability".
In that sense, Paul Graham is right.
HOWEVER, there’s another dimension of programming languages which is completely orthogonal to this, and which Lisp doesn’t naturally touch on : the declaration of types and describing the graph of type-relations and compositions.
Types are largely used as a kind of security harness so the compiler or editor can check you aren’t making certain kinds of mistakes. And can infer certain information, allowing you to leave some of the work to them. Types can also help the compiler optimise code in many ways : including safer concurrency, allowing the code to be compiled to machine-code with less of the overhead of an expensive virtual machine etc.
Research into advanced type management happens in the ML / Haskell family of languages and perhaps Coq etc..
Ultimately programming is about transforming input data into output data. And function application and composition is sufficient to describe that. So if you think POWER in programming is just about the ability to express data-transformation, then Lisp is probably the most flexibly expressive language to do that, and therefore still is at the top of the hierarchy, the target to which other programming languages continue to aspire.
If you think that the job of a programming language is ALSO to support and protect you when you’re trying to describe that data-transformation, then POWER is also what is being researched in these advanced statically-typed languages. And mainstream languages will also be trying to incorporate those insights and features.


OK. Consider me won over.
Lisp is great to work with. The things that grabbed me about FP in Erlang and Haskell (pattern-matching arguments, partial application, lazy evaluation) are all here.
My code is as concise as Erlang and damned nearly as concise as Haskell (I think the line count is similar though the number of characters per line is about twice as high)
Although I respect Haskell’s type system, Clojure’s dynamic typing holds me up less. I *am*, admittedly, hitting more problems that a type system would have picked up. (Far more than I typically hit in Python) but I think as I get more used to the language this will go down.
I’m not being particularly demanding in terms of libraries. (Quil is almost all the libraries I need at the moment.) But I’m finding that there are all these handy things like spit which make me smile. (Remember what this was like in Java?)
Things that would still be a bit fiddly in Python / CoffeeScript continue to turn out to be easier than I imagined they would be when I implement them in Lisp. That’s partly because I default to approaching them as “how do I write a small lambda that can then map across this list” and mostly, by the time I wrote that function, all I have to do is … er … map it across the list.
Lisp is extra-ordinarily compressible. I keep finding ways to refactor and fold up things I did earlier to make them shorter and shorter. And the more functionality I add to my program the more compressed it seems to get.
I am grinning to myself at the thought that my code might be compilable to both Android and into Javascript. I haven’t tried either yet, but if I manage it then Clojure is now my new favourite language.
CoffeeScript isn’t at all bad, but if ClojureScript works out, then I’ll probably start to move aggressively to use it as my default in-browser language. (And yes, I guess that may mean rewriting OWL in it. OWL is still short enough that I think I could sprint it in a couple of days.)
Similarly, if I can compile Clojure libraries that can be called from Java projects then you’ll start to see me more productive on Android. (Beyond OWLdroid I have a couple of other bits and pieces of apps. written, but not taken them to completion. If Clojure slots painlessly into the workflow, it will be a lot more tempting to dive back in.)
So … yeah … Clojure rocks!

Clojure Debugging

Has to be said that Clojure’s runtime debugging support is the worst ever. A call stack of irrelevant Java information and no idea which line of Clojure actually triggered the error.
At least with CoffeeScript you can look into the Javascript at the appropriate line-number and see sort of what it’s doing and then map that back to CoffeeScript manually.

Clojure / Quil

Having decided that this year was my Haskell year, I now find myself dabbling with … er … Clojure.

Why? Well, basically because of Quil which is a wrapping of the Processing library for Clojure. I need to do some Processing-like graphics, and I want to learn the FP way of doing it. Haskell would be great, but I’ve had a bit if hassle recently with trying to install some of its extra libraries so not I’m not so confident I can set it up as quickly as I need. Plus, Clojure / Processing also holds out a bit of hope I might be able to move what I’m doing to Android, which would be a bonus for what I’m working on at the moment.

So suddenly I’m back in Emacs. And writing Lisp as seriously as I ever have. It still looks somewhat verbose and cumbersome, especially compared to Haskell, but I’m finding that as I tweak and refactor, and get more familiar with the idiom, it starts to distil down to smaller and more elegant code. I’m enjoying.

Aaaargh! Quora. No! (Should I learn Clojure for Android programming?)

Having contrasted Quora, positively with StackOverflow, I find that Quora is also starting to play the “word-shaping” game by which either an algorithm or a tone-deaf moderator decides to constrain how you are allowed to express your questions 🙁
No idea why they really feel the need to do this. But it basically has the effect of driving out all personal voice, subtle context to your question, potential for jokes, creative wordplay, malapropism, coining neologisms or anything else that keeps language alive and a delight for the intelligent mind.
Here’s my original (rejected) question :

Should I learn Clojure for Android programming?
I’d like to get into Android programming. But every time I play with it, I find it full of that verbose Java bureaucraticality that we all know and hate.
I’d like to work with a nice modern, higher-level language. (I’m mainly using CoffeeScript / Python these days) So, would it be worth me learning Clojure to do Android programming?
By this I mean two things :
– can you write Android apps. in Clojure at all (is the tooling there?)
– does Clojure buy you anything in the Android world? Or will I still be making the same long sequence of imperative calls to the same Java libraries that I’d be doing in Java? Ie. for this kind of application there isn’t much “compression” in Clojure compared to Java

I’m not saying this is a great question. Or perfect example of writing. But it is MY question, the way I wanted to phrase it.

Update : Got into a certain amount of argument about this. (Partly because I’m complaining.)
Here’s what I found myself replying :

If people prefer not to answer the question, that’s their prerogative. No problem.
The point is, is Quora going to set a “maximum sophistication” limit on questions, so that people who are capable of understanding a question that requires three paragraphs to capture its full meaning, are nevertheless prevented from writing or reading such questions because Quora has decided that only single-paragraph questions are allowed?
I think that will be a catastrophic loss. For me because I like Quora. And, I think for Quora, because it will become a less interesting place to be. I’ve already seen this happen on StackExchange. A place where I used to hang out every day, but where I now spend as little time as possible.