Prev: micro solution backpack cd-writer hell
Next: "...error while loading shared libraries: libg2c.so.0"
From: Shane on 17 Nov 2005 23:00 On Fri, 18 Nov 2005 03:52:15 +0000, Bradley K. Sherman wrote: > > When Google buys Microsoft, the command line will have triumphed > over the thin, thin candy shell of the GUI. > > --bks er.. wouldnt that be the webpage interface has triumphed? -- Hardware, n.: The parts of a computer system that can be kicked The best way to get the right answer on usenet is to post the wrong one.
From: Bradley K. Sherman on 17 Nov 2005 23:04 In article <pan.2005.11.18.04.00.06.121100(a)weasel.is-a-geek.net>, Shane <shane(a)weasel.is-a-geek.net> wrote: >On Fri, 18 Nov 2005 03:52:15 +0000, Bradley K. Sherman wrote: > >> >> When Google buys Microsoft, the command line will have triumphed >> over the thin, thin candy shell of the GUI. > >er.. wouldnt that be the webpage interface has triumphed? Have a little bit longer look at the Google home page. That'a a command line if I ever saw one. Sort of like that thing at the bottom of the page when I hit ':' in vi. Or perhaps the ed session when I am on a dumb terminal being used as a console to a ?nix box. --bks
From: Shane on 17 Nov 2005 23:22 On Fri, 18 Nov 2005 04:04:10 +0000, Bradley K. Sherman wrote: > In article <pan.2005.11.18.04.00.06.121100(a)weasel.is-a-geek.net>, > Shane <shane(a)weasel.is-a-geek.net> wrote: >>On Fri, 18 Nov 2005 03:52:15 +0000, Bradley K. Sherman wrote: >> >>> >>> When Google buys Microsoft, the command line will have triumphed >>> over the thin, thin candy shell of the GUI. >> >>er.. wouldnt that be the webpage interface has triumphed? > > Have a little bit longer look at the Google home page. > > That'a a command line if I ever saw one. Sort of like that > thing at the bottom of the page when I hit ':' in vi. Or > perhaps the ed session when I am on a dumb terminal being > used as a console to a ?nix box. > > --bks er.. Have a look at _any_ app the buttons usually correspond to cli commands/arguments the webpage (in this example) is providing an easy to use interface to googles cli's IOW, just like a gui app does even drag and drop is just a fancy way of saying mv -- Hardware, n.: The parts of a computer system that can be kicked The best way to get the right answer on usenet is to post the wrong one.
From: Bradley K. Sherman on 17 Nov 2005 23:33 In article <pan.2005.11.18.04.22.21.625386(a)weasel.is-a-geek.net>, Shane <shane(a)weasel.is-a-geek.net> wrote: >On Fri, 18 Nov 2005 04:04:10 +0000, Bradley K. Sherman wrote: > >> In article <pan.2005.11.18.04.00.06.121100(a)weasel.is-a-geek.net>, >> Shane <shane(a)weasel.is-a-geek.net> wrote: >>>On Fri, 18 Nov 2005 03:52:15 +0000, Bradley K. Sherman wrote: >>> >>>> When Google buys Microsoft, the command line will have triumphed >>>> over the thin, thin candy shell of the GUI. >>> >>>er.. wouldnt that be the webpage interface has triumphed? >> >> Have a little bit longer look at the Google home page. >> >> That'a a command line if I ever saw one. Sort of like that >> thing at the bottom of the page when I hit ':' in vi. Or >> perhaps the ed session when I am on a dumb terminal being >> used as a console to a ?nix box. > >er.. >Have a look at _any_ app >the buttons usually correspond to cli commands/arguments >the webpage (in this example) is providing an easy to use interface to >googles cli's >IOW, just like a gui app does >even drag and drop is just a fancy way of saying mv > Have you ever used Google? --bks
From: Reinder Verlinde on 18 Nov 2005 06:09
In article <m3iruq3cm7.fsf(a)mobile.int.cbbrowne.com>, Christopher Browne <cbbrowne(a)acm.org> wrote: > A fundamental difference between shell and GUI is that the GUI tends > to restrict your choices to the vanishingly few options that the > programmer specifically programmed into it, whereas the shell is > inherently more open-ended. Isn't that more a matter of "shells tend to be designed for programmers, and GUIs for 'normal' people"? I would say that some (all?) of the fundamental differences between shell and gui are: - a shell requires one to memorize available options, whereas a GUI allows you to easily discover them (building a GUI that allows one to discover myriads of available options is hard) - a shell is command-centered; GUIs are data-centered. - GUIs use direct manipulation I think that one could design a GUI for programmers, for example by providing a way to build a data flow from building blocks (a bit like Apple's Automator, but more powerful). I doubt one could design a shell for non-programmers that suited them better than a GUI. > Well, 'find' is probably not the most "user-friendly" program ever > created. I use it, surprisingly often; some coworkers, who are > otherwise very knowledgeable, emit blank stares when they encounter > it. It would be nice if something better had been created; alas, I > haven't seen better alternatives forthcoming... I assume that this is to do with the Unix 'find' command. This shows another difference between GUIs and shells: GUIs tend to improve over time 'all over the board'; shells and shell commands in some areas can not. Some improvements I know of in shells are: - line editing - history buffer - command completion (still in its infancy because it does not know the syntax of commands) - Apple's commando interface that allowed one to pop up a GUI-dialog with which one could both see and set all options for a command - Microsoft's upcoming shell that gets rid of text as the I/O format. However, there is a fundamental corner where shells tend to get frozen because of backward compatibility concerns, and probably also because programmer-types do not want to give up the advantage they gained by memorizing arcane options for the benefit of newcomers (examples from Unix shell commands: why do we have 'tail -c 10' to read the last 10 characters of a file, but not 'head -c 10' to read the first 10? Why is 'recursive' sometimes -r, and sometimes -R?) So, if a shell's programming interface is not properly designed from the start, it may be doomed. Reinder |