This post is a quick update to my last one, Testing Hy code. Although I found hy to be a compelling idea, I decided to stop using it.

I did a little bit of the following tasks with hy:

1. trying out panda 3d, mostly following their tutorials
2. trying out kivy, again mostly following tutorials
3. doing a little machine learning with Tensorflow

One big problem was that, when working from tutorials, I had to translate the code from python to hy. That’s not that hard, but it took some of my focus away from learning/exploring kivy and panda.

Another issue I had was that by using hy, I strayed too far from the common path, and a simple task, like testing became difficult. With kivy, I ran into an unsurmountable issue where the test code would cause kivy to try to render an app from the test code, and fail and crash.

I also found that in many cases, the hy code I wrote was more dense than python. Maybe it’s just that my eyes were not yet trained for it, but this:

(setv [path data checks] path-data-checks
      next-checks (lfor [rule cookie] checks
                    (rule.check self path data cookie))
      filtered-checks (filter next-checks))

is just much more complicated to visually parse for me than this:

path, data, checks = path_data_checks()
next_checks = [rule.check(self, path, data, cookie) for rule, cookie in checks]
filtered_checks = filter(next_checks)

When I read the hy code, I have to follow the code more closely to understand what it does. Probably over time, this would improve but I just didn’t feel it was worth it. People often complain about the editing of lisp code, but I used emacs with parinfer and that was super nice. Parinfer was probably actually the part I liked the most about working with hy.

Ultimately, I found that managing hy was taking up energy and time, and I wasn’t really getting anything back for that. I like python plenty as-is, so the tradeoff just didn’t make much sense.