• 1 Post
  • 38 Comments
Joined 1 year ago
cake
Cake day: June 14th, 2023

help-circle

  • You tried to apply far too much pressure over too large a surface area. Either make a more focused approach by not chasing Free Software and XMPP supremacy at the same time, or find ambient ways to give people options without forcing them to make choices in the direction you want. In particular, complaining about bridges usually doesn’t get the discussion to a useful place; instead, try showing people on the other side of the bridge how wonderful your experience is.

    Also, I get that you might not personally like IRC, but you need to understand its place in high-reliability distributed systems before trying to replace it; the majority of them use IRC instead of XMPP for their disaster recovery precisely because its protocol jankiness makes it easier to wield in certain disaster situations.



  • I’d love to link you to their Wikipedia pages, but both of them are redlinked. As far as I can tell, Dr. V. Ronald was an educator who moved from Canada to the USA as part of the whole Xerox PARC thing and probably was valued for mainframe experience; does anybody have a full bio? The current maintainer is Ron Sunk, who did a full run at MIT up through postdoc before going to Red Hat. The names are a coincidence; runk implements what we now call Sunk summation, after Sunk’s thesis. (As you might guess, that’s an instance of Stigler’s law, since clearly Dr. Ronald discovered Sunk summation first!)

    Also, as long as we’re here, I want to empathize a little with Sunk. The GUIs that folks have placed on runk, like GNOME’s Gunk or Enlightenment’s enk, look very cool, and there’s rumors of an upcoming unified number-counting protocol that will put them all on equal ground. But @MossyFeathers@pawb.social wasn’t joking; Dr. Arnold’s code literally only reads punch cards, and there’s a façade to make it work on modern Linux and BSD transparently. It predates X11, if that’s any help. The tech debt is real.


  • Because frankly, Ronald (the current maintainer, not the original author) is very competent. I say this as somebody who has personally been yelled at by Ronald at a kernel summit; I didn’t deserve it, but none of his technical points were wrong. I like to think of myself as the kind of person that, given enough time and documentation, can maintain anything; I think it’d still take three of me to do Ronald’s job. (Well, “job.” I think he technically works for Red Hat or something?) Not to excuse his conduct, just to explain why he’s not been replaced yet.















  • Your code looked alright. Working in C is a risky chore. You’re early in your journey and I think it’s good to get a taste of many of the traditional techniques before turning towards newer fancier algorithms.

    “Haskell and OCaml”, hm? The two concepts you need to internalize are katamorphisms and paramorphisms. You may have heard of “recursion schemes”; these two schemes are the ones available on any tree. Fundamentally, most of a compiler is tree-to-tree transformations (nanopasses), and they are expressible as one of two forms:

    • Katamorphism: The leaves of each node are transformed before the branch (bottom-up)
    • Paramorphism: The leaves are transformed after/during the branch transformation (top-down)

    If you look again at my AST builder builder, you’ll see .run() and .walk() methods, implementing the recursion for any katamorphism or paramorphism respectively. In Haskell, these are called Traversable types. This is a pun in Monte, where .run() is also the default method; the syntax makes it easy to perform a katamorphism by passing a tree-traversing object directly to the AST.

    Your types are alright, but you’ll want to pass a generic parameter through them, turning them into a valid Functor in Haskell or a generic module in OCaml. This is a basic defense against the “AST Decoration Problem”, AKA the “AST Typing Problem”. As you add features to your compiler, you’ll realize why these are necessary.