4 ms·

Sledgehammer is an allegory for cognitive burden of checking and rechecking the code you write in a command line. *nix CLI for example is not an ideal of unifor

Sledgehammer is an allegory for cognitive burden of checking and rechecking the code you write in a command line. *nix CLI for example is not an ideal of uniformity ([0]) and simplicity. It's not at the same level of simplicity as your common household knife, at least. [0]: `--opt=val`, `--opt val`, `-opt=val`, `opt=val`. First two are usually interchangeable but sometimes not. Third one was completely unexpected for me (clang uses a mix of first, second and third). Forth one is easy, only `dd` uses it.

jolmg 7y ago
> Sledgehammer is an allegory for cognitive burden of checking and rechecking the code you write in a command line. The way you write that makes it sound like you're taking several seconds to read and re-read commands you've written tens of thousands of times before. It doesn't have to be like that. Not every command is risky, and checking for mistakes takes an instant. If you're paying attention to what you're typing, you can know what you've written is correct even if you're not looking at the computer or keyboard. It's just about practice. The more you use the command line, the less mistakes you make. Also, I find that use of GUI also carries significant cognitive burden, because there's is more room for human error, and I can't always rewind what I've done to recheck. With the CLI, I can scroll up or check my history to see exactly what I asked the computer to do, but when using a GUI, things are more manual, and there's no always-available equivalent to scrolling on the terminal or checking history, as if I had a Tivo on my desktop. For example, using sqlite on CSVs versus working those CSVs on a spreadsheet program. Let's say I want to remove rows where a certain column is a certain value. In sqlite, I would just translate that last sentence to SQL and tell it to sqlite, leaving it in history and my terminal window like a chat conversation between me and my computer. In a spreadsheet, I think the natural thing to do would be to sort by the column, select the range of fields I see that have the mentioned value in the mentioned column, and delete them. Let's say I save, turn off the computer and leave. Then the next day, I would wonder if I could have possibly moved the mouse a little more than I should have, selecting one more row than I should have and deleted something I shouldn't have. Spreadsheets have undo/redo (by per-app convention only), but it probably doesn't save that undo history across reboots. So that information is lost. I'd have to compare the CSV I saved with the original. In a CLI, I would just look at the history of what I did yesterday and read (in SQL) "remove rows where a certain column is a certain value", and with that I can be sure that that mistake would have been impossible. In other words, with CLI, I just need to make sure I'm translating what I want to code appropriately, and I'm free from the burden of caring about the possibilities for human errors, like those possible when working manually with data in a GUI. > nix CLI for example is not an ideal of uniformity [...] `--opt=val`, `--opt val`, `-opt=val`, `opt=val`. That's very rarely a problem. I don't forget the syntax of tools I'm using day by day. It could only happen on new tools or ones that I haven't used in a very, very long time. If I really am not sure of something like the syntax of options, I'll just give a quick check in the manual. Takes less than 5 seconds. Also, I think GUIs are even less uniform. For example, it used to be that by convention, every GUI program had a menu-bar at the top, but for Firefox and Chromium now, probably the most used GUI programs worldwide right now, the menu-bar is basically non-existent. We now get a hamburger button or a vertical ellipsis button to our right. The interface is very non-standard. The guys who built Blender, the 3d modeling program, were also very creative in how they designed the GUI, with their splitable tiling subwindows. I don't know of any other interface like it. Gimp is also very unique in having different windows for differing things in the same running instance of the program. MS Office introduced the ribbon interface to replace the toolbars it had before. Honestly, in comparison, I think CLIs are very uniform. The interface is much more restrictive, and doesn't allow for as much creativity. > simplicity. It's not at the same level of simplicity as your common household knife, at least. I think you're confusing simplicity with ease of use. CLI is simple like a knife and GUIs are easy to use like a tomato slicer. A knife is not easier than a tomato slicer, and a tomato slicer is not simpler than a knife. Why is a CLI simpler than a GUI: Because for any one task, a GUI program's code will be mostly about the management of the GUI and have little to do with the task it's supposed to do, while a CLI program's code will be mostly about the task itself. The reason for that is that a CLI is super super simple. You take a list of string arguments, maybe read from stdin, maybe write to stdout or stderr, and return a status code. That's basically it. A GUI on the other hand, needs to create windows. redraw them regularly, listen for input, decide to play an animation over widgets when some event happens like when you hover over a button with the mouse, etc. If you check what a CLI program asks of the OS while it's running (via strace for example), the requests are normally very relatable to what the program is supposed to be doing. If you did that with a GUI program, you're going to be bombarded with the amount of system calls it makes for GUI shenanigans. A second reason why a CLI is simpler is that CLI tools are composable while GUIs are not. This means that CLI tools can be made for very fine-grained functionalities. For example, you can't split a basic GUI file manager into multiple GUI programs, but can make a bunch of CLI utilities that handle the various tasks of a GUI file manager. Because they're so focused on a granular task they can solve it better. I mean, who's going get a better solution for the searching of files? A GUI file manager developer that needs to also cover many other things like file copy and move, or a CLI utility developer that is making a utility like `find` that is solely focused on finding files? CLI utilities are simpler because they're focused because they're composable. CLIs are very much like knives: simple, versatile, composable.

jolmg 7y ago

> Sledgehammer is an allegory for cognitive burden of checking and rechecking the code you write in a command line. The way you write that makes it sound like you're taking several seconds to read and re-read commands you've written tens of thousands of times before. It doesn't have to be like that. Not every command is risky, and checking for mistakes takes an instant. If you're paying attention to what you're typing, you can know what you've written is correct even if you're not looking at the computer or keyboard. It's just about practice. The more you use the command line, the less mistakes you make. Also, I find that use of GUI also carries significant cognitive burden, because there's is more room for human error, and I can't always rewind what I've done to recheck. With the CLI, I can scroll up or check my history to see exactly what I asked the computer to do, but when using a GUI, things are more manual, and there's no always-available equivalent to scrolling on the terminal or checking history, as if I had a Tivo on my desktop. For example, using sqlite on CSVs versus working those CSVs on a spreadsheet program. Let's say I want to remove rows where a certain column is a certain value. In sqlite, I would just translate that last sentence to SQL and tell it to sqlite, leaving it in history and my terminal window like a chat conversation between me and my computer. In a spreadsheet, I think the natural thing to do would be to sort by the column, select the range of fields I see that have the mentioned value in the mentioned column, and delete them. Let's say I save, turn off the computer and leave. Then the next day, I would wonder if I could have possibly moved the mouse a little more than I should have, selecting one more row than I should have and deleted something I shouldn't have. Spreadsheets have undo/redo (by per-app convention only), but it probably doesn't save that undo history across reboots. So that information is lost. I'd have to compare the CSV I saved with the original. In a CLI, I would just look at the history of what I did yesterday and read (in SQL) "remove rows where a certain column is a certain value", and with that I can be sure that that mistake would have been impossible. In other words, with CLI, I just need to make sure I'm translating what I want to code appropriately, and I'm free from the burden of caring about the possibilities for human errors, like those possible when working manually with data in a GUI. > nix CLI for example is not an ideal of uniformity [...] `--opt=val`, `--opt val`, `-opt=val`, `opt=val`. That's very rarely a problem. I don't forget the syntax of tools I'm using day by day. It could only happen on new tools or ones that I haven't used in a very, very long time. If I really am not sure of something like the syntax of options, I'll just give a quick check in the manual. Takes less than 5 seconds. Also, I think GUIs are even less uniform. For example, it used to be that by convention, every GUI program had a menu-bar at the top, but for Firefox and Chromium now, probably the most used GUI programs worldwide right now, the menu-bar is basically non-existent. We now get a hamburger button or a vertical ellipsis button to our right. The interface is very non-standard. The guys who built Blender, the 3d modeling program, were also very creative in how they designed the GUI, with their splitable tiling subwindows. I don't know of any other interface like it. Gimp is also very unique in having different windows for differing things in the same running instance of the program. MS Office introduced the ribbon interface to replace the toolbars it had before. Honestly, in comparison, I think CLIs are very uniform. The interface is much more restrictive, and doesn't allow for as much creativity. > simplicity. It's not at the same level of simplicity as your common household knife, at least. I think you're confusing simplicity with ease of use. CLI is simple like a knife and GUIs are easy to use like a tomato slicer. A knife is not easier than a tomato slicer, and a tomato slicer is not simpler than a knife. Why is a CLI simpler than a GUI: Because for any one task, a GUI program's code will be mostly about the management of the GUI and have little to do with the task it's supposed to do, while a CLI program's code will be mostly about the task itself. The reason for that is that a CLI is super super simple. You take a list of string arguments, maybe read from stdin, maybe write to stdout or stderr, and return a status code. That's basically it. A GUI on the other hand, needs to create windows. redraw them regularly, listen for input, decide to play an animation over widgets when some event happens like when you hover over a button with the mouse, etc. If you check what a CLI program asks of the OS while it's running (via strace for example), the requests are normally very relatable to what the program is supposed to be doing. If you did that with a GUI program, you're going to be bombarded with the amount of system calls it makes for GUI shenanigans. A second reason why a CLI is simpler is that CLI tools are composable while GUIs are not. This means that CLI tools can be made for very fine-grained functionalities. For example, you can't split a basic GUI file manager into multiple GUI programs, but can make a bunch of CLI utilities that handle the various tasks of a GUI file manager. Because they're so focused on a granular task they can solve it better. I mean, who's going get a better solution for the searching of files? A GUI file manager developer that needs to also cover many other things like file copy and move, or a CLI utility developer that is making a utility like `find` that is solely focused on finding files? CLI utilities are simpler because they're focused because they're composable. CLIs are very much like knives: simple, versatile, composable.