The other project I am continuing to work on is Rad [1], a programming language tailor made for writing CLI scripts. It's not for enterprise software, it specializes specifically in CLI, offering all the essentials built-in, such as a declarative approach to arguments and generated help (as opposed to Bash where you have to roll your own arg parsing and help strings each time).

[0] https://github.com/amterp/kan

[1] https://github.com/amterp/rad

I use it for all my personal projects. Any new project where I will have todo lists, I'll run `kan init` and `kan serve`, and begin tracking tasks. Because it's a CLI, you can interact with the board thru the CLI with commands like `kan add` and `kan edit`, so I've even included a SKILL markdown file in the repo which I use to let Claude read and interact with my boards. You can also navigate all your boards from a single `kan serve`, so it's convenient and snappy cross-project too.

[0] https://github.com/amterp/kan

I thought the "dont let agents finishing interrupt you" workflow was an interesting point. I've set up chime hooks to basically do the opposite, and this gives me pause to wonder if I'm underestimating the cost of context switching. I'll give it a go.

    #!/usr/bin/env rad
    ---
    Dev automation script.
    ---

    args:
        build   b bool    # Build the project
        test    t bool    # Run tests
        lint    l bool    # Run linter
        run     r bool    # Start dev server
        release R bool    # Release mode
        filter  f str?    # Test filter pattern

        filter requires test

    if build:
        mode = release ? "--release" : ""
        print("Building ({release ? 'release' : 'debug'})...")
        $`cargo build {mode}`

    if lint:
        print("Linting...")
        $`cargo clippy -- -D warnings`

    if test:
        f = filter ? "-- {filter}" : ""
        print("Running tests{filter ? ' (filter: {filter})' : ''}...")
        $`cargo test {f}`

    if run:
        bin = release ? "target/release/server" : "target/debug/server"
        $`./{bin}`


    Usage: ./dev -b (build), ./dev -blt -f "test_auth" (build, lint, test auth), ./dev -r (just run).

[0] https://github.com/amterp/rad

Lately I've mainly been working on stability and bug fixes. I've released some big features the past few months so I'm doing a big push on polish, before I again tackle some larger features that I'd like to implement.

If CLI scripts is something you're interested in at all, give it a go! We have docs and a guide [1] for getting started, feedback very welcome :)

[0] https://github.com/amterp/rad [1] https://amterp.github.io/rad/guide/getting-started/

I'm currently using Material for MkDocs but was thinking of switching off it, in part due to the lack of options around having custom highlighting in code blocks (my docs website is for a programming language I am working on). What are Zensical's plans here? Tree sitter highlighting would be perfect in my case.

Folks interested in scripting like this might like this tool I'm working on https://github.com/amterp/rad

Rad is built specifically for writing CLI scripts and is perfect for these sorts of small to medium scripts, takes a declarative approach to script arguments, and has first-class shell command integration. I basically don't write scripts in anything else anymore.

  args:
      username str           # Required string
      password str?          # Optional string
      token str?             # Optional auth token
      age int                # Required integer
      status str             # Required string
  
      username requires password     // If username is provided, password must also be provided
      token excludes password        // Token and password cannot be used together
      age range [18, 99]             // Inclusive range from 18 to 99
      status enum ["active", "inactive", "pending"]

Very keen for feedback so if any of that sounds interesting, feel free to give it a go!

https://github.com/amterp/rad

[0] https://github.com/amterp/rad

  args:
      username str           # Required string
      password str?          # Optional string
      token str?             # Optional auth token
      age int                # Required integer
      status str             # Required string
  
      username requires password     // If username is provided, password must also be provided
      token excludes password        // Token and password cannot be used together
      age range [18, 99]             // Inclusive range from 18 to 99
      status enum ["active", "inactive", "pending"]

[0]: https://github.com/amterp/rad

Please check it out if it sounds at all interesting! Keen for feedback :) I've written some docs, including a "getting started" guide, linked in the GitHub page.

I'm taking a lot of inspiration from Python in the syntax and I'm actually worried it will trip up any LLM I train on my language since I think it will risk probabilistically just reverting to Python mid-answer Time will tell

I don't blame anyone in the picture, I don't disagree that time saved with LLMs can be well worth it, but it still is a topic I think we in the PL community need to wrestle more with.

Keen to hear people's thoughts and feedback! GitHub here: https://github.com/amterp/rad

The docs site also contains a guide for getting started, including some of the unique features: https://amterp.github.io/rad/guide/getting-started/