Having spent the last couple of months reading up on Lua programming (Programming Lua 4th edition), I wanted to put what I'd learnt into practice. I picked the Project Rosalind problem set for the task. Each problem in it is well defined, and the focus is on functionality not clever programming tricks or language features.
There is a pleasing conceptual purity to Lua. The only data structure available is a table. Arrays are implemented as tables, as are dictionaries, namespaces, modules, and objects. Metatables allow the construction of prototype style inheritance for OOP, and you are free to tinker with the underlying mechanisms as much as you like. Syntax is minimal, consistent, and with very little sugar.
I liked reading about Lua a great deal. Programming with it was a different matter, which surprised me. The problem with purity and minimalism in a language, is it can give rise to awkward and stilted code. The more messy and "real world" the problem, the greater the tendency.
Lua has very good string handling abilities, so was a good fit for the problem set (being as it is the manipulation of dna sequences). However everything seemed a little too formal. The uniformity and lack of syntactic shortcuts made me aware of the language as I wrote code. This wasn't the same kind of awareness that comes from the high ceremony of say C# (something I use in my day job). Instead it was a strange butting up against a sort of conceptual one-ness. Sure, Lua is elegantly designed, but something about that elegance made using it a self-conscious endeavour.
For contrast I decided to undertake the same set of exercises in Python, a language I have tinkered with on and off for some time. I don't consider myself a Pythonista, nor someone deeply knowledgeable of the standard library, but it immediately struck me how much more readily things flowed.
Unlike Lua, Python embodies a number of conceptual ideas and offers a choice of built-in data structures. Syntax is inconsistent and has a fair helping of sugar. On paper it is far from elegant, but it has the remarkable property of staying out of your way for most of the time. The imperfections and inconsistencies make it easier to program in not harder.
The language is low on ceremony, meaning little time is spent dwelling on the language. I could code pretty much in the way I thought about the problem at hand. This zen-like state of affairs didn't always prevail (would it still be programming if it did?). For most of the time though, and for most of the problems, Python just... wasn't there, but was.
The final joy, because that's what it was - joy, came when after a handful of lines of code I realised the job was done. All the decisions that have gone into making Python, mean I only spend a short time using it. I don't think there's a better hallmark of good language design than that.