3 ms·

>Unfortunately the world now revolves around [gui] web browsers. We brought this technologically retarded hellscape on ourselves and we deserve it. This seems

by pb7 4y ago

>Unfortunately the world now revolves around [gui] web browsers. We brought this technologically retarded hellscape on ourselves and we deserve it. This seems backwards. Limiting yourself to CLI tools do retard your abilities, modern GUI apps do not.

kkfx 4y ago
Sorry? CLI respect of Emacs yes, is limited and limiting, but modern GUIs are FAR more limited and limiting. Can you integrate them? No. Let's say you want in a single view a set of mails, financial transactions, notes etc. You can arrange something in a CLI, you can do it in org-mode, you can't do it in the most advanced ERP monster. Modern UIs try to go back to the original document UI concept but TOTALLY fails for the interactive part, they are mere view where you can touch some knobs someone else placed there for you, nothing more, and try to bend them is a nightmare.
- kube-system 4y ago
  What can't you do in X Window that you can do in a terminal? I'd agree that some GUIs are bad, but the same could be said about some TUIs.
  - kkfx 4y ago
    Not in, but with modern GUIs (so X11 xlibs wrapped by some widget lib) I can't compose nor integrate anything. For instance if I want to do some simple math in an email I'm composing I need to launch another application, type the same math I've typed in the message body, evaluate it, copypaste the results, copy-pasting is the sole IPC such tools have. On a terminal, I can run a terminal based editor who typically can run code from inside the text buffer. In Emacs I can do much more in both terminal and X11. That's is. My org-mode notes links anything, meaning mails (searches, specific messages, threads), financial transactions (ledger), elisp code, for instance to act on notes themselves like an `* Online retails orders` heading with a "click here to add a new one" or to change the Emacs/EXWM graphic, for instance to present something, org-ql queries on my notes etc. In pure CLI (not TUI) I can at least cat and process programs output, in modern GUIs I can't. A simple showcase: https://youtu.be/B6jfrrwR10k https://youtu.be/B6jfrrwR10k
    - kube-system 4y ago
      This is a matter of pattern, not technology. GUI apps can and sometimes do provide interfaces for programmatic use. And some terminal applications fail to follow conventional Unix patterns.
- zdragnar 4y ago
  This seems like an unfair comparison. If you limit the capabilities of a GUI interface to only what is possible without code changes, then you must do the same for CLI applications. Emacs is all code. Most CLI-only applications cannot be modified other than the flags you pass in; you are instead forced to pipe from one application to another. If you limit the capabilities of GUI applications to the realm of existing software (i.e. your monster ERP reference) then we must also limit the capabilities of CLI tools to what exists, and I know (for having looked far and wide) that I have needs which are not available via terminal-only programs; the only existing set of available software that I need with a comprehensive set of features is in a GUI-only application.
  - kkfx 4y ago
    That's exactly the original Unix model fault: it's designers though that's possible making many very small and simple "programs as functions" to be easy combined in scripts and with IPCs to doing almost anything without the need to go to "system code" as a cheap and easy solution to the hardness of a classic system design. They quickly drop such idea introducing GUIs, who fail to offer composability and scripting, and they derailed hitting their own design limits. Modern GUIs are the monster emerged form such ashes who happen to be worst than the problem it try to solve. The issue in the example comparison in my previous post is that at least in CLIs you can combine/compose a bit, with modern GUIs you can't. Write a script is easy, at least FAR easier than change an ERP.
- pb7 4y ago
  The GP lists some ways that a terminal-only workflow limits you. >Modern UIs try to go back to the original document UI concept but TOTALLY fails for the interactive part, they are mere view where you can touch some knobs someone else placed there for you, nothing more, and try to bend them is a nightmare. I don't see this as a bad thing. I want someone responsible for the product to figure out the best way to use it via a focused set of controls and inputs. Some people fail at this, others are amazing.
  - kkfx 4y ago
    Just a simple example: you probably buy on Amazon and find it's order history webpage simple and nice. Now let's say you want to collect such history in your desktop, link it to the corresponding bank transactions per any order (you have bought many things and they are charged separately on your bank), link to some bought items notes like when the warranty period end in your agenda. What do you need to achieve such result? In CLIs you need a way to query in text all such elements, you are limited by the limited and limiting Amazon WebUI who do not offer anything cat-able, even not anymore a manual *sv export. Not much different is the situation on your bank side where if you are lucky you just get manual ofx/qif export. In a classic CLI world you wold have a remote service who can be queried ssh-in it and locally process the output. In modern Emacs you can do the same in a modern 2D DOCUMENT-BASED GUIs. You just need a bit of math to mach items to bank transactions, nothing more than 20 SLoC. With the WebUI paradigms you need perhaps a WebVM extension with around 5-10k SLoC to achieve something similar...
    - pb7 4y ago
      I don’t actually. Amazon is on the “fail” list. It sounds like you want APIs for all of your services. That’s fair. But I don’t think the vast, vast majority of people have use cases as you describe so the ROI on providing something and maintaining it is too low. In any case, in today’s world, you can programmatically scrape the page of the results and crawl further pages if necessary. It wouldn’t be 5-10K lines to output a list of names and prices.

by pb7 4y ago

kkfx 4y ago

Sorry? CLI respect of Emacs yes, is limited and limiting, but modern GUIs are FAR more limited and limiting. Can you integrate them? No. Let's say you want in a single view a set of mails, financial transactions, notes etc. You can arrange something in a CLI, you can do it in org-mode, you can't do it in the most advanced ERP monster. Modern UIs try to go back to the original document UI concept but TOTALLY fails for the interactive part, they are mere view where you can touch some knobs someone else placed there for you, nothing more, and try to bend them is a nightmare.

kube-system 4y ago
What can't you do in X Window that you can do in a terminal? I'd agree that some GUIs are bad, but the same could be said about some TUIs.
- kkfx 4y ago
  Not in, but with modern GUIs (so X11 xlibs wrapped by some widget lib) I can't compose nor integrate anything. For instance if I want to do some simple math in an email I'm composing I need to launch another application, type the same math I've typed in the message body, evaluate it, copypaste the results, copy-pasting is the sole IPC such tools have. On a terminal, I can run a terminal based editor who typically can run code from inside the text buffer. In Emacs I can do much more in both terminal and X11. That's is. My org-mode notes links anything, meaning mails (searches, specific messages, threads), financial transactions (ledger), elisp code, for instance to act on notes themselves like an `* Online retails orders` heading with a "click here to add a new one" or to change the Emacs/EXWM graphic, for instance to present something, org-ql queries on my notes etc. In pure CLI (not TUI) I can at least cat and process programs output, in modern GUIs I can't. A simple showcase: https://youtu.be/B6jfrrwR10k https://youtu.be/B6jfrrwR10k
  - kube-system 4y ago
    This is a matter of pattern, not technology. GUI apps can and sometimes do provide interfaces for programmatic use. And some terminal applications fail to follow conventional Unix patterns.
zdragnar 4y ago
This seems like an unfair comparison. If you limit the capabilities of a GUI interface to only what is possible without code changes, then you must do the same for CLI applications. Emacs is all code. Most CLI-only applications cannot be modified other than the flags you pass in; you are instead forced to pipe from one application to another. If you limit the capabilities of GUI applications to the realm of existing software (i.e. your monster ERP reference) then we must also limit the capabilities of CLI tools to what exists, and I know (for having looked far and wide) that I have needs which are not available via terminal-only programs; the only existing set of available software that I need with a comprehensive set of features is in a GUI-only application.
- kkfx 4y ago
  That's exactly the original Unix model fault: it's designers though that's possible making many very small and simple "programs as functions" to be easy combined in scripts and with IPCs to doing almost anything without the need to go to "system code" as a cheap and easy solution to the hardness of a classic system design. They quickly drop such idea introducing GUIs, who fail to offer composability and scripting, and they derailed hitting their own design limits. Modern GUIs are the monster emerged form such ashes who happen to be worst than the problem it try to solve. The issue in the example comparison in my previous post is that at least in CLIs you can combine/compose a bit, with modern GUIs you can't. Write a script is easy, at least FAR easier than change an ERP.
pb7 4y ago
The GP lists some ways that a terminal-only workflow limits you. >Modern UIs try to go back to the original document UI concept but TOTALLY fails for the interactive part, they are mere view where you can touch some knobs someone else placed there for you, nothing more, and try to bend them is a nightmare. I don't see this as a bad thing. I want someone responsible for the product to figure out the best way to use it via a focused set of controls and inputs. Some people fail at this, others are amazing.
- kkfx 4y ago
  Just a simple example: you probably buy on Amazon and find it's order history webpage simple and nice. Now let's say you want to collect such history in your desktop, link it to the corresponding bank transactions per any order (you have bought many things and they are charged separately on your bank), link to some bought items notes like when the warranty period end in your agenda. What do you need to achieve such result? In CLIs you need a way to query in text all such elements, you are limited by the limited and limiting Amazon WebUI who do not offer anything cat-able, even not anymore a manual *sv export. Not much different is the situation on your bank side where if you are lucky you just get manual ofx/qif export. In a classic CLI world you wold have a remote service who can be queried ssh-in it and locally process the output. In modern Emacs you can do the same in a modern 2D DOCUMENT-BASED GUIs. You just need a bit of math to mach items to bank transactions, nothing more than 20 SLoC. With the WebUI paradigms you need perhaps a WebVM extension with around 5-10k SLoC to achieve something similar...
  - pb7 4y ago
    I don’t actually. Amazon is on the “fail” list. It sounds like you want APIs for all of your services. That’s fair. But I don’t think the vast, vast majority of people have use cases as you describe so the ROI on providing something and maintaining it is too low. In any case, in today’s world, you can programmatically scrape the page of the results and crawl further pages if necessary. It wouldn’t be 5-10K lines to output a list of names and prices.