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

C[omp]ute

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.

Last 100 entries

Sentidos Comunes (Chilean Online Magazine); Hilary Mantel: The Assassination of Margaret Thatcher - August 6th 1983; NSA Interceptng Gmail During Delivery; General IIR Filters; What's happening with Scala?; Interesting (But Largely Illegible) Typeface; Retiring Essentialism; Poorest in UK, Poorest in N Europe; I Want To Be A Redneck!; Reverse Racism; The Lost Art Of Nomography; IBM Data Center (Photo); Interesting Account Of Gamma Hack; The Most Interesting Audiophile In The World; How did the first world war actually end?; Ky - Restaurant Santiago; The Black Dork Lives!; The UN Requires Unaninmous Decisions; LPIR - Steganography in Practice; How I Am 6; Clear Explanation of Verizon / Level 3 / Netflix; Teenage Girls; Formalising NSA Attacks; Switching Brakes (Tektro Hydraulic); Naim NAP 100 (Power Amp); AKG 550 First Impressions; Facebook manipulates emotions (no really); Map Reduce "No Longer Used" At Google; Removing RAID metadata; New Bike (Good Bike Shop, Santiago Chile); Removing APE Tags in Linux; Compiling Python 3.0 With GCC 4.8; Maven is Amazing; Generating Docs from a GitHub Wiki; Modular Shelves; Bash Best Practices; Good Emergency Gasfiter (Santiago, Chile); Readings in Recent Architecture; Roger Casement; Integrated Information Theory (Or Not); Possibly undefined macro AC_ENABLE_SHARED; Update on Charges; Sunburst Visualisation; Spectral Embeddings (Distances -> Coordinates); Introduction to Causality; Filtering To Help Colour-Blindness; ASUS 1015E-DS02 Too; Ready Player One; Writing Clear, Fast Julia Code; List of LatAm Novels; Running (for women); Building a Jenkins Plugin and a Jar (for Command Line use); Headphone Test Recordings; Causal Consistency; The Quest for Randomness; Chat Wars; Real-life Financial Co Without ACID Database...; Flexible Muscle-Based Locomotion for Bipedal Creatures; SQL Performance Explained; The Little Manual of API Design; Multiple Word Sizes; CRC - Next Steps; FizzBuzz; Update on CRCs; Decent Links / Discussion Community; Automated Reasoning About LLVM Optimizations and Undefined Behavior; A Painless Guide To CRC Error Detection Algorithms; Tests in Julia; Dave Eggers: what's so funny about peace, love and Starship?; Cello - High Level C Programming; autoreconf needs tar; Will Self Goes To Heathrow; Top 5 BioInformatics Papers; Vasovagal Response; Good Food in Vina; Chilean Drug Criminals Use Subsitution Cipher; Adrenaline; Stiglitz on the Impact of Technology; Why Not; How I Am 5; Lenovo X240 OpenSuse 13.1; NSA and GCHQ - Psychological Trolls; Finite Fields in Julia (Defining Your Own Number Type); Julian Assange; Starting Qemu on OpenSuse; Noisy GAs/TMs; Venezuela; Reinstalling GRUB with EFI; Instructions For Disabling KDE Indexing; Evolving Speakers; Changing Salt Size in Simple Crypt 3.0.0; Logarithmic Map (Moved); More Info; Words Found in Voynich Manuscript; An Inventory Of 3D Space-Filling Curves; Foxes Using Magnetic Fields To Hunt; 5 Rounds RC5 No Rotation; JP Morgan and Madoff; Ori - Secure, Distributed File System; Physical Unclonable Functions (PUFs); Prejudice on Reddit

© 2006-2013 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
side:

  - 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.

Andrew

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

Hi

(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,
right?

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
"tail"...

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.

Andrew

PS
http://stackoverflow.com/questions/2540237/are-the-square-brackets-in-clojures-defn-defmacro-and-binding-really-a-vector
- 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).

Andrew


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

Hi,

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

Hi,

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
Clojure...)

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
out.

Cheers,
Andrew

Language - http://www.babel-17.com/
Blog - http://phlegmaticprogrammer.wordpress.com/

Comment on this post