Gemini* and Gopher

• Personal/Opinions

  • 🔤SpellBinding: ACHWNSI Wordo: EASED

  • Infection

    minor cat scratch infection but not from my cat :(

  • 🖼️ xkcd: Grounded #3124

• Technology and Free Software

  • One Big Org Text File

    Occasionally, blog entries note degraded performance when org files grow to a big number of lines.

    One of the outcomes of the Old Computer Challenge is that I have dropped Emacs denote for writing phlog posts, and replaced it with a simplified Elisp script. I am thinking about also dropping denote for my notes, excluding another dependency. As an alternative I am thinking of moving towards "One Big Text File" (OBTF), of course in the format of One Big Org Text File.

  • Internet/Gemini

    • Lagrange v1.18.6 released

      There are new builds of Lagrange available with the following changes:

      * Added Samogitian (sgs) UI translation.

      * Link icons are now included in the clickable part of a line. Previously, only the link text was clickable.

      * Fixed handling of percent-encoded semicolons in the URI path component.

      * Fixed crash when opening context menu in some input fields.

      * Updated UI translations.

    • There is no stagnation

      There's been some discussion (via Antenna and on the BBS) about supposed stagnation in Gemini.

      [...]

      Gemini provides a relatively poor source of positional/status goods for people who want to "improve" the underlying system. What is *does* provide is a bunch of forums that get flood-filled by agitation against the very essence of Gemini itself. Yet here we are half a decade later still running the same software.

      If you reject the very principle that protocols and software can be basically "finished", you're going to have an issue with Gemini. We just have to live with that.

      For software's permanent revolutionaries, Gemini sucks and it must be painful to see one's cherished ideas traduced. But for digital gardening, Gemini works very nicely. There's much less friction getting content online. Similarly for blogging.

  • Programming

    • When vibe coding, isn't the source code the prompt?

      I've been thinking about “vibe coding” (probably overthinking) and how that might effect development in odd ways. And by “vibe coding” I mean in its original meaning [1], “where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.” Since February, I've come across several projects, some commercial, that have been “vibe coded” in such a manner. And I found myself asking myself, what's the source code in this case? What file should be checked into source control? And my answer was “the prompts, of course.”

      I have a project where I need to parse HTML (HyperText Markup Language), and I wrote some PEG (Parsing Expression Grammar) code [2] to do it. But the code I checked into source control wasn't the resulting C sludge that came out of the tool, but the PEG code itself—that is the source of … um … the source, as it were. If I want to change the parser, I don't change the C code, I change the PEG code and regenerate the C code. I don't necessarily care about the C code output, much like I no longer necessarily care about the assembly output from the C compiler. And there are many DSL (Domain-specific Language)s out there that “compile” into some other code like C or Rust, and in those cases, it's the file that contains the DSL that is checked into source control, not the resulting output of the tool.

    • Re: When vibe coding, isn't the source code the prompt?

      The concept that AI prompts "are the source code" isn't really far fetched. At least not when you think about who actually uses Vibe Coding as a "useful tool."

      A friend of a friend was telling me the other day about a mobile app idea they had. Having some sort of background loosely based in tech, they spun up their Vibe Coding IDE, gave it a prompt and within a few hours had some working code. The project itself isn't relevant, but needless to say the project is taking library X and outputting it to library Y and that is it. Nothing complex, something that almost wouldn't need a Proof of Concept task in a real development environment. But they wanted to see if it could be done and I guess that is what Vibe Coding is all about.

      We discussed it a little, I brought up my background in system design, software development and technical writing. They asked if I used Vibe Coding in my day job and I said no. The point of Proof of Concept development and R&D in general is to not only explore the possibilities, but to learn and understand the technology. You are learning where to find documentation, identify pitfalls of the solution you are investigating, and getting yourself familiar with the overall concepts of what you are trying to build. When you Vibe Code you lose a lot of this. There is a reason why when learning a new tech stack or programming language we start with a real world project to actually learn the concepts. You need to grow that muscle memory.