Better is better than worse

I was just saying Python was not metaprogrammable, but we create small functions all the time that are effectively extensions to the syntax, usually short-hand for commonly-repeated patterns that others may just copy-paste around. This is a good thing; I've seen it called "once and once only", and has the important effect that the repeated bit of syntax can be changed in one place swiftly.

In data science work, some ML thingajimajigs expect target features to be 2D arrays with one column rather than 1D vectors. You know this because they tell you to say `y.reshape(-1,1)`. This is for practical purposes part of the syntax in "data python".

But often in data science work, your values are kept in "data frames" and need to be extricated first using the method "values". However, arrays themselves don't have a "values" method so you can't say `y.values.reshape(-1,1)` with confidence. A "convenience function" comes in handy:

The straightforward translation of this "convenience function" to Hy is:

(I haven't run any of these examples). But wait, do we need to call a function everytime we want to just prepare a target? That kind of thing has a performance penalty, and besides, before the dataframe detection came up, this was just a snippet of code we had memorized -- the usual developer doesn't write functions like

Lisps, including Hy, have the aditional concept of a macro. Macros are metaprogramming tools: one writes program-construction programs; when these are evaluated at compile-time, they explicitly change other code we had written. For example, one might write

and then rewrite `prepare-target` as follows:

We can also make the whole prepare-target "utility function" a macro so it gets automatically inlined -- the way we did by hand when all we meant was `#|y`:

Now we can continue to use "prepare-target" (or "prepare_target" if importing back on Python).

Often Python makes one write lots of intermediary variables if we want to have readable code at all

This is the direct equivalent in Hy:

but why not say this instead?

This is obviously possible in Python, but to my ear less readable:

(and with less brackets, someone might note). But see how the parallelism between the expression is lost unless one goes out of one's way to say

Also check out this version

So far it seems that I'm talking about saving characters -- at the price of an explosion of (round and [square brackets]).

But you can not only manage all of those braces but also make them work for you with one weird trick: a "rainbow brackets" extension for your go-to code editor. This will give you colorful visual indication of which are matching parentheses. I'd say this is useful in any language, but in Lisplikes such as Hy, rainbow bracketing effectively shows you the complete structure of your code.

Yeah, man, the brackets are not a drag, they actually diminish the quantity of things you have to juggle on your head while trying to solve problems. There was an article on HN today with a title like "Think in Math, Implement in Code". The comments were mostly to the effect that making up a math formalism rarely helps ordinary everyday problems. But also some pointed out, conversely, that "thinking in code", hands-on, is typically associated with highly-nested loops, non-MECE if-else clauses and worse.

My transitional experience between Python and Hy reinforces an idea that I already had from watching people transition from PHP to node.js: because one tends to sit at the keyboard to figure out problems rather than find an available whiteboard and go into deep thinking, one tends to conceptualize problems in the ways that the language makes most easy. I've known people in finance who were still wed to Matlab and used 2D matrices to represent binary trees.

A concrete example from just yesterday is as follows: I was extracting network information from some shapefiles, which is easy thanks to the vast universe of interoperable Python libraries. The problem was that names were lost in such a way that I was obtaining

when I wanted

What I did have was the mapping {1: "bart"} etc in dict form. After poking the libraries some more, I came up with this in not more than ten minutes (this in the unbearable open plan office of the day job I haven't quit yet)

You kind of need to understand the Hy synax for list and dict comprehensions, but with your rainbow bracket coloring on, code like this grows by thinking in code like this. What, if I was on a dumber language, I might have been neck-deep in double loops already; indeed, much of the conceptual footwork to give us this functionality has been done by Python who came with (the Pythonic version of) list comprehensions (which yes, were in Haskell before). But look how messed up `cross_dict` gets in Python:

I have written nested list comprehensions in Python before -- with much thought and care and painfully aware that comprehensions are pretty much an embedded DSL that doesn't talk much to how Python is otherwise structured. But this is a dict comprehension of a list comprehension of a dict comprehension. I can't reason like this "by the seat of my pants". S-expressions on the other hand let me do it. And Hy already has everything Python in it to begin with, while giving me a non-messed up syntax.

I do admire the work done by the creators and developers of languages like Python and Ruby and so on, who try to make complex things easy by means of cute notation. But how often there's an impedance mismatch between problems at hand, and how often do we avoid thinking in ways that annoy Guido van Rossum? Hy is your ticket to freedom, baby.