| Andrew Cooke | Contents | Latest | RSS | Twitter | 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

Lepl parser for Python.

Colorless Green.

Photography around Santiago.

SVG experiment.

Professional Portfolio

Calibration of seismometers.

Data access via web services.

Cache rewrite.

Extending OpenSSH.

C-ORM: docs, API.

Last 100 entries

Have to add...; Culturally Liberal and Nothing More; Weird Finite / Infinite Result; Your diamond is a beaten up mess; Maths Books; Good Bike Route from Providencia / Las Condes to Panul\; Iain Pears (Author of Complex Plots); Plum Jam; Excellent; More Recently; For a moment I forgot StackOverflow sucked; A Few Weeks On...; Chilean Book Recommendations; How To Write Shared Libraries; Jenny Erpenbeck (Author); Dijkstra, Coins, Tables; Python libraries error on OpenSuse; Deserving Trump; And Smugness; McCloskey Economics Trilogy; cmocka - Mocks for C; Concept Creep (Americans); Futhark - OpenCL Language; Moved / Gone; Fan and USB issues; Burgers in Santiago; The Origin of Icosahedral Symmetry in Viruses; autoenum on PyPI; Jars Explains; Tomato Chutney v3; REST; US Elections and Gender: 24 Point Swing; PPPoE on OpenSuse Leap 42.1; SuperMicro X10SDV-TLN4F/F with Opensuse Leap 42.1; Big Data AI Could Be Very Bad Indeed....; Cornering; Postcapitalism (Paul Mason); Black Science Fiction; Git is not a CDN; Mining of Massive Data Sets; Rachel Kaadzi Ghansah; How great republics meet their end; Raspberry, Strawberry and Banana Jam; Interesting Dead Areas of Math; Later Taste; For Sale; Death By Bean; It's Good!; Tomato Chutney v2; Time ATAC MX 2 Pedals - First Impressions; Online Chilean Crafts; Intellectual Variety; Taste + Texture; Time Invariance and Gauge Symmetry; Jodorowsky; Tomato Chutney; Analysis of Support for Trump; Indian SF; TP-Link TL-WR841N DNS TCP Bug; TP-Link TL-WR841N as Wireless Bridge; Sending Email On Time; Maybe run a command; Sterile Neutrinos; Strawberry and Banana Jam; The Best Of All Possible Worlds; Kenzaburo Oe: The Changeling; Peach Jam; Taste Test; Strawberry and Raspberry Jam; flac to mp3 on OpenSuse 42.1; Also, Sebald; Kenzaburo Oe Interview; Otake (Kitani Minoru) move Black 121; Is free speech in British universities under threat?; I am actually good at computers; Was This Mansplaining?; WebFaction / LetsEncrypt / General Disappointment; Sensible Philosophy of Science; George Ellis; Misplaced Intuition and Online Communities; More Reading About Japan; Visibilty / Public Comments / Domestic Violence; Ferias de Santiago; More (Clearly Deliberate); Deleted Obit Post; And then a 50 yo male posts this...; We Have Both Kinds Of Contributors; Free Springer Books; Books on Religion; Books on Linguistics; Palestinan Electronica; Books In Anthropology; Taylor Expansions of Spacetime; Info on Juniper; Efficient Stream Processing; The Moral Character of Crypto; Hearing Aid Info; Small Success With Go!; Re: Quick message - This link is broken; Adding Reverb To The Echo Chamber; Sox Audio Tools

© 2006-2015 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 -
http://news.ycombinator.com/item?id=2880935 (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 =
(www.babel-17.com)? 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 - http://www.babel-17.com/
Blog - http://phlegmaticprogrammer.wordpress.com/

Comment on this post