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

C-ORM: docs, API.

Last 100 entries

Lepton Decay Irregularity; An Easier Way; Julia's BinDeps (aka How To Install Cairo); Good Example Of Good Police Work (And Anonymity Being Hard); Best Santiago Burgers; Also; Michael Emmerich (Vibrator Translator) Interview (Japanese Books); Clarice Lispector (Brazillian Writer); Books On Evolution; Looks like Ara (Modular Phone) is dead; Index - Translations From Chile; More Emotion in Chilean Wines; Week 7; Aeon Magazine (Science-ish); QM, Deutsch, Constructor Theory; Interesting Talk Transcripts; Interesting Suggestion Of Election Fraud; "Hard" Books; Articles or Papers on depolarizing the US; Textbook for "QM as complex probabilities"; SFO Get Libor Trader (14 years); Why Are There Still So Many Jobs?; Navier Stokes Incomplete; More on Benford; FBI Claimed Vandalism; Architectural Tessellation; Also: Go, Blake's 7; Delusions of Gender (book); Crypto AG DID work with NSA / GCHQ; UNUMS (Universal Number Format); MOOCs (Massive Open Online Courses); Interesting Looking Game; Euler's Theorem for Polynomials; Weeks 3-6; Reddit Comment; Differential Cryptanalysis For Dummies; Japanese Graphic Design; Books To Be Re-Read; And Today I Learned Bugs Need Clear Examples; Factoring a 67 bit prime in your head; Islamic Geometric Art; Useful Julia Backtraces from Tasks; Nothing, however, is lost with less discomfort than that which, when lost, cannot be missed; Article on Didion; Cost of Living by City; British Slavery; Derrida on Metaphor; African SciFi; Traits in Julia; Alternative Japanese Lit; Pulic Key as Address (Snow); Why Information Grows; The Blindness Of The Chilean Elite; Some Victoriagate Links; This Is Why I Left StackOverflow; New TLS Implementation; Maths for Physicists; How I Am 8; 1000 Word Philosophy; Cyberpunk Reading List; Detailed Discussion of Message Dispatch in ParserCombinator Library for Julia; FizzBuzz in Julia w Dependent Types; kokko - Design Shop in Osaka; Summary of Greece, Currently; LLVM and GPUs; See Also; Schoolgirl Groyps (Maths); Japanese Lit; Another Example - Modular Arithmetic; Music from United; Python 2 and 3 compatible alternative.; Read Agatha Christie for the Plot; A Constructive Look at TempleOS; Music Thread w Many Recommendations; Fixed Version; A Useful Julia Macro To Define Equality And Hash; k3b cdrom access, OpenSuse 13.1; Week 2; From outside, the UK looks less than stellar; Huge Fonts in VirtualBox; Keen - Complex Emergencies; The Fallen of World War II; Some Spanish Fiction; Calling C From Fortran 95; Bjork DJ Set; Z3 Example With Python; Week 1; Useful Guide To Starting With IJulia; UK Election + Media; Review: Reinventing Organizations; Inline Assembly With Julia / LLVM; Against the definition of types; Dumb Crypto Paper; The Search For Quasi-Periodicity...; Is There An Alternative To Processing?; CARDIAC (CARDboard Illustrative Aid to Computation); The Bolivian Case Against Chile At The Hague; Clear, Cogent Economic Arguments For Immigration; A Program To Say If I Am Working; Decent Cards For Ill People; New Photo

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