Hacker News new | past | comments | ask | show | jobs | submit login

The problem with GUIs (I assume you mean them by "actual user interfaces") is that they rely too much on the user's memory, and that they do not scale, especially for the cloud systems.

I have many text notes which record various commands. I have them because it is so easy -- once you figured out how to do something, get the history and copy relevant stuff. At work, we share the commands on Slack, put them into Wiki, paste them in the docs, and so on. If the commands grow too complex, they turn into scripts -- after all, scripts are just file rename away.

I don't think I could do this efficiently I had to use GUIs. Theoretically, I could write an manuals with dozens of steps[0], but this is much more significant effort, and they'll likely go stale anyway.

[0] https://docs.microsoft.com/en-us/iis/application-frameworks/...




You are confusing command line and terminal here, I believe. Note how OP was specifically using emacs as an example. From your "store and share commands" point of view so called TUIs (like emacs in terminal) are as opaque as GUIs (emacs in X11).


Note that nothing stops a GUI program from also supporting programmability and scripting. While it's true that most of them don't, you'll also find that a surprising number do.

For example, the entire MS Office Suite is programmable - you can write VB Script (or lately, JS?) and achieve most if not all of the functionality supported in the GUI.

Rather more well known on this front, Emacs and many other Lisp systems have always supported the same kind of programmability as a shell from within the GUI environment - both in the form of a simple REPL and more advanced GUI-command interaction (e.g. executing the current selection as elisp code, executing a command with the current selection as input etc).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: