Our great sponsors
-
logseq
A local-first, non-linear, outliner notebook for organizing and sharing your personal knowledge base. Use it to organize your todo list, to write your journals, or to record your unique life.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
mu
Soul of a tiny new machine. More thorough tests → More comprehensible and rewrite-friendly software → More resilient society. (by akkartik)
Congratulations, now you replaced a trivial file format that (from a quick glance at the code) needed about ~35 of easily readable and self-contained Lua code to parse with an external dependency that would be much larger and harder to follow and either having (at least) an XML parser as its own dependency or implementing its own XML parsing, as well as being at the mercy of their developers. Also unless you are using some highly popular library, you may end up with some abandoned dependency.
Examples of both are at [0] (C++ based parser, you'd also need to write some bindings for lua) and [1] (Lua based parser for a subset of the format, abandoned for almost a decade).
There are times when using an external dependency might be a good idea, but a text-based file format that describes lines and can be implemented in a few lines of code is not one.
[0] https://github.com/svgpp/svgpp
[1] https://github.com/luapower/svg_parser
Congratulations, now you replaced a trivial file format that (from a quick glance at the code) needed about ~35 of easily readable and self-contained Lua code to parse with an external dependency that would be much larger and harder to follow and either having (at least) an XML parser as its own dependency or implementing its own XML parsing, as well as being at the mercy of their developers. Also unless you are using some highly popular library, you may end up with some abandoned dependency.
Examples of both are at [0] (C++ based parser, you'd also need to write some bindings for lua) and [1] (Lua based parser for a subset of the format, abandoned for almost a decade).
There are times when using an external dependency might be a good idea, but a text-based file format that describes lines and can be implemented in a few lines of code is not one.
[0] https://github.com/svgpp/svgpp
[1] https://github.com/luapower/svg_parser
For anyone looking in this direction, Obsidian[0] with the excalidraw-plugin[1] is an awesome solution: Free for personal use and cross-platform.
[0]: https://obsidian.md/
People that liked this post may also be interested in drawit, a vim plugin that helps you create ascii diagrams.
https://github.com/vim-scripts/DrawIt
becomes a colored bar chart with three bars. So the file is both kinda readable in a plain text editor, in a browser with js disabled (with React server side rendering), and in the richest version with JS enabled. I don't have a WYSIWYG editor for the widgets though, that's pretty neat.
Full example:
Markdown:
https://github.com/phiresky/blog/blob/master/posts/2021/host...
Corresponding post with interactive widgets:
https://phiresky.github.io/blog/2021/hosting-sqlite-database...
Yes thank you, I was indeed alluding to https://github.com/akkartik/mu. Perhaps a more precise term would be "software stack".
Honestly, I just went with JSON because there's a nice Lua library for it (thank you https://github.com/rxi/json.lua).
I haven't thought about the file format much so far, just the experience of writing in it as if it's the "ground truth". We all seldom open our text files in a hex editor.