Notes from the desk of a wolf

Blogging again, and what I've been up to

2026-04-29T00:00:00-00:00

I think I'm warming up to the idea of having a personal blog. Of course, being myself, I re-wrote my static site generator in OCaml, and then re-wrote it again just to add support for blogging.

How does it feel? Good, I think. Many times ago I tried this I didn't consider the end result worth the effort, so it makes me feel good that now I have a plan for this.

What goes in a first post? Maybe a recap of what I've been doing lately:

Growl, my programming language, was re-written from C to OCaml this month, and gained a static type system based on subtyping along with a type inference algorithm inspired by SimpleSub.

Currently I'm weighing the benefits of principal type inference in a concatenative language. Types in applicative languages, like OCaml, are more well-behaved, and give you better errors when something goes wrong.

In concatenative languages, this is not the case. I've had to add more and more heuristics to the type inference algorithm to discern from a "good type" and a "bad type that still looks good", and the existence of type annotations was bolted in after I noticed that some programs give types that are too general.

An example of the latter point is the definition for list/each in the current (unpublished) branch with support for ADTs:

type a list 
  { nil
  | cons : a, a list
  }

def list/each
  [..r, a list, [..r, a -> ..r] -> ..r]
  { list/case: swap
      [drop]
      [swap unbury [unbury drop call] 3keep
       swap drop list/each];
  }

That annotation is required, or else the type inference algorithm gives list/each a type of [..r, a list, [..r, a -> ⊤] -> ..r] (where ⊤ is the "top" stack). Since we lose track of the stack returned by the quotation given to list/each, it can, for example, push values to the stack indiscriminately, and the type inference will have de-synced from the actual result of the program, and that's no good.

Of course, the language doesn't really stop us from doing that with the correct annotation, it just returns a weird recursive type of [(..r & μr. (..r, nat & ..r)) -> (..r | μr. (..r, nat | ..r))]:

def main 
  { list/each: {1 2 3 4}
      [];
  }

Whether we should reject words with recursive types or not is a heuristic I haven't touched on yet. There's also the problem in that the type inference can't infer the types of useful combinators, like bi@, but I've decided to just ignore them for the meantime.

So for Growl, the updates are a resounding "meh", but that's okay. I'm not like a type theorist, I'm just a guy playing around with their computer.

I've also been working on an album, titled Dogyears, but you'll be hearing more about it during the year as I get it done.

Stop doing computers!

2025-02-01T00:00:00-00:00

Today I looked at my phone (a Motorola Moto G85), and saw six new application icons on my app drawer. I recognized those icons, they were the same applications it installed during the first setup I went through when I first got this phone: various games which I can only assume are ad-ridden and have some sort of deal with Motorola/Lenovo to get them installed in as many phones as they can.

Fortunately, Android provides the user with the ability to see what installed an application in their device, and in this case, they were all installed by an application by the name of "Moto App Manager".

If you search for that name you'll get lots of results from places like Reddit, some blogs or review sites, and even Lenovo's community forums, about what the app does: installing "helpful suggested apps".

For a similar story related to the point I'm about to make, this exact same phone runs out of memory every week or so for no reason, and until I restart it, it just... doesn't work correctly. Apps crash for no reason, anything that uses the fingerprint reader refuses to work, crashing when the dialog is normally shown, the tap-to-pay functionality doesn't work, nothing works until I hit restart and wait five whole fucking minutes or more for the phone to boot up.

I'm tired of having to jump through hoops to get "solutions" to problems that shouldn't have even been problems to begin with.

For example, I posted about this on Mastodon as a rant and one of the responses I got went along the lines of "oh, you can disable the app for good by getting into USB debugging mode and sending commands to the phone to freeze the application.", and it's ridiculous that I (or anyone else for that matter) should be expected to jump through hoops of that kind just to make my phone just slightly more usable.

If I told any of my family members that they have to restart their phone every once in a while otherwise it starts acting up, or that I need to connect their phone to my computer and send it commands to stop it from installing apps they never asked for, they'd start wondering whether the phone is malfunctioning or something like that.

And that's the problem. Why do I, or anyone who is slightly tech-savvy, have to cope with tricks and hoops and general fuckery with everything we are forced to use to make it usable? Why do the rest have to either just "get used to it" or have to ask for help to make their devices more pleasant to use?

"Just go to this hidden section in the settings and disable this switch, but only after 4 dialog boxes asking you if you really want to!"--- "You need to disable this application by sending commands from your computer so it won't install shit bloatware that you'll never need!"

Statements dreamed up by the utterly deranged.

We're basically letting abusive practices in technology hold us hostage.

Thanks to my friend Spencer who helped me with proofreading for this post! :)

Unmaintained, dead, or just finished?

2023-11-04T00:00:00-00:00

What happens when a project reaches a point where no new features are needed? Is it really "unmaintained" if there's nothing left to do? Sure, you could add more features, but if the "core" of what you have works, and you've built projects with it, is it really worth it?

I've been thinking about this for a while now, after I saw a conversation on the MoonScript Discord guild which went roughly like this:

A: Are there any plans for type declarations in MoonScript?
B: No, and there'll never be due to MoonScript being unmaintained.

Come to think of it for a moment, the Lapis web framework, which is being used in production by itch.io and other projects from Leaf, is written in MoonScript (as well as most code using said framework). Lapis sees new releases regularly (last one being two days ago), so it's safe to say it's not an "unmaintained" project, and a relief, considering it's used in production.

But this means that, by proxy, MoonScript is also used in production, so... what gives?

Nothing, honestly. I wouldn't say MoonScript is dead, since people are clearly writing code with it today, but I also wouldn't say it's unmaintained, even if it hasn't seen a release in roughly 7 years. I'd argue there's different contexts for when a project is "dead", "alive" or "unmaintained", and when it comes to compilers (or more specifically transpilers, in the case of MoonScript), I'd say it basically boils down to the status of the target language (and we all know Lua isn't dead.)

Of course, if it were something like a web framework, or otherwise a project in an area that moves fast, sadly things die fast, but we're not on that level... yet.