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:
- trying out panda 3d, mostly following their tutorials
- trying out kivy, again mostly following tutorials
- 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:
1 2 3 4 (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:
1 2 3 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.