Dayaml Alternatives

dayaml reviews and mentions

• System Design of a Cellular APL Computer
  2 projects | news.ycombinator.com | 19 Apr 2025

  My YAML loader[0] is where I first broke through the wall. It's still languishing in a relatively proof-of-concept state but does exhibit the basic design principles.

  There's also a Metamath verifier that does parallel proof verification on the GPU. It's unpublished right now because the whole thing is just a handful of handwritten code in my notebook at the moment. Hoping to get this out this month, actually.

  A DOOM port is bouncing around in my notes as well as a way to explore asynchronous APL.

  I'm also helping Aaron Hsu in his APL compiler[1] for stuff adjacent to my professional work, which I can't comment on much, unfortunately.

  Et hoc genus omne

  [0]:https://github.com/xelxebar/dayaml

  [1]:https://github.com/Co-dfns/Co-dfns

• StrictYAML
  5 projects | news.ycombinator.com | 7 Mar 2025

  I totally feel you on the implementation side. The formalization used in the spec leaves a lot to be desired, and the spec devs seem to recognize this well. One of the aims of my dayaml[0] project is to explore a completely different formalization that rationalizes out the non-fundamental sharp edges.

  That said, there really aren't that many special cases. A lot of the them are UI features, arguably endemic to the problem space in one form or another.

  The deficiencies you see in the language, however, don't ring true with me. They are mostly implementation deficiencies:

  - Anchors are just pointers. YAML can efficiently represent generic object graphs, but if a loader copies those pointers into a billion laughs, that's an issue with the implementation decision. Usually, it comes down to assuming that YAML graphs are always trees, which will always turn cyclic graphs into infinite tree unfoldings.

  - Keys are explicitly specced as unique [1]. Not really sure why libyaml and friends get this wrong.

  - Loading YAML to objects is explicitly designed to represent the native data structures of your language. It's a serialization format by design. That's why it loads into objects. That's why it has complex keys.

  We can certainly discuss whether YAML is appropriate as a configuration language or not, but YAML is first and foremost designed as a language-agnostic textual representation of object graphs. The spec goes well out of it's way to make this clear, and viewing YAML for what it is, instead of a configuration language, really makes the apparent oddities disappear IMHO.

  [0]:https://github.com/xelxebar/dayaml

  [1]:https://yaml.org/spec/1.2.2/#mapping

  [2]:https://yaml.org/spec/1.2.2/#11-goals

• APL Demonstration (1975) [video]
  1 project | news.ycombinator.com | 26 Jun 2024

  Hard disagree. I wrote a YAML parser in APL[0], set it aside for 8 months, and then one day decided to read through it while getting a haircut. I can happily report that the full 22 lines were very grokkable. In fact, I even found a bug and now have several ideas for a rearchitecture I'd like to work on.

  APL just looks unfamiliar. Don't confuse that with unreadability. IMHO, the ergonomics for expressing and communicating high-level specifications just blows other languages out of the water. And those specifications also happen to also be executable implementations with leading-edge performance to boot.

  Admittedly, though, the learning curve is painfully steep. I think it's worth it though.

  [0]:https://github.com/xelxebar/dayaml

• YAML Parser for Dyalog APL
  4 projects | news.ycombinator.com | 8 Jan 2024
• k on pdp11
  6 projects | news.ycombinator.com | 8 Jan 2024

  I've been knee deep in APL for the past year, working on a YAML parser: https://github.com/xelxebar/dayaml. It's still very prototypy, but for ~30 lines of code it's surprisingly complete.

  The process of getting that project to where it is now really revolutionized how I think of software development in general and how I manage my dev teams at work. Our best practices and wisdom around software dev really are much more strongly tied to historical habits and tooling whims than we'd like to believe. I believe we as a community have a lot of unpicked fruits laying around if we shift focus onto the human side of Human-Computer Interfacing for a while.

  About K, though, Arthur Whitney sounds like such a beast, and I would love to mingle with the K community. Within the array programming circles, APL/J/BQN form one cluster and K looks like it's off on its own a bit with different ideas and a laser focus on high performance. Extremely enticing.

• A note from our sponsor - SaaSHub
  www.saashub.com | 9 Jun 2026

  SaaSHub helps you find the best software and product alternatives Learn more →