1. 39
  1.  

  2. 14

    Not much has changed since 2012 when this was published, Rust & Go (released in 2009/10) still don’t have any GUI libraries anywhere near as simple as REBOL, instead wrapping an older GUI system or using XML. In fact, most programming languages seem to expect you to make the GUI in HTML/JavaScript/CSS now, 6 years after this post. Even visual programming languages like Scratch rely on replicating textual elements with graphical puzzle pieces. Once you get into Piet or pureData, the language is visual, but I wouldn’t recommend trying to write a GUI app with an esolang like Piet, pureData, on the other hand, lets you create a simple or more complex GUI but it’s nothing you would traditionally consider code.

    1. 3

      Have you tried / what do you think of something like ImGui (especially when exposed to a “scripting” language)?

      1. 1

        Haven’t seen it before – looks good – and it’s been ported to Rust/Go & Javascript… https://github.com/ocornut/imgui

      2. 1

        I think that the we are still far away from the ideal library the article mentioned.

        Electron (for all it’s flaws) get’s fairly close. It’s not as descriptive, but HTML paired with a good CSS framework can get fairly close.

        There’s nothing that’s true native that comes even close though. I wonder how long it’ll take. Maybe with the advent of UIKit for macOS/iOS we’ll get another paradigm shift?

      3. 12

        I think that the author misses the point of having those command line tools available. It’s all about gradual development. Unix was designed for interchangeable parts that work together, making it as easy as possible to leverage work that others have done and replacing parts if they fail to work correctly, all the way up to the process level.

        This kind of interoperability has proven very difficult to accomplish pervasively with GUI applications. You have to standardize on some interface to exchange data, and not only that, create an intuitive method to compose programs together. Unifying the “small, composable tools” and “graphical interface” paradigms would require a drastic change in the way that current GUI applications work, so much so that it would likely break the dominant WIMP paradigm.

        The author was right: it’s easier to work with text, since your CLI applications already do it and that it doesn’t take extreme effort to try to use the applications in a different method than what the author thought of using it for. I think the best example of this has been Apple’s Automator. Sure, you can graphically script your Mac, but you only get the features that the application authors thought to give you.

        1. 4

          I might just add that Microsoft (with OLE), Apple (with MacOS classic, as well as AppleScript and Automator), Google (Android fragments, and now again with “stripes”) and many, many others have attempted to make “interchangeable” UI components. I think the closest to that today is something like React, where you really can just import a UI component.

          That being said, text isn’t exactly “simple.” For one, just text encoding can be tricky. On top of that, applications generally care about the structure of whatever text input they get, whether it be JSON or something else. That means parsers everywhere, which are themselves very complex. I think the PowerShell approach of communicating through objects is worthwhile, since at least in principle behavior can be bundled with data directly.

          1. 4

            This kind of interoperability has proven very difficult to accomplish pervasively with GUI applications. You have to standardize on some interface to exchange data, and not only that, create an intuitive method to compose programs together.

            If I understand you correctly, this is something Smalltalk “got right” nearly 40 years ago. All the GUI stuff can be seamlessly reused and composed. No text files needed. It’s actually very simple.

            Unifying the “small, composable tools” and “graphical interface” paradigms would require a drastic change in the way that current GUI applications work, so much so that it would likely break the dominant WIMP paradigm.

            Maybe, maybe not. The paradigm it clearly breaks is the one where standalone applications are the basic units of commercial value. Some of us may remember OpenDoc

          2. 6

            Even scratch is nothing but a bunch of structured data underneath, stored as text (with some blobs mixed in).

            https://en.m.wikipedia.org/wiki/.sb2_file

            A way to render it, and a way to write it. There’s nothing wrong with it.

            1. 1

              Hm. I can only access this site when my VPN is off. Not cool.

              Stories with similar links:

              1. The UNIX Philosophy and a Fear of Pixels via inactive-user 9 years ago | 11 points | 2 comments