Over the last month or so, I’ve begun learning Clojure. I don’t do much blogging, let alone technical, but I realise I’ve actually had this blog for so long that my first impressions of Python (the language I spend most of my day job writing in), are documented.

I read through Kyle Kingsbury’s Clojure from the ground up series, and found it an easy learning process. Although I consider myself somewhat of a polyglot, I realised that I hadn’t actually learned any new programming languages in almost ten years, aside from various JavaScript type annotation supersets. (I’ve tried learning Haskell, but have been largely unsuccessful.)

All in all, I like it. I like its functional paradigm, making functions pure by default, but not having to ask permission to get side-effects (which is the feeling I get a bit with Haskell). Leiningen is a great tool to get up and running, and it takes care of a lot of the minutae, like installing dependencies and running tests. I really like being able to name functions almost anything, including non-ASCII characters and characters normally reserved (so now I can use possessive in a function name).

One thing I find about that I really dislike is the abbreviations. Now, this might simply be because it’s the first language I’ve picked up in a while, and I simply haven’t paid attention to it in other languages, but the incessant abbreviating every conceivable name drives me up the wall. Why in the world does it have to be conj and assoc, what’s wrong with conjoin and associate‽ The fact that abbreviations are applied so randomly proved a stumbling block for me, which I feel it really shouldn’t have to be. This is my first foray into Lisp, so I don’t know how much (if any) is simply convention, but space-saving concerns one might have had in the 50s can surely be ignored today. I get more riled up than I justifiably should be, but it irks me. (And again, I realise this might simply just be my internalisation of some abbreviations: I have no problem with str, concat and def.)

I find the destructuring syntax in a lot of cases to be greatly confusing and emanating magic. I have come to terms with let taking a vector of alternating key value pairs, but the sprinkling of keywords to imbue bindings with special properties means I’m still at a copy & paste–stage for some use cases. I’m not very far into macros yet (I have yet to write my first one), but from what I can sense, it leads to a lot of poorly designed APIs. But it might just take some getting used to. (I thought the self argument for Python methods was stupid at first, and now I don’t think about it.)

I also really miss Python’s named, any-order parameters. I realise something similar can be achieved in Clojure using keys destructuring, but that can’t be combined with arity overloading, which I also really like. (Yes, this might be a case of wanting to have a cake and eating it too.)

The lack of a good date and time library is also unfortunate (at least for the apps I tend to do). I’ve been using clj-time, which seems to be a pretty thin wrapper around Joda Time, and while it does its job, it has some odd shortcomings, the primary being its incapability of representing date-less times. I’ve resorted to vectors of hours, minutes, etc., but when you’re used to Python’s datetime library, specifically datetime.time in this instance, you find yourself wanting.

I have found one library that I really like, though: Enlive. It’s an unconventional templating library, in that it doesn’t make a DSL for templating (or, indeed, give access to the whole language, as in PHP), letting the templates instead be pure HTML, and doing the transformations in Clojure. It took me a little while to get the hang of doing things such as loops, but I think it makes for a clean separation of concerns, and I’ll definitely investigate the concept in Python. (There is a Python port, although it doesn’t seem to get much attention these days.)

All in all, I’m really excited about Clojure. For web development it lacks some of the maturity and cohesiveness that I’m used to with Django, but as a language it has a lot of interesting concepts and libraries.

Aaron Gustafson (via Jeremy Keith):

The square brackets (“[]”) at the end of the name are the magic bit that allows the values of each chosen “reservation_requested_device” checkbox to be submitted as the value of “reservation_requested_device”.

This is not, strictly speaking, true. It is not incorrect either, and if you use PHP, you’ll need it.

That was a mouthful, but the underlying truth is this: You don’t need square brackets at the end of a checkbox’ name attribute to send multiple values to the server. However, in order for the server to understand that there is (or might be) multiple values, PHP has chosen a convention of ending the name with square brackets (which aligns with its syntax for pushing an element to an array). It is possible others have mimicked this behaviour (I know jQuery does it for sending arrays as XMLHttpRequests from the client), but there is no necessity for it.

I have wrapped up a tiny example to showcase that this is not necessary. My example is implemented in the Python web framework Django.

A query string can contain any key multiple times, and it is up to the server to interpret the result. For instance, Django has chosen for its QueryDict that you can access any value from the standard Python get method to get a single value, or you can access the getlist method to get a list of values (it is possible for the resulting list to only contain one item, or indeed none for an unknown key).

The use of square brackets might indeed be very logical (to signify the expectation of multiple values), but Jeremy noted that he, wasn’t sure whether that was just a PHP thing, and I wanted to confirm that’s indeed the case.

John Gruber outlines his wishes for Twitter’s new longer tweet format:

This sounds like what I’ve been hoping they’d do: treat longer-than-140-character posts as an attachment type, like quoted tweets, images, etc.

An idea for a service I’ve been idly considering for some time: Capture part of a page, and if requested with an Accept header that prefers images over HTML, show the text as an image.

Sort of like a mix of Mozilla’s PageShot (but instead do it for excerpts) and OneShot and similar apps for text-fragments-as-screenshots.

This would be ideal for Twitter clients, although I’m not sure whether (any) Twitter clients actually explicitly prefer images over HTML. Considering how most of them embed images inline, I think they should, though.