Andrew Cooke | Contents | Latest | RSS | Previous | Next


Welcome to my blog, which was once a mailing list of the same name and is still generated by mail. Please reply via the "comment" links.

Always interested in offers/projects/new ideas. Eclectic experience in fields like: numerical computing; Python web; Java enterprise; functional languages; GPGPU; SQL databases; etc. Based in Santiago, Chile; telecommute worldwide. CV; email.

Personal Projects

Choochoo Training Diary

Last 100 entries

Surprise Paradox; [Books] Good Author List; [Computing] Efficient queries with grouping in Postgres; [Computing] Automatic Wake (Linux); [Computing] AWS CDK Aspects in Go; [Bike] Adidas Gravel Shoes; [Computing, Horror] Biological Chips; [Books] Weird Lit Recs; [Covid] Extended SIR Models; [Art] York-based Printmaker; [Physics] Quantum Transitions are not Instantaneous; [Computing] AI and Drum Machines; [Computing] Probabilities, Stopping Times, Martingales; bpftrace Intro Article; [Computing] Starlab Systems - Linux Laptops; [Computing] Extended Berkeley Packet Filter; [Green] Mainspring Linear Generator; Better Approach; Rummikub Solver; Chilean Poetry; Felicitations - Empowerment Grant; [Bike] Fixing Spyre Brakes (That Need Constant Adjustment); [Computing, Music] Raspberry Pi Media (Audio) Streamer; [Computing] Amazing Hack To Embed DSL In Python; [Bike] Ruta Del Condor (El Alfalfal); [Bike] Estimating Power On Climbs; [Computing] Applying Azure B2C Authentication To Function Apps; [Bike] Gearing On The Back Of An Envelope; [Computing] Okular and Postscript in OpenSuse; There's a fix!; [Computing] Fail2Ban on OpenSuse Leap 15.3 (NFTables); [Cycling, Computing] Power Calculation and Brakes; [Hardware, Computing] Amazing Pockit Computer; Bullying; How I Am - 3 Years Post Accident, 8+ Years With MS; [USA Politics] In America's Uncivil War Republicans Are The Aggressors; [Programming] Selenium and Python; Better Walking Data; [Bike] How Fast Before Walking More Efficient Than Cycling?; [COVID] Coronavirus And Cycling; [Programming] Docker on OpenSuse; Cadence v Speed; [Bike] Gearing For Real Cyclists; [Programming] React plotting - visx; [Programming] React Leaflet; AliExpress Independent Sellers; Applebaum - Twilight of Democracy; [Politics] Back + US Elections; [Programming,Exercise] Simple Timer Script; [News] 2019: The year revolt went global; [Politics] The world's most-surveilled cities; [Bike] Hope Freehub; [Restaurant] Mama Chau's (Chinese, Providencia); [Politics] Brexit Podcast; [Diary] Pneumonia; [Politics] Britain's Reichstag Fire moment; install cairo; [Programming] GCC Sanitizer Flags; [GPU, Programming] Per-Thread Program Counters; My Bike Accident - Looking Back One Year; [Python] Geographic heights are incredibly easy!; [Cooking] Cookie Recipe; Efficient, Simple, Directed Maximisation of Noisy Function; And for argparse; Bash Completion in Python; [Computing] Configuring Github Jekyll Locally; [Maths, Link] The Napkin Project; You can Masquerade in Firewalld; [Bike] Servicing Budget (Spring) Forks; [Crypto] CIA Internet Comms Failure; [Python] Cute Rate Limiting API; [Causality] Judea Pearl Lecture; [Security, Computing] Chinese Hardware Hack Of Supermicro Boards; SQLAlchemy Joined Table Inheritance and Delete Cascade; [Translation] The Club; [Computing] Super Potato Bruh; [Computing] Extending Jupyter; Further HRM Details; [Computing, Bike] Activities in ch2; [Books, Link] Modern Japanese Lit; What ended up there; [Link, Book] Logic Book; Update - Garmin Express / Connect; Garmin Forerunner 35 v 230; [Link, Politics, Internet] Government Trolls; [Link, Politics] Why identity politics benefits the right more than the left; SSH Forwarding; A Specification For Repeating Events; A Fight for the Soul of Science; [Science, Book, Link] Lost In Math; OpenSuse Leap 15 Network Fixes; Update; [Book] Galileo's Middle Finger; [Bike] Chinese Carbon Rims; [Bike] Servicing Shimano XT Front Hub HB-M8010; [Bike] Aliexpress Cycling Tops; [Computing] Change to ssh handling of multiple identities?; [Bike] Endura Hummvee Lite II; [Computing] Marble Based Logic; [Link, Politics] Sanity Check For Nuclear Launch; [Link, Science] Entropy and Life

© 2006-2017 Andrew Cooke (site) / post authors (content).

Initial Thoughts on Clojure

From: andrew cooke <andrew@...>

Date: Sat, 13 Aug 2011 09:31:05 -0400

For some time I have felt that there was "space in the market" for a simple,
untyped, functional language.  I even wrote a parser for it (working name at
the time was SFL - simple functional language).

You can argue that Python is good enough for this role.  That's a good
argument, but the language (more exactly, the people driving the language)
have an antipathy for fuctional idioms that leave some uncomfortable corners -
no tail call optimisation, for example, and poor parallelism.

Clojure could fill this space (although the JVM forces it into an ugly
compromise for TCO).

I had hoped for a different syntax (Haskell's, although it may be that when
you work through the details, you need lazy evaluation to make it really
work).  And I am not a fan of S-expressions (yes, I know that I am supposed to
become accustomed, or to tweak my IDE; no, it doesn't happen).  But there are
advantages to this approach, and syntax is not the most important part of a
language - perhaps I can live with this.

So Friday I used Clojure in earnest.  One day isn't much, but here's my take:

  - The documentation is pretty bad.  It's hard to find examples of code in
    use and the official docs are brief.

  - Error messages are unhelpful.  You are often faced with a Java cast
    exception that tells you very little (not even useful class names).

  - IDE support is poor, at least in IntlliJ (there's a plugin, but it doesn't
    do much beyond provide basic text highlighting).

Those are all negative points.  But they all seem fixable.  On a more positive

  - The language has adopted some seriously good "small ideas".  Things like a
    library for zippers, or records that integrate cleanly with maps (so
    there's a unified, extensible, interface to product types - something that
    drove me crazy with Pytyp)

  - It has also adapted some "big ideas" - things like STM - that seem like
    they could be useful (didn't have time or need to try this).

  - It takes "functional programming" seriously.  For a language based on the
    JVM it is surprisingly hardcore about (the lack of) mutable state.

Will it survive?  I don't know.  It suffers from using the JVM (maybe it also
gains; I didn't get to the point where I could explore how easy integration is
with other Java libraries) and I don't see the JVM getting significantly
better.  On the other hand, there seems to be some movement towards making the
language self-hosting - that might offer a long-term escape plan.

I will continue to use it, when I get the chance.  I was impressed by the
thing it was doing right - more than you might think from just hearing "Lisp
on JVM).  It is the most "modern", promising Lisp I have used, and it's way
more usable than Scala.


Why I tried clojure and then stopped

From: Adrian Sinclair <adriansinclair2007@...>

Date: Sat, 13 Aug 2011 11:25:42 -0400

Clojure makes strong use of vectors, which is something that is very =
different from other functional languages. Most functional languages use =
(linked) lists for everything, and the car/cdr (head/tail in haskell) =
model works great for recursion. Vectors are (in terms of how they are =
implemented on a low level) similar to tuples, and like tuples, they are =
most efficient when you know that the size of the list won't change, but =
when dealing with recursion (as you must with functional programming) =
the length of a list changes very often, making vectors ill suited for =
general purpose collections.

The amount that clojure used vectors turned me off almost immediately. =
I'll stick with Haskell, thank you.=

Re: Why I tried clojure and then stopped

From: andrew cooke <andrew@...>

Date: Sat, 13 Aug 2011 11:45:45 -0400


(Sorry for the weird formatting (= at the end of lines).  My blog software is
not very sophisticated....)

I thought this was one of the more interesting areas.  I agree cons cells are
awesome, and I was surprised by the emphasis on vectors in Clojure (although
I'm still confused about exactly when [] means vector - are argument lists
something different?).

On the other hand, for some tasks, like number crunching, this could be
useful.  And the zip library looks like it could be a unifying abstratcion
that helps merge the two.  And list comprehensions (and folds) make some
recursion unnecessary.  And linked lists are still available when you want,

It would be interesting to know how recursion over vectors is handled.  Given
the emphasis on immutability it should be possible to avoid copying on

I'm new to this, so I don't have answers, but my current take is more that
it's more an interesting new approach than a fatal flaw.


- arglists are vectors too.

More from HN and Adrian Sinclair

From: andrew cooke <andrew@...>

Date: Sat, 13 Aug 2011 12:25:11 -0400

I submitted this post to HN (a pretty nice technical discussion site) where it
generated some interesting discussion - (including defense of IntelliJ,
extra links, and a book recommendation).

One thing I think I should have said in the original article is that the
optimisations available from a JIT are very useful for a language like
Clojure.  So that's another argument for it being based on JVM rather than,
say, LLVM (see, for example, the Python/Swallow experience).

Also, Adrian Sinclair replied to my reply above with some more details on why
the use of vectors can be troublesome.  It's an interesting (and cogent)
argument, so I'm copying the email here (with permission - it was originally
an email to my private address rather than the blog account).


On Sat, Aug 13, 2011 at 12:02:23PM -0400, Adrian Sinclair wrote:
> The main problem that I have with vectors being so common is that in order
> to comply with the standard protocol for ordered collection-related
> functions, you have to accept vectors as well as linked lists, even when
> linked lists would be better for the function you're implementing. The
> result is you have to convert the vector to a linked list for the sake of
> efficiency (the `tail` function is very inefficient for vectors, but very
> fast for lists).
> It's not just that this is annoying, it's also inefficient. If a developer
> gets a vector back from some function (as that's the standard collection
> type to return), and then passes it to 5 different functions that convert
> the vector to a list, then the vector is being converted to a list 5
> times. Of course, the same happens if you pass a list to 5 functions that
> convert it to a vector. The only real solution to the problem is to strongly
> prefer one collection type, and for the past 62 years (58 when clojure was
> created), all lisps have preferred lists to vectors, and all major ones have
> support for vectors. Hence LISt Processing.

Have you tried Babel-17?

From: Steven Obua <steven.obua@...>

Date: Sun, 14 Aug 2011 12:23:20 +0200


in your search for a simple functional language, have you tried Babel-17 =
( I created it after trying out Clojure, and as I am =
not a big brackets fan, I came up with a (purely) functional language =
which is dynamically typed but has a syntax more like Scala.

- Steven=

Use vectors where they make sense

From: Sean Corfield <sean@...>

Date: Sun, 14 Aug 2011 18:16:40 -0700

I'm a bit surprised at Adrian's negative response to vectors. Clojure =
has vectors so that random access can be amortized O(1) so developers =
will use lists where lists make sense and vectors where vectors make =
sense. The same goes for Clojure's other data structures: sets and maps. =
They all have their uses, and the ability to make the right choice is =
better than being restricted to using only lists for everything, IMO. If =
some function gives you a vector and you need a list for five function =
calls, you can always do:

  (let [s (seq (func-that-returns-vector))]
    (pass s to-five-functions))

Now the conversion is only done once!

Mind you, looking at the source code, the conversion is both almost =
trivial and lazy (so it's wrong to portray it as some terrible =
inefficiency). A vector is a java.lang.Iterable (amongst other things) =
and the conversion involved simply creates an IteratorSeq for each =
element of the vector that is actually required, when it is required. =
Considering how many sequences are created and thrown away during any =
real world functional program execution, I would expect the O(1) random =
access benefits of vectors to outweigh any occasional overhead of =
converting them to sequences, when used appropriately.

A huge amount of work has gone into the performance of the Clojure =
persistent data structures so that Clojure code can be as fast as raw =
Java while tackling very complex problems in very concise, elegant ways.

Re: Have you tried Babel-17?

From: andrew cooke <andrew@...>

Date: Sun, 14 Aug 2011 21:20:33 -0400


I don't think I'd ever heard of Babel-17 before, but I agree it fits what I
was looking for.  I'm going to stick with Clojure for now, but I will try to
follow Babel-17 (I feel guilty for not doing more, because I know how
depressing it can be to labour away on a project people aren't using, but I am
already pushing the limits of what I can expect to get away with at work using

I looked at the blog too.  The UI work sounds interesting.  If you remmeber,
when it's done, please ping me - I would be interested to see how it all turns


Language -
Blog -

Comment on this post