1. 18

  2. 9

    Obviously, I’m not inventing all that. If you know about emacs, you know that that’s basically what they do, but instead of using stdin, stdout or execve, they just evaluate Elisp. However, what I think could be very interesting would be to allow native applications to do the same thing, with a native platform that would ship without any real applications (so unlike emacs), and let applications implement their own workflow.

    So close…and yet so far

    1. 3

      At first I found it funny that you linked CLOSOS (people often refer to it in a “meme-y” way).

      Now that I’ve read the article, I agree that CLIM-style listener should do the trick :P

    2. 7


      What’s interesting to me is that IMO development tools are kind of a red herring here. What you’re really speaking to is the fact that the *NIX “everything is a stream of bytes” interface between applications is amazing for certain classes of interaction but starts to fall down when we want richer/higher levels of abstraction pipelines.

      Tools like nu and elvish try to augment this with their own models, but ultimately very few programs actually support them, and that’s the missing link as far as I’m concerned.

      One of the reasons things like Powershell with its object pipelines or even AppleEvents/AppleScript with its dictionaries and verbs models are so successful is that they’re pervasive and supported by the operating system as well as by many applications.

      Can you tell this is something I’ve thought about a fair bit? I’ve been champing at this particular bit ever since the sunset of the Amiga platform, where we could use AREXX to glue applications together in rich, interesting, expressive ways.

      1. 8

        I didn’t find it that great—it read like any of a hundred other posts I’ve read about how computing sucks and instead things should be done a completely new way (and I’ve been reading these since the early 90s, and none have come to pass). The only saving grace of the article (to me) was the last paragraph, where the author admits it won’t get done unless they write it, and even then, it might not be accepted by others.

        1. 3

          That’s interesting. I guess I’ve gotten to the point where I rather ignore such negativity because it’s SO INCREDIBLY PERVASIVE in our industry.

          What I enjoyed about the article was more the idea of “Hey existing paradigms have some serious limitations. Wouldn’t it be great if we could have something richer?” - because that’s a question I don’t see being asked nearly often enough.

          People seem to get locked into current paradigms as The Way of Heaven. UNIX’s “Everything is a stream of bites” is a totally awesome paradigm but it’s not the only paradigm and it’s also not a reason to stop innovating.

          Perhaps I was reading between the lines too much but that’s what I got out of it :)

          1. 4

            I’m not kidding when I say I’ve been seeing these since the early 90s—TUNES is one such example. Ended up nowhere. LoperOS is another one. Blue Abyss is a third one, and those are just the ones off the top of my head. Lots of pontificating, little work. At some point, I got tired of the questions, and now I just want to see some answers.

            1. 1

              I can appreciate that. I REALLY can!

              It’s especially frustrating when you’ve SEEN and EXPERIENCED better answers, and because of Worse is Better, we ended up backsliding into a place which works for 90% of use cases so it thrives and obliterates everything else in its path.

              But for me anyway I’m still willing to encourage the asking. At least people are recognizing that better is a thing that COULD happen.

      2. 7

        It’s 2022. Today, developing a library, an application or a service is a totally different experience from what it used to be only a few years ago. Every professional engineer or programmer is expected to know tools like git, a coding editor, a terminal to run various commands, like compiling, testing, etc.

        Sounds like totally the same experience as 2012. And the same as 2002 only it was SVN then. And the same as 199x only it was CVS (or Projector if you were in Apple’s bizarro-world ‘classic’ ecosystem.)

        1. 4

          Composing two GUIs between each other should be something that is widely supported, and standardized.

          My guts tell me that if we fix that, we fixed most accessibility issues.

          1. 5

            Website doesn’t work without JavaScript

            1. 1

              On the topic of criticizing design,

              .content :is(blockquote, p, ol, ul) {
                max-width: 64ch; /* or 60-70 */

              would go a long way towards readability–the lines are way too long. The rivers from justified text makes it harder to read too. Another offense is using <blockquote>s for admonitions/call-outs as the spec says these elements are for quoting sources–and the who-to-blame is limitations with Markdown for not supporting these kinds of elements (good thing there are alternatives).

              The blockquote element represents a section that is quoted from another source.

              Content inside a blockquote must be quoted from another source, whose address, if it has one, may be cited in the cite attribute.

            2. 3

              Kitty’s shell integration allows you do many cool things like opening the output of the last command in a pager. I think it should be possible to use that mechanism to get your last output in a shell variable.


              1. 2

                I’m curious about how that works. If you’re able to get it into the shell, is that driven by the shell emitting escape codes that are interpreted by kitty to cause it to send the last output as input to the terminal? It feels like that could be a serious security issue if you can cause someone to, say, accidentally emit such an escape sequence from untrusted user input.

                1. 2

                  The protocol is described at the bottom of this page: https://sw.kovidgoyal.net/kitty/shell-integration/

                  1. 1

                    The part of the protocol described there seems to be how the shell should delimit sections of output, which makes sense. I’m more curious about how you would retrieve those sections, to get the contents of one of them (such as the output of the last command) in a pager or a shell variable from wherever it is stored inside kitty.

                    1. 2

                      Gotcha. For common cases (like if you wanted a way to easily copy the last command output), you would do something like this: https://github.com/kovidgoyal/kitty/discussions/4477#discussioncomment-2077030

                      If you wanted to do something more complex, you can use kitty’s scripting interface: https://sw.kovidgoyal.net/kitty/kittens/custom/#passing-the-contents-of-the-screen-to-the-kitten

              2. 3

                I really liked this bit:

                I have started a project on my spare-time to try and change how programs would work with their environment

                Jokes aside, that was a great read.

                1. 3

                  Didn’t have time to read it all yet, but one fragment jumped at me:

                  (…) you will oftentimes run a command, see its result, then run the command again, piping it to a filter command or sort or field extractor like [jq]. If the output is too long, it’s likely you will output into a file and will work on that file (…)

                  Sorry if that’s addressed further down in the article (didn’t notice while skimming); assuming not, I’d recommend taking a look at Ultimate Plumber (disclaimer: /me = up’s author).

                  Also, I’m currently working at Enso, which will hopefully eventually help alleviate this and some other issues as well. (I hope this will show up to be an understatement of the year.)

                  1. 2

                    I think having caching of prior results by default would be very worthwhile. My approach to thinking about this has been to make ninja the default. Much of the queries that I do through the shell would be well suited to a pure, reactive workflow.

                    Agreed that GUI doesn’t need to be mouse driven. Imo, http with ssh port forwarding also solves a lot of the problems with remote and local APIs such as avoiding x11 forwarding.

                    CLI pipelines resulting in structured data is valid. A binary description language / protocol to reduce the serialization and deserialization penalty, sure.

                    However, tui aside, much of CLI tools are an execve interface to setting up a data pipeline. I think that the MVC folks have a good point about separating your data pipeline from your view on that pipeline. This implies that CLI tools shouldn’t communicate in terms of UI primitives, and that GUI view shouldn’t be composed.