I should have included a disclaimer -- I agree that textures and sprites are excellent, but they come from asset packs (for this same reason I cannot redistribute them in the source release). Only the crossbow placeholder is self-made.
I don't have any issue with paid asset packs, I would gladly build the entire game with third-party art, but there is only so much of it in the necessary style, resolution and quality.
> Over the years I have been frustrated by binary and XML formats that make data only accessible via a single program (or by me wasting time manually converting each file, or by me writing a file format conversion program).
For me, the frustration is version control. Native spreadsheet formats (xlsx/ods) are binary, so un-diffable. Plaintext formats like CSV/TSV play nice with Git, but come at a high cost in ergonomics: there is no way to preserve formatting such as column widths and formulas are usually discarded on save. Moreover, Excel/Calc don't really like it when you overwrite an open file from another program.
MtCellEdit seems to be a step in the right direction, but still leaves a good part of the itch unscratched.
I would agree that the flying has become "unreasonably" cheap given the negative externalities, but if we are talking about traveling over distances of >500 km, the alternatives are rarely compelling -- unless you are lucky enough have a direct high-speed-rail connection to your destination.
It is true that Hy really shines in those cases where it adopts an existing Python feature and adds meaningful quality-of-life improvements: anonymous functions without limitations; multiple iteration in for-loops; relaxed character set for identifiers. Things that seem completely obvious, once you have them.
It also demonstrates that elegance in a Lisp-on-Python is reached in a very different way than elegance in a stand-alone language, since it becomes an art of making the best out of what is already there.
I would like to make the observation that as Hy matured over the years, instead of accumulating syntactic sugar and special cases to grow more Lispy, less Pythony, it seems to have generally gone the opposite way. That is, becoming a thinner syntactic abstraction of Python's feature set, focusing on the essentials that cannot be emulated in any other way (macros)
A few examples from recent releases:
- "match" is just native Python "match" -- it doesn't even polyfill for pre-3.10 Python versions (in the TypeScript world this would be unthinkable)
- "foo?" used to mangle to "is_foo" as a special case, but this has been removed
- "hy.eval" has been overhauled to be more like Python's "eval"
- nice-to-have but non-essential utilities ("unless") get often pushed out into the Hyrule package
For me this direction was counter-intuitive at first, but it has some very nice outcomes; for one, it simplifies the learning curve when coming over to Hy from Python, and it makes it easier to consistently interact with Python packages (arguably the main reason to use Python in the first place!)
Or maybe it's just a matter of simplyfing maintenance of the language; IIRC, "let" took like 4 attempts to get right :)
In any case, congratulations on this great milestone!
Not to discourage you from building your own, but Joplin seems to already tick all or at least most of your boxes -- in fact, I was surprised that it was was not addressed in the first article.