Chris McCormick

Hy(lang) is a LISP-family programming language built on top of Python. You get the rich Python language & library ecosystem, with a LISP syntax and many of the language conveniences of Clojure, such as reader macros for easy access to built in data types. What's not to love?

I recently found out I have the most GitHub stars for projects written in Hy of any developer worldwide. With this admittedly ridiculous credential in hand I'd like to offer some opinions on the language.

I really like Hy a lot. I prefer writing code in Hy to writing code in Python, and I am writing this post because I want to see Hy do well. I originally wrote this as a list of things in Hy that could possibly be improved, from the perspective of an end user such as myself. Then my friend Crispin sent me this fantastic video by Adam Harvey: "What PHP learned from Python" and I realised that all of the issues I have with Hy stem from the same basic problem that Adam talks about.

Here is the crux of the problem: I've written a bunch of software in Hy over the past few years and often when I moved to a newer point-release of the language all my old code breaks. My hard drive is littered with projects which only run under a specific sub-version of Hy.

gilch[m] It might depend on the Hy version you're using.

I understand that the maintainers of the language, who are hard-working people doing a public service for which I'm deeply grateful, are concerned with making the language pure and clean and good. I understand that languages have to change to get better and they need to "move fast and break things" sometimes. That's all fine and good.

However, I think Adam Harvey's point stands. If you want users to use and love your language:

• Break things cautiously
• Maintain terrible things if it makes life better
• Expand the zone of overlap [backwards compatibility between consecutive versions]

I think if you can maintain backwards compatability you should.

Almost all of the breakages I've experienced between Hy versions could have been avoided with aliasing and documentation. Not doing this backwards compatibility work basically tells your users "don't build things with this language, we don't care about you." I know that is almost certainly not the attitude of the maintainers (who are lovely, helpful people in my experience) but it is the way it comes across as an end user.

Here is a list of things which have changed between versions which blew up my Hy codebases each time I upgraded Hy:

• Renaming true, false, and nil to the Python natives True, False, and None. These could have been aliased to maintain backwards compabitility.

• Removing list-comp and dict-comp in favour of the excellent lfor, dfor, and friends. Again, small macros could have aliased the old versions to the new versions.

• Removing def in favour of setv. A very small macro or maybe even an alias could have retained def as it is pretty much functionally identical from the perspective of an end user.

• Removing apply, presumably in favour of #**. Support could have been retained for the functional apply. There are situations where a proper apply is favourable.

• Removing the core macro let. It seems there was an issue where let would not behave correctly with generators and Python's yield statement. A more user-friendly solution than chopping the imperfect let from the default namespace and breaking everybody's code would have been to document the issue clearly for users and leave the imperfect let in. I know it is available in contrib. Moving it to contrib broke codebases.

Having your old code break each time you use a new version is frustrating. It makes it hard to justify using the language for new projects because the maintainance burden will be hy-er (sorry heh).

Some other minor nits I should mention which I think would vastly improve the language:

• loop/recur should be core. Like let these are available in contrib, but that means you have to explicitly import them. Additionally it would be super nice if they were updated to support the vector-of-pairs declaration style of let and cond etc.

• Why does assoc return None? This is completely unexpected. If there are performance issues then create an alternative which does what Python dict assignment does (aset?) but it seems unwise to break user expectations so fundamentally.

It is much easier to provide criticism than it is to write working code. I am sorry this is a blog post instead of a pull request, and I hope this criticism is seen as constructive. I want to thank everybody who has worked on hy. I am a huge fan of the language. It is an amazing piece of software and I am very grateful for your work.

I've got three conference talks coming up in Perth (Australia), London, and The Gold Coast (Australia). If you're nearby let me know - I would love to buy you a coffee/beer and hear what you're up to.

Security BSides

This Sunday, September 22nd, Perth, Western Australia.

I'm presenting "Bugout: practical decentralization on the modern web." It's a talk about the library I built on top of WebTorrent for building web based decentralized systems.

Clojure eXchange

December 2nd-3rd, London, UK.

I'm giving a keynote: a show and tell of the multitude of strange things I've been building with the Clojure[Script] family of programming languages, and how Clojure enables the bad habit of starting way too many projects. I'll also give an update on Thumbelina, the tiny MIDI controller I've been working on with my friend Dimity.

Linux.conf.au

January 13th-17th, Gold Coast, Australia.

I'm talking about Piku, and how it helps you do git push deployments to your own servers. I've made a bunch of contributions to this open source project in recent months. I've personally found a huge productivity gain from being able to deploy internet services without having to think too much, and I'm excited to show others this too.

In November 2015 Nick Szabo gave a talk on the history of the blockchain which was dense with useful ideas.

Here are some notes I took on his talk:

• Philosophical inspiration to Cypherpunks who invented Cryptocurrency:

  • Ayn Rand: Galt's Gulch - independence from corrupt institutions.
  • Tim May: "protect yourself with cryptography" (cyber Galt's Gulch.)
  • Friederich Hayek: Institutions of property, contracts, money are actually important to human freedom.

• Use computer science to minimize vulnerability to strangers.

• Non-violently enforce the good services of institutions.

• "Try to secure as much as possible" not just communication.

• Cryptography: only secures communications from 3rd parties.

• David Chaum: let's apply this to money too.

• Centralization problem remained in digital cash startups.

• Bad assumptions in computer security: trusted third parties like certificate authorities are secure.

• Trusted third parties are security holes.

• Centralization is insecure.

• E.g. Communists were able to get stranglehold with just control of railroads, newspapers, radio.

• Gold is insecure

  • Spanish looted Aztec gold, pirates looted Spanish gold.
  • Part of end of gold standard was German U-boat threat to British gold transportation.
  • Franklin Roosevelt's government confiscated gold.
  • In modern times xray machines detect gold easily.

• Decentralization per computer science is much more automated & secure than traditional security.

• CS decentralization can only replace small fraction of traditional security but with very high cost savings.

• Traditional security isn't the protocol itself, requires strong external law enforcement.

• Computer security can be secure across national borders instead of siloed inside jurisdictions.

• Cryptocurrency helps solve this through decentralization.

• Separation of duties: several independent people to perform a task to get it done.

• Each node as independent as possible.

• E.g. crude measure of independence: geographic diversity of nodes.

• Number of nodes is only a proxy measure of decentralization.

• Smart contract:

  • Long lived process or "distributed app".
  • Acts like a contract.
  • Performance, verification etc.
  • Generally 2 parties + blockchain (replacing TPP).

• Wet code = traditional law. Dry code = smart contract.

• Law is subjective, enforced with coercion, flexible, highly evolved.

• Smart contracts are mathematically rigorous, cryptographically enforced, rigid, very new.

• Law is jurisdicionally siloed, and expensive to execute.

• Smart contracts are super-national & independent and low cost.

• Seals in clay/wax were important when writing was invented: signature + tamper evident.

• Modern seals at e.g. crime scenes: sealing door, evidence bag with numeric identifier.

• Blockchain can keep secure log with both semantics (serial number) and proof of evidence (photo hash).

• Put proof of evidence on blockchain as well as semantic reference for contract code to interface with.

• Can secure physical spaces with same mechanism.

• Proplets: blockchain can tell them which keys have which capabilities.

  • For almost any valuable property that can be controlled digitally
  • Example: Auto-repo collateral upon contract breach.
  • Example: creditors without access to offshore oil rig used as collateral.

• Recent project:

  • Trust minimized token: secure property titles, colored coins. Securing transfer of ownership.
  • Trust minimized cash flows (dividends, coupons, etc).

• Idea: social networks for blockchains. Execute payment swaps & smart contracts after linking social accounts together.

• Let's try to think about security more broadly instead of only encryption.

• Let's try to protect everything that's important to us, without centralization.

Recently I've been hacking on a game engine for infinitelives called px3d.

It's built on top of ClojureScript, Blender, and Three.js and it runs in the browser.

One feature I'm particularly happy with is the live-reloading of Blender assets into the game. You hit "save" in Blender and the updates appear in the running game a second later - no need to re-compile or re-load the game.

The way this works is with a background script which watches the assets.blend file. It re-builds the assets.glb whenever it is modified, and writes the hash of the file into assets.cljs. Figwheel pushes changes to the compiled cljs files whenever they change, and there is another bit of code which tells three.js to re-load assets.glb if the hash has changed.

Infinitelives

Infinitelives is the vehicle me and my buddy Crispin use to make games and tooling, mostly for gamejams. The gamejam format is great because it is time-boxed, which means we can periodically do this self-indulgent thing we enjoy without taking too much family or work time.

Gamejams are typically only 48 hours long and so we have learned some good techniques for shipping working code under extreme constraints. A hardcore economy of time, resources, and scope is required.

ClojureScript & Figwheel are perfect for this with their hot-loading of modified code. I built the tight Blender re-load integration for the same reason. Hand drawn graphics consume a lot of time during jams and this should help us really level up on the content side of things.

If you'd like to find out when we release games and new tools you can sign up to our release notifications on the infinitelives home page or follow us on Twitter.

If you liked this you might also like my Roguelike game web template which you can get on itch.io. Thanks for supporting my work!