4 ms·

I disagree. True, command lines are another shadow on the cave wall, but they're a sharper shadow: they show more of what's actually happening, and they give yo

I disagree. True, command lines are another shadow on the cave wall, but they're a sharper shadow: they show more of what's actually happening, and they give you tools to get more information about, as Stephenson would put it, "the tangled nam-shubs beneath." This is arguably not inherent to the command line, but it's definitely inerent to how GUIs work: GUIs cannot compose, are harder to script, and cannot show the kind of info CLIs can, if they wish to remain accessible (there's a reason there's no graphical method to get the inode number of a file). I think Stephenson expressed this quite well.

pwdisswordfish 10y ago
Nothing stops you from putting the inode number in a copyable field in a "file properties" window. Now, of course there is basically nothing you can do with an inode number in a graphical environment, but then there is also very little you can do with it in a command line as well. Omitting this detail is not something "inerent" to graphical interfaces.
- qwertyuiop924 10y ago
  Fair enough: for that particular detail. The point is, when UX matters, you cannot add mode switch (like command line flags), and you can't give the user all the data: their eyes would pop out. The GUI is a higher level abstraction: lack of control is the tradeoff.
  - rer 10y ago
    What if the data where there but not in front of their eyes. I want there to be data there.
rer 10y ago
How would you do GUIs to make them compose, script, and show the kind of info CLIs can?
- qwertyuiop924 10y ago
  They can't: that's the price you pay for the abstraction. Smalltalk got the closest, but if you really want to dig into a GUI, at the end of the day, you have to read the code behind it.
  - rer 10y ago
    Maybe I should read the code behind Smalltalk. I'm glad the day isn't over.
  - colejohnson66 10y ago
    You mean AppleScript?
    - qwertyuiop924 10y ago
      No, AS didn't do nearly as good a job as ST did.
- Fr0styMatt88 10y ago
  I'd point to the work done on tangible UIs and programming environments for that. For example, the work on tangible UIs eg- Self: http://www.selflanguage.org/ http://www.selflanguage.org/ This is a good demo of what could be done in the Self environment: https://www.youtube.com/watch?v=Ox5P7QyL774 https://www.youtube.com/watch?v=Ox5P7QyL774 GUI and non-programmability are tangential things. I don't think they're implicitly bound together.
  - qwertyuiop924 10y ago
    However, GUIs are implicitly more complex than text steams. Sure, they can be programmable, and conposable, but it's an uphill battle, and CLI just does it so effortlessly.
    - fzzzy 10y ago
      The CLI only does so effortlessly because of all the work done to make it effortless. Pipes, string formatting, argument parsing. If the same amount of work was put into a direct manipulation GUI as was put into unix, it would be just as effortless, if not more. Why are terminals still based on the concept of a teletype? It is fully one dimensional. You have to fit all interactions through that one dimension. (Multiple terminal windows are a kind of hyperspace, I suppose.)

pwdisswordfish 10y ago

Nothing stops you from putting the inode number in a copyable field in a "file properties" window. Now, of course there is basically nothing you can do with an inode number in a graphical environment, but then there is also very little you can do with it in a command line as well. Omitting this detail is not something "inerent" to graphical interfaces.

qwertyuiop924 10y ago
Fair enough: for that particular detail. The point is, when UX matters, you cannot add mode switch (like command line flags), and you can't give the user all the data: their eyes would pop out. The GUI is a higher level abstraction: lack of control is the tradeoff.
- rer 10y ago
  What if the data where there but not in front of their eyes. I want there to be data there.

rer 10y ago

How would you do GUIs to make them compose, script, and show the kind of info CLIs can?

qwertyuiop924 10y ago
They can't: that's the price you pay for the abstraction. Smalltalk got the closest, but if you really want to dig into a GUI, at the end of the day, you have to read the code behind it.
- rer 10y ago
  Maybe I should read the code behind Smalltalk. I'm glad the day isn't over.
- colejohnson66 10y ago
  You mean AppleScript?
  - qwertyuiop924 10y ago
    No, AS didn't do nearly as good a job as ST did.
Fr0styMatt88 10y ago
I'd point to the work done on tangible UIs and programming environments for that. For example, the work on tangible UIs eg- Self: http://www.selflanguage.org/ http://www.selflanguage.org/ This is a good demo of what could be done in the Self environment: https://www.youtube.com/watch?v=Ox5P7QyL774 https://www.youtube.com/watch?v=Ox5P7QyL774 GUI and non-programmability are tangential things. I don't think they're implicitly bound together.
- qwertyuiop924 10y ago
  However, GUIs are implicitly more complex than text steams. Sure, they can be programmable, and conposable, but it's an uphill battle, and CLI just does it so effortlessly.
  - fzzzy 10y ago
    The CLI only does so effortlessly because of all the work done to make it effortless. Pipes, string formatting, argument parsing. If the same amount of work was put into a direct manipulation GUI as was put into unix, it would be just as effortless, if not more. Why are terminals still based on the concept of a teletype? It is fully one dimensional. You have to fit all interactions through that one dimension. (Multiple terminal windows are a kind of hyperspace, I suppose.)