Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

The battle of the experts and the newbies

By 42 in Op-Ed
Sat Jul 07, 2001 at 01:34:11 PM EST
Tags: Technology (all tags)

Every now and then, like all major flamewar topics, the question of how newbie-friendly a free operating system should be gets reseurrected. On the one hand, we have folks claiming that GUIs and polish are either inessential / deficient / contrary to the culture and philosophy of the operating system in question, etc. On the other hand, you have folks that point out that the Microsoft operating systems are very newbie friendly, that the other camp is blind to the enormous strides being made on that platform simply because the focus of improvements is on the end user. Can't we all just get along?

Author's note: I've seen this flamewar numerous times. In fact, if this article were posted on Slashdot, probably the mother of all flamewars would erupt. By posting this here, I hope that a useful discussion will happen.

Perhaps the most eloquent defense that I have read of the whole command line vs the GUI argument was written by Neal Stephenson. His arguments for the primacy of the command line are well reasoned. In it , Mr. Stephenson forcefully makes the point that when push comes to shove, a GUI's capabilities will be limited by the visions of its designers, whereas the power of the command line is without limits.

I do not wish to refute his argument. I don't think I can. However....

Time and again, I have heard arguments on why a certain feature / capability of Linux or Unix should not be made more user-friendly. It could be something as simple as boot messages, or something as complex as "is what GNOME / KDE provides essential?" The argument seems to take the thread of: there are alternative ways of achieving the objective and (a) these alternatives are the time-honoured way of doing things or (b) these alternatives are the in line with the culture and philosophy of Unix / Linux.

Yes, a GUI may not be as capable as a command line. But if it makes someone's life easier, why should you stand in the way?

And its not just GUIs: time and time again, people in the know -- people who may have put in a lot of effort to reach their level of expertise -- argue against lowering the entry barrier1 for newbies. One should respect the achievements of the experts. But the experts should also try to ensure that their art progresses to mere technology2.

Now, before you get out your flamethrowers, let me clarify that I am not saying that experts do not help out newbies. This is plainly not true -- the numerous FAQs and mailing lists, and helpful websites that exist out there will attest to that. What I am saying is that by their attitudes, the experts are helping out newbies in the wrong way. Instead of reducing the height of the mountain, they are insisting on teaching newbies to climb Mt. Everest -- simply because they think that climbing Mt. Everest is the Right Thing To Do TM.

1 Mr. Ts'o is arguing for lowering the entry barrier -- not on the other side, as the placement of the link may seem to imply.

2 This is a reference to Arthur C. Clarke's statement (I paraphrase): "Any sufficiently advanced technology is indistinguishable from magic."


Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure


Related Links
o Slashdot
o Slashdot [2]
o well reasoned
o boot messages
o entry barrier
o Also by 42

Display: Sort:
The battle of the experts and the newbies | 81 comments (77 topical, 4 editorial, 0 hidden)
The problem with user-friendliness... (4.33 / 3) (#1)
by pongo on Sat Jul 07, 2001 at 02:03:00 AM EST

...as manifested by Microsoft is that they use GUI interfaces as a means to an end: By simplifying the administration of their systems to a few sets of GUI dialogs, Microsoft believes they are doing the world a service. In fact, their belief is so strong that they simply provide no other alternative to system administration other than through the GUIs provided.

I could make the same argument for, say, linuxconf, which also attempts to be the end-all solution to system administration. But there is a major difference here: Whereas it's often difficult, if not downright impossible, to bypass a Microsoft dialog to configure something manually, I know of no instance where linuxconf provides functionality which cannot be duplicated by the appropriate command-line commands.

I teach Unix sys admin courses at a local community college. Without fail, I will get at least one student per semester challenging me as to why I refuse to teach sys admin techniques using linuxconf, XF86Setup, etc. I give them the normal stock answer: You might not always have X available, vendor Y might not support the same GUI interface, blah blah blah.

But I've never told them the real reason why I teach sys admin using the command line:

Because I can.

hardly. (4.00 / 4) (#5)
by rebelcool on Sat Jul 07, 2001 at 02:44:06 AM EST

I disagree. Whilest it may not be CONVIENENT to change a program's settings in windows, its far from impossible (unless the program is using its own customary form of storing them). Personally I always stored settings in .INI files (which, as you might not know, are just like any CONF or PROPERTIES file you'll find on a unix system). The windows API has very fast builtin functions for manipulating ini files. Some people use the registry (particularly if you're doing alot of mixing of programs), which is harder to edit, but certainly possible.

The only way I can see a program's options not being edittable would be if they were using their own form of storage, which is kind of like reinventing the wheel.

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

Windows is opaque and poorly-documented (5.00 / 2) (#13)
by sigwinch on Sat Jul 07, 2001 at 05:14:31 AM EST

Whilest it may not be CONVIENENT to change a program's settings in windows, its far from impossible (unless the program is using its own customary form of storing them).
Here's a sample configuration problem: suppose you routinely use your laptop on several networks and use DHCP. For most of the networks, DHCP tells you to use good, fast name servers for DNS resolution. However, one of the networks specifies an ISP's name server that is slow and unreliable. The solution is to detect when the bad name server is suggested, and do lookups directly in that case; otherwise use the suggested servers.

Automating this solution under Windows would be very hard, since the mechanisms are opaque binaries with poorly-documented interfaces and semantics, the data structures are not meant to be easily modified by third-party tools, and there are few hooks to trigger custom behavior (so the triggers tend to be gruesome kluges). Any solution will likely be highly specific to particular versions and service pack levels of Windows. Moreover, any solution will be fragile and tend to break as the system administration tools are used.

Contrast this with a good Unix-like OS, which will use a collection of scripts to manage the networking. Under Red Hat Linux the relevant script is /sbin/ifup. Adding two lines to that file will solve the immediate problem: 1) Search /etc/resolv.conf for the offending server address using the grep program. 2) If the address is found, execute echo "nameserver" > /etc/resolv.conf.

With slightly more generality (say, a dozen lines of script), and a little documentation, this solution can be packaged up so that even novices can patch their system to have the feature. Under Red Hat, it gets even better: the GUI is itself a Python script (/usr/lib/rhs/netcfg/netcfg.py), so it's pretty straightforward to extend the GUI so that even novices can manage the new DNS blacklisting feature without getting their hands dirty.

When people talk about "the Unix way" with fondness, this sort of thing is what they're talking about. Simplicity, transparency, and adaptability.

Naturally most novices will never, ever make these upgrades themselves. The point of scripting is not that everybody and their chinchillas will go out and rewrite the system scripts. The point is that novices eventually bump up against the limitations of the pre-packaged GUI system, and the local guru needs to be able to help them. Under Windows, the limitations of the GUI are a brick wall that even the guru often cannot overcome in a cost-effective manner. Under a Unix-like OS, the local guru can often come up with a quick fix that makes your life easier.

I don't want the world, I just want your half.
[ Parent ]

Hell, if it's that much hassle, may as well... (3.66 / 3) (#24)
by marlowe on Sat Jul 07, 2001 at 11:22:22 AM EST

do it by a command line.

-- The Americans are the Jews of the 21st century. Only we won't go as quietly to the gas chambers. --
[ Parent ]
Ignoring for a moment every command below c:\winnt (4.33 / 3) (#6)
by psctsh on Sat Jul 07, 2001 at 03:00:32 AM EST

I'd be willing to learn from you. I don't know much about unix administration, and I myself learned what I know about IIS through the IMSAdminBase COM object, MetaEdit, and the IIS mmc snapin (this was required for my job). I've found no limitations in what I can do with a little digging. I've yet to have a problem bypassing the dialogs (whether they be for the NT users, dns, dsn, sql server administration), and when there doesn't exist a command line utility, you can write a .vbs script in about two seconds which will do what you need it to do (Microsoft's a regular Santa Claus when it comes to adding com objects for vb). When that doesn't work? Write something using VC and one of the API's that Microsoft always provides.

So seriously--I'm completely ignorant on the subject of unix administration, and want to know: What's often difficult or impossible to do in windows?

[ Parent ]
Relative difficulty (5.00 / 2) (#16)
by sigwinch on Sat Jul 07, 2001 at 06:44:05 AM EST

I've found no limitations in what I can do [regarding automated Windows administration] with a little digging.
It's not that anything is impossible under Windows, it's that things are needlessly difficult.
...and when there doesn't exist a command line utility, you can write a .vbs script in about two seconds which will do what you need it to do (Microsoft's a regular Santa Claus when it comes to adding com objects for vb).
Hmmm...I wasn't aware of that. If it is actually done properly then Windows isn't as bad as I thought it was.
Write something using VC and one of the API's that Microsoft always provides.
If you have to switch languages to get at an API, the system design is probably flawed. Especially if the language is C -- writing, debugging, qualifying, and releasing a C program takes significant time and effort. (Esp. if you have to pay hundreds of dollars for the compiler package.)
So seriously--I'm completely ignorant on the subject of unix administration, and want to know: What's often difficult or impossible to do in windows?
Well, there are good Unixes and bad Unixes. Some of them (HP-UX, if I remember right) use binary configuration files and compiled C programs all over the place, which I think is a Bad Thing. Others, like Red Hat Linux, use text configuration files and scripts for almost everything, which I think is a Good Thing.

Here's what I think the benefits of a "good" Unix are:

  • You can inspect the system and see the overall logic that makes it work. You don't have to worry that something will activate behind your back and break the changes you just made. You don't have to make assumptions about some minor feature that the vendor forgot to document. Everything is right there in front of you.
  • IMHO, scripts are *far* easier to develop than C programs. You can build up complicated things one step at a time, making sure they work correctly at every step. I haven't used them, but I expect that .vbs scripts have this advantage too.
  • Because it's all just files, you can develop much of the code as an unprivileged user. Only when it seems to build correct configurations do you have to risk a live system.
  • Because it's all just files, you can easily recover from blowing things up. Just save copies of everything before you start and restore them when everything melts down.
  • Because the whole system is exposed, you can add entirely new concepts to it. (See my DNS server blacklist example elsewhere in these comments.) Want to update the load balancing round robin DNS server from email messages received by a certain account, checking for new messages every five minutes on weekdays and every 30 minutes on weekends? No problem. I don't know why you would want to do that, but it's easy to do. (By easy, I'm talking about less than 10 lines of script and a couple of crontab entries.)
  • Since the administration tools are often scripts themselves, it's pretty easy to add new concepts to the GUIs. Not only is it easy to add entirely new classes of features, you can extend it all the way to the GUI, so that novices can manage the new features.
  • The diff and patch programs let you easily package up all the changes you make, and the changes can later be easily applied to other systems (or the same system after a reinstall). You can trivially distribute the changes throughout an organization, or even to the general public.
  • Because it's all just files, you can easily put them under a version control system. People routinely put the entire /etc hierarchy under CVS control. If a problem occurs, it's trivial to roll back the changes. (Can you imagine trying to check the Windows registry into Source Safe?)
  • Text configuration files are flexible. I use Red Hat Linux, and I have my choice of RH's mishmash of different administration tools, linuxconf, or Webmin. (Webmin runs as a web server and lets you configure your system from a web browser. I mostly use it these days.)
  • Backups, restores, and upgrades tend to be easier: just copy your old files over. I just upgraded from Red Hat 6.2 to 7.1, which is a fairly major upgrade. Naturally, I kept my same home directory over the upgrade, so my GUI customizations were totally unaffected. Ditto for the custom crypto scripts I wrote for the mail reader. Not counting the file copying time, I spent probably 15 minutes and got a seamless upgrade. Talk about a major time saver compared to the standard Windows approach of manually setting everything up again.

I can only think of about two major drawbacks to the text files and scripts approach. First, you have to be able to navigate big, complex piles of source code, and you have to be able to suck useful information out of man pages.

Second, a lot of the scripts tend to 'shell' scripts, which are usually ugly as programming languages. Red Hat, for example, makes extensive use of bash scripts. (I consider bash particulary repulsive.) If I could wave a magic wand, I'd change all the scripts into Python. Or Perl. Hell, I'd rather use Visual Basic scripts instead of bash.

I don't want the world, I just want your half.
[ Parent ]

Network config (4.00 / 1) (#27)
by IntlHarvester on Sat Jul 07, 2001 at 12:22:01 PM EST

One thing that's stumped me on Windows is that there's apparently no scripting or commandline interface into the network configuration. No ifconfig, ipconfig is pretty much read only, and there's no COM interfaces to be seen.

On Win2000 the network connections folder is apparently integrated into explorer.exe, which means that you can't even use Run As to change things if you aren't logged in as an administrator.

[ Parent ]
Might want to recheck ipconfig... (4.00 / 1) (#31)
by psctsh on Sat Jul 07, 2001 at 02:24:34 PM EST

I honestly don't know what to tell you, mainly 'cause I don't know what it is you want to do (I also don't know what ifconfig does...). The network connections folder has some pretty varied functionality built into it--are you trying to add new connections, configure existing ones, configure what services run through a specific adapter, configure the adapter itself...?

The easiest suggestion I can make is to tell you to spend a half-hour searching msdn.microsoft.com for what you're trying to do--and I've found that it helps to get very specific (and when you find something of questionable relevance, click on it and search the nearby folders/keywords). Another suggestion is to just go to winnt\system32 and spend some time searching through the *.exe's located there (many of them are in fact 20+ commands in one--the most obvious being net.exe for NT management). Also, there are many administration tools found on the MSDN site (usually linked through the knowledge base articles, not the download center) that aren't immediately available straight from the w2k cd.

Sorry, I realize how vague that sounds, but since I really don't know what it is you're trying to do...perhaps a little clarification (and I'll see if I know what you need)?

[ Parent ]
Network Connections (3.00 / 1) (#45)
by IntlHarvester on Sat Jul 07, 2001 at 08:48:22 PM EST

On one level I want a scripting interface to anything that can be done with the network connections GUI.

On another level, I just want to f*ing change the f*ing IP address from a batch file. (Well, you asked for an example, and it looks like you got it.)

And, I've been using NT fulltime since 1994, been all over microsoft.com, and IPCONFIG is still IPCONFIG.

[ Parent ]
sorry (5.00 / 1) (#47)
by psctsh on Sat Jul 07, 2001 at 09:48:09 PM EST

the only ip changing that I know how to do (off the top of my head) involves IIS virtual servers--adding and removing ip/port combinations is as easy as changing the metabase key "lm\w3svc\[svridnumber]\ServerBindings" to hold the correct values (try adding in some random ones through mmc to get the syntax). The COM object to access the metabase is IMSAdminBase, and it should be available through the visual basic scripting thingie--I've never tried it using anything other than C though, so your results may vary.

But this doesn't really sound like what you want to do. You sound more like you want to assign which ip is related to which network card? Try this. It doesn't tell you how to get the files to load, but apparently it is possible to load it in via a file--just have your batch file modify the appropriate entries. Also, maybe this will help shed some light on it as well...good luck.

[ Parent ]
Only during installation (4.00 / 2) (#48)
by IntlHarvester on Sat Jul 07, 2001 at 10:11:13 PM EST

Links relate to unattended setup only. Thanks anyway.

[ Parent ]
netsh (none / 0) (#63)
by Tsuraan on Sun Jul 08, 2001 at 06:47:01 PM EST

try the following:
netsh interface ip set address "Local Area Connection" static xxx.xxx.xxx.xxx yyy.yyy.yyy.yyy zzz.zzz.zzz.zzz 1
netsh interface ip set dns "Local Area Connection" static ddd.ddd.ddd.ddd
netsh interface ip set wins "Local Area Connection" static none

where xxx... is your ip address, yyy... is the netmask, zzz... is the gateway, and ddd... is the dns server. Or, if you use dhcp, do the following:
netsh interface ip set address "Local Area Connection" dhcp
netsh interface ip set dns "Local Area Connection" dhcp
netsh interface ip set wins "Local Area Connection" static none

This works fine with windows 2000, and it should work with other OS's too, as far as I know.

[ Parent ]

Woo! (none / 0) (#77)
by IntlHarvester on Tue Jul 10, 2001 at 05:35:52 PM EST

I guess there's still some tricks for me to learn about Windows. Incredible thanks for the tip!

[ Parent ]
Fundamentally different philosophy (5.00 / 2) (#42)
by swr on Sat Jul 07, 2001 at 07:23:40 PM EST

when there doesn't exist a command line utility, you can write a .vbs script in about two seconds which will do what you need it to do (Microsoft's a regular Santa Claus when it comes to adding com objects for vb). When that doesn't work? Write something using VC and one of the API's that Microsoft always provides.

Does Windows come with all of that documentation installed? Is VC included with Windows?

Sure there are lots of tools available for Windows, but in nearly all cases you have to go out of your way (and out of your pocket!) in order to get the sort of flexibility that comes with a basic *nix install.

Windows: VBS, .bat
*nix: sh, perl, expect. Also tcl, python on some systems.

Documentation for scripting languages:
Windows: Minimal included for .bat, and I haven't yet found any found any included for VBS.
*nix: Included with system, very complete.

Documentation for command-line tools:
Windows: Minimal included with system.
*nix: Included with system, very complete.

C/C++ compiler:
Windows: Sold seperately.
*nix: Included with system.

API documentation:
Windows: Not included with system.
*nix: Included with system, very complete.

When I say "very complete" above, I mean it is possible to completely re-implement the system with the provided documentation. That can be, and has been, done with *nix. The Wine folks have had great difficulty doing that with Windows. I'm not suggesting that many people are wanting to reinvent their OS - what I'm suggesting is that the documentation that comes included with *nix is much more complete than any you will ever find anywhere for Windows.

What we see here is a fundamental difference in philosophy. With Windows, you can access the internals of the system, but in doing so you are going against the grain of the system. With *nix, the internals are fully documented and always at your fingertips.

Windows is on the most desktops because it hides it's internals. If you're the sort of person who wants access to the internals, you might be happier with a system that more closely matches the *nix philosophy.

[ Parent ]
God I need to take a shower (3.33 / 3) (#50)
by psctsh on Sat Jul 07, 2001 at 10:39:45 PM EST

Why is it I'm in the unfortunate position of defending Microsoft? I never meant to give the impression that Windows is some kind of gift from God where even the most ignorant of users is given full control through scripting and the waving of a hand.

I never said that Microsoft sent out documentation with every Windows installation. I never said that Microsoft distributed Visual C with every copy of Windows. I never mentioned anything about Windows being better than *nix in any way shape or form. I don't need a point by point bulleted breakdown of why Windows is a weaker operating system than *nix.

In terms of the "documentation issue," when was it ever brought up that the documentation was immediately at your fingertips in an understandable, complete format? I could have sworn I mentioned that you did need to dig through the documentation to find relevant information. The reason you didn't find much documentation on batch files is because Microsoft got rid of most of it back in the eighties. Is it that hard to understand the concept of how they work?

The reason you didn't find any documentation on vbs scripting is 'cause Microsoft keeps all of their developer api's and documentation on their website. There's numerous pages on vbs scripting, coupled with the fact that virtually every Active X Control and COM object is documented with a vbs example.

Oh yes, and bad Microsoft for making things difficult for the WINE people. Who'dve thought that they'd have trouble implementing a closed source system that's been in developement for around a decade and a half by huge teams of developers? Way to state the obvious.

So actually, in retrospect, how did your comment even get in the same thread as mine? Did you click the wrong "reply to" link? I'm pretty sure that the original intent of my article was to state that in most cases it's possible to script the same functionality the administrative tools give.

Does the fact that I dared mention that Windows can be scripted automatically flag me for a point by point dissertion as to what's free on *nix and what's not free on Windows? Should I be forced to explicitly state my opinion on every subject, company, and person in every one of my comments?

Let me reassert the main point from my original post:

Microsoft does not box it's users in by only giving out the GUI to perform administration. They have many command line utilities and scripting extensions to perform the exact same tasks. These utilities are not necessarily well documented, but they are documented. These utilities are not necessarily the most flexible in the world, but they do work.

Remind me to never post anything but the most violent anti-windows propoganda ever again.

[ Parent ]
Calm down, it's only ones and zeros (none / 0) (#54)
by sigwinch on Sat Jul 07, 2001 at 11:59:51 PM EST

So actually, in retrospect, how did your comment even get in the same thread as mine?
People take a topic in directions that interest them. Just because you wrote the parent comment doesn't mean you are being criticized, it just means they went off on a tangent they found interesting.

I don't want the world, I just want your half.
[ Parent ]

Yeah, honestly (4.50 / 2) (#55)
by psctsh on Sun Jul 08, 2001 at 12:33:31 AM EST

I don't really remember my rationale behind writing that comment...I was seriously pissed off about it, and took it as swr trying to shove some kind of ideology down my throat, when I'm not in entire disagreement. I don't know what came over me--it's like I snapped or something. Now I can't even see how I saw anything accusatory in swr's post...maybe I felt like I was being patronized. Another weird thing is I'm not prone to out and out flame someone--I'll usually post a condescending joke.

I honestly have no explanation or excuse as to why I flipped out like that.

[ Parent ]
Menu's make the learning curve worse (4.25 / 4) (#2)
by Weezul on Sat Jul 07, 2001 at 02:04:40 AM EST

You should think of software in terms of total learning curve (ignorant -> novice user -> scripting -> system programmer). Yes, it's possible that menu's make the ignorant -> novice transition easy, but it's likely that they make the novice -> scripting transition more difficult since they remove need for the relevent background information necissary to learn scripting.

The solution is to make the GUI more relevent to the system. Examples: The old Autocad's menu's showed you the commands they correspond to when you use them (they entered the command on the command line). Plan 9's menu's are really just blocks of text for commands, but the cut and paste is so efficent that you can use them like menus.

Anticdote: The old BBS dialer programs had no menus, but they did have help screens which told you what keys to press. You learned the key stroke commands very quickly on these systems. Eventually, more advanced dialer programms came out with menus and key stroke commands. No one ever learned the keystroke commands for these new dialers, so we were all permenently less efficent for our "upgrade."

"Fascism should more appropriately be called Corporatism because it is a merger of state and corporate power." - Benito Mussolini
Law of diminishing returns (4.87 / 8) (#3)
by John Milton on Sat Jul 07, 2001 at 02:11:23 AM EST

Most people don't really care to make the novice user -> scripting transition. Novice skills are enough to do what they want to do. So user friendly dialogue boxes are the end of the line for them. I do agree though that there should be a wide variety of options.

"When we consider that woman are treated as property, it is degrading to women that we should Treat our children as property to be disposed of as we see fit." -Elizabeth Cady Stanton

[ Parent ]
try it (4.33 / 9) (#4)
by Weezul on Sat Jul 07, 2001 at 02:26:25 AM EST

People don't care about novice -> scripting since they have not been given the chance by their software. Realize, I'm not proposing bash as the ultimate novice -> scripting transition tool. I'm saing that we should not waist effort on tools which damage novice -> scripting.

Actually, I really should just go ahead and make the stronger claim that novice -> scripting is the *most* importent transition since it has the highest returns. You should see the way most people sit and preform mindless repeditive tasks at their computer all day when they could just script it. They treat the computer like a toaster (instead of a turing equivelent) and they think their job is being a short order cook who works the toaster. Understanding, the basic principles of scripting can be very liberating to your average computer user. The user interface should provide temptation and hints at the existance and use of a basic scripting system.

I've always believed that the Chruch-Turing Thesis says something about user interface design.

"Fascism should more appropriately be called Corporatism because it is a merger of state and corporate power." - Benito Mussolini
[ Parent ]
I would disagree (4.44 / 9) (#7)
by ubernostrum on Sat Jul 07, 2001 at 03:06:49 AM EST

GUI software, with all its menus, does offer the chance. Many popular applications (I'm thinking office suites, for example) offer "scripting" in the form of macros or other such tools. Yet do people use them? Not in my experience. Why? Maybe because they're too stupid to figure out which option requires the most work in the long run and so laziness prevents them. Or maybe they don't know the option exists. Most people, it has been reliably established, would rather shell out $$$ per minute to have a tech support guy tell them how to do something if it means they don't have to read a manual or take the flashy, interactive, "Welcome to [application]" GUI introduction, or take a course on how to use the program. As a result, they never learn what options they have.

Now, drop them into the UNIX/Linux world. Help is of two kinds: the GNOME/KDE references, which get you about as far as "This is your mouse. This is an icon. Point. Click. Drag. Be free." And the man pages, which, to quote Mr. Stephenson's own argument, read

"like the terse mutterings of pilots wrestling with the controls of damaged airplanes. The general feel is of a thousand monumental but obscure struggles seen in the stop-action light of a strobe. Each programmer is dealing with his own obstacles and bugs; he is too busy fixing them, and improving the software, to explain things at great length or to maintain elaborate pretensions."
And in general, this is true. Reading a man page when you honestly don't know how to use the command in question is a lot like trying to find out why your girlfriend is mad at you - you're always left with the nagging feeling that the very fact that you had to ask such a question is indicative of your total ignorance and lack of worth as a human being. It's annoying, but at the end you know exactly what your options are.

And once it's made available as an option, the newbie to scripting transition isn't necessarily for everyone - the idea of UNIX/Linux/GNU/etc. is choice. If that means that you want to run your computer by manually flipping transistors one at a time to implement straight binary instructions, you can do that. If you want to write your own scripts to automate things, you can do that. But should you be forced to? No. It's all about choice. And if someone wants to have applications that handle tasks for them without necessitating studious command-line work or scripting (or even apps that just make it easier to automate things, so that you don't have to memorize the locations, purposes, and syntaxes of ten thousand .conf and rc files), they should be able to choose that, and there are probably plenty of programmers and companies willing to make money marketing such a thing.

Basically, you can lead a user to UNIX, but you can't make him think. Some people will see the opportunities scripting and other niceties provide, and will take advantage of them. Others will ignore those advantages, or ask for something that simplifies it - apps that simplify scripting and make it less of a "writing a program" type of task - checkboxes might figure into it somewhere. They will choose to either let someone write their scripts for them (or at least write scripts based on their instructions), or to just ignore scripting and go on as usual. And they shouldn't be forced down any particular path. UNIX is all about options, and choices, and that's how it should be.

You cooin' with my bird?
[ Parent ]

Choice (4.00 / 3) (#10)
by Weezul on Sat Jul 07, 2001 at 04:30:25 AM EST

"You can lean a user to unix but you can't make him think"

I'm not interested in *making* people think. I'm interested in increasing the probablility that they transition from a non-thinking to a thinking person. The mear presence of a scripting langague is almost irrelevent. The question is how intuitive is the transition from normal use to scripting. (I doubt unix will help much with this as the only thing intuitive about unix is the fact that we have all been using it for years)

"Fascism should more appropriately be called Corporatism because it is a merger of state and corporate power." - Benito Mussolini
[ Parent ]
Oh really? (3.00 / 1) (#12)
by ubernostrum on Sat Jul 07, 2001 at 05:04:03 AM EST

"I doubt unix will help much with this as the only thing intuitive about unix is the fact that we have all been using it for years"

I think we need a little more accessible documentation, and that people need to be made aware of what they can do with UNIX, but I think that's all that should be done - what people use an OS for is their own business. And I've been a UNIX/Linux user for about six months (that's when I started using Linux, though - I started learning to use Linux a good while before that, and tried to at least get the "basics" down before I dove into it), so I don't know what it would be like to have been "using it for years."

You cooin' with my bird?
[ Parent ]

evolution vs. design (5.00 / 3) (#30)
by Nyarlathotep on Sat Jul 07, 2001 at 02:24:27 PM EST

I would be tempted to make the following hypothosis (which likely total bullshit):

All the designed human langauges have failed (esparanto) and evolved languages are still dominant. Perhaps, we should not expect significant improvments via replacment to very fundamental things, i.e. the "nothing -> newbie" transition. Conversly, the "newbie -> scripting" transition lives more at the level of modern education, so we have a better chance of making significant improvments via replacment.

Ok, well my above argument sounds like bullshit to me. Specifically, any computer use is likely closer to educated material then spoken langauge. Still, it's an interesting though which could suggest interesting research projects.

Campus Crusade for Cthulhu -- it found me!
[ Parent ]
Game (4.57 / 7) (#51)
by Kaki Nix Sain on Sat Jul 07, 2001 at 10:40:43 PM EST

If you want more people to use scripts and such to take full advantage of the automation abilities of the machine in from of them, it is advantagious to hook them early in the process of getting used to the tool (methinks). And the younger the better. How about this, make a fun game for kids that requires small steps on the road to programming and scripting ability. That sounds like a nice positive suggestion to me.

[ Parent ]

Bumblebee! (4.00 / 1) (#62)
by fluffy grue on Sun Jul 08, 2001 at 06:20:45 PM EST

There was a really damned cool game on the C64 called Bumblebee. Its point was exactly that - you had a bumblebee which you had to control by writing a program in a very simple BASIC-like language. You had to write a program to make the bumblebee visit all the flowers in a garden and return to its hive in a limited amount of time without running into walls or being eaten by a spider or frog. Its commands were basically 'go forward', 'turn', 'wait' (to wait for the spider or frog to move somewhere else), and 'repeat' (and repeats could be nested). I had a lot of fun with that game as a kid. Then again, I've always been a geek. :)

It also had a more traditional mode for less patient kids (where you could just control the bumblebee directly), but it wasn't nearly as much fun that way.

Now I need to find it and play it under Frodo. Yay!
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

Nice. (none / 0) (#65)
by Kaki Nix Sain on Sun Jul 08, 2001 at 07:54:16 PM EST

Yeah. Now that I think about it, there are a good bit of games that use the idea of programming something ahead of time.

I was sort of thinking before that the game would use little steps to have the person progress from the direct control type interface to the scripting style. Something like, start off with a small task that can be directly done easily. Have the boards get progressively larger, while letting the player "win" the ability to automate more and more types of tasks. There wouldn't be a definite line where scripting is necessary, but it would start to look more and more inviting. Having a person embrace something freely (b/c they see the advantage) instead of forcing them to learn it (b/c someone else sees the advantage) makes a difference.

This remindes me of a failing, in the eyes of my friends and I, of the first Warcraft which was that you couldn't give the pions a script of what to harvest/mine.

[ Parent ]

RTS (none / 0) (#67)
by Weezul on Mon Jul 09, 2001 at 12:14:28 AM EST

Personally, I think RTS games can avoid "cheating" by including an internal scripting langague which forces people to share the code controlling their units. The users would improve the user interface as better and better scripts were developed. You might practice for months with one user interface only to discover you need to master the interface to the latest script.

If a good RTS game like StarCraft offered this feature then I'm shure lots of gamers would learn programming to understand and use people's scripts (and write their own).

"Fascism should more appropriately be called Corporatism because it is a merger of state and corporate power." - Benito Mussolini
[ Parent ]
Yeah. (none / 0) (#74)
by Kaki Nix Sain on Mon Jul 09, 2001 at 06:59:54 PM EST

Controling vast armadas of space ships in 3d with scripts would be fun.

Then again... "What the hell are his red fighters doing!? Shit! Why are my fighters just sitting there! AGHHH! I need to add a new condition... there. Run that, hah! Shit! Syntax error! Noooo!"

I was sort of thinking before about something aimed more towards an even younger crowd. That way they would learn a scripting language before they even understood what it was they were learning. Sort of like how we learn most things as kids. :)

[ Parent ]

Not learn keystroke commands? (4.57 / 7) (#14)
by Tachys on Sat Jul 07, 2001 at 06:22:45 AM EST


Select All=A

These are "global" keybinds in the Macintosh they work almost everywhere. They are basically tatooed into my brain from 12+ years using a Macintosh. And I learn more of them in many programs I use all the time. Because in Mac and Windows lots of menu choices have keybinds and the keybinds are shown next to the menu choice they activate.


My Dad needed to have a bunch of files imported into another application. From MacDraw to ClarisDraw I think. It was a long process of exporting and importing. But using Quickeys I managed to automate the process making it do most of the work.

In a Macaddict" it had a nifty applescript. I changed a few things in it. I could move a file on my computer for my website on to it. The script would automatically upload that file to where it needed to be on the web site.

In Adobe ImageReady I created a 'droplet'. When I dragged some image files on it it would Resize the Image to 410 pixels horizonial, scale veritcal with that, adjust the gamma level for windows machines, convert it to a gif with 16 colors no dither, and save that file. I can open the droplet and change many of these settings. I made this droplet by 'recording' what I did to the image. Then drag the resulting 'actions' from the action panel into the droplet.

If you find people having a tough time learning to script, the scripting laugauge is the problem not the GUI.

[ Parent ]
war-dialer (1.06 / 15) (#28)
by core10k on Sat Jul 07, 2001 at 12:41:52 PM EST

Wait, you're one of those fucks who called me at 3:00 in the morning and disconnected right away? Screw off.

[ Parent ]
Ok, so I voted a +1... (3.87 / 8) (#8)
by psctsh on Sat Jul 07, 2001 at 03:57:33 AM EST

...but there was just something inherently wrong with this piece. It took me a few minutes before I realized what the problem is, mainly because it's something you took for granted.

The problem is that it was claimed by Stephenson(not by you I'll admit--you remained fairly ambiguous on this point) that GUIs by their very nature limit the user in terms of functionality (and I'll also admit that I'm going to take your word on this--that was one long-ass page you linked to). I find this statement to be completely and utterly wrong--a well designed GUI is easier to understand, and every bit as extensible as the command line. At the most basic level, a gui can emulate the command line through the use of various radio-buttons, check-boxes, and text-fields.

When done properly gui's give greater control over the input of data and the output of said data--take for example "grep" vs the windows search. When I decide to use grep, after I get the output I have to call something like "emacs filename" or "notepad filename" or whatever the launching program is. If at a later time I want to go back to that result set, I have to reenter my search, and then reload the file.

Using windows search, my results are displayed in a pane on the right, and a simple double click opens the file for editing, automatically choosing the correct editor (what? I want to use an alternate editor? Right-click and choose "open with"). Should I need my previous result set again, I just switch back to explorer and it's there.

One of the main complaints I've heard about gui's is that they "slow you down." Yes, I'll agree to that--conditionally. I'd like to point out that shells and command lines slow you down as well. Any time I'm doing programming, or typing up a document, I'll spend most of my time in a shell. It's faster--I don't have to keep moving my hand off the keyboard to the mouse. Conversely, when I'm browsing the web, or doing something that involves the use of an obscure filename, it's much easier to use the mouse to click on a link (rather than tabbing through them), or click on a filename (rather than cd'ing to the directory, doing a "dir" to remember the exact filename, typing "filename --help" 'cause I don't remember the exact flags...).

Did I have a point? Oh yeah--I guess I could sit here and pick out the flaws of command lines and GUIs all day, but I'm starting to lose interest. I think the keyword here is "inertia," 'cause it seems that the fastest way to something is by not changing the way you do things.

And besides, everyone knows great GUI design is an art form--what's it take to add stuff to a command line program? An extra "case" statement? It sounds like Stephenson's just bitter that he failed elementary crayons.

I _will_ go out on a limb... (4.50 / 2) (#22)
by 42 on Sat Jul 07, 2001 at 10:30:06 AM EST

...and state that if you didnt think I was agreeing with Stephenson about the GUI limitations, sorry for not being clear enough. I totally agree with him on that point.

Let me provide a minor example. Windows Explorer, for example, provides the basic functionality of the Unix "find" command. Using Windows Explorer, you can find files anywhere within your drive that match a pattern. This is done by using "Find" from the right-click menu on the drive.

This tool can even emulate partially, an advanced feature of "find". That is, the following command :

find . -name <file name pattern> -exec grep -l <some pattern to search for in a file> {} \;

....can be emulated by "Find" when you select the "Advanced" tab of the "Find" tool. However, thats where the capabilities of "Find" stops. The UNIX "find" command has the capability to execute arbitrary commands via the "-exec" flag. I will concede that the Windows Explorer tool is very intelligently designed - they have implemented in it, the features that is responsible for 95% of the tasks "find" is used for. But if you wanted to do more with "Find" you are stuck.

Now you may argue that I am really comparing apples to oranges, since it may just be a coincidence that the "Find" and the "find" tools have bery similar names. In that case, there would really be no point to comparing the features of the two tools - "Find" may not have been designed to replace "find". To that I say (1) While that is possible, its not very probable (2) Think about how you could implement via a GUI, capabilities like that provided by the "here document" feature in editors, or 'sed'. (No, 'sed' does not have a programming language - it is not even capable of computing what a push-down automaton can).

Now, having said all this, you should realize that this is only tangential to my point. The argument about the efficacy of GUI's is one I mentioned, but is not the one that I wanted to debate. My statement is that GUI's are by and large helpful to newbies. A carefully designed GUI should not be scorned by experts just because they dont need it. As pointed out in this discussion by Weezul, there are different levels the GUI can advance you to. So what if, "expert" (or "systems programmer" to use Weezul's terminology) isnt one of those level?

[ Parent ]

I thought you agreed, but it was rather ambiguous (5.00 / 1) (#33)
by psctsh on Sat Jul 07, 2001 at 04:06:58 PM EST

...and I figured I'd try to avoid accusing you of anything. I also know that you weren't willing to argue this point, because it was taken for granted [in the context of the article] that Stephenson was right. Since I disagreed with one of your assumptions, yet agreed with the rest of the article (which was a reasoned explanation as to why novice GUIs/wrappers should exist), I decided to argue the point I was interested in.

I didn't really feel like bringing this up in my post, because quite frankly I had grown tired of writing (as you can tell towards the end--I stopped caring completely). In the interest of time I neglected to mention that I agree--windows' find is poor compared to grep/find combinations. It was designed to be as simple as possible, and is also much slower than grep is (unless indexing service is enabled). I used windows' find as an example simply because it's the most widely known GUI file search out there.

Given two hours with visual C and I'd have a comparable search/find utility that uses a gui. However, my point (which came across poorly, now that I reread my post) wasn't that GUI's are necessarily better than command lines. My point was that they can always be made to be equal or better (it seems many gui designers go for the LCD though), and the ideal one to use is more often than not going to be the one that's quickest to access at the time. So if you're working at a command prompt, it's going out of your way to launch a window and search, and vice versa.

To just make the absolute claim that a command-line prompt will *always* be more powerful than a GUI equivalent is just naive. There will always be varying cases, with command-lines being quicker and more powerful here, and GUI's being quicker and more flexible there.

As for my find/grep GUI solution? Implement GUI representations for each shell command (to create a consistent interface), and give each command a "chain" button, along with an "execute" one. So you set up your options for "find"--maybe click "recursive" and "case insensitive," type in your regular expression for the file, click "chain," and pick another program (say "grep"). It then loads a pseudo instance of "grep"--select the options you want, and for the text string type in "yourtext," for the file thing type in "$file" and voila--hitting "Execute" now gives you a command-chaining interface that works on the output of each previous command. I'm not saying it'll be easier to program (much harder actually), but if each shell command saved your last query inbetween sessions, you could do complex chaining in relative seconds without the need for memorization of obscure command line flags (I use 'grep -ir' 99% of the time--why should I have to type in the -ir over and over again?).

The only reason GUIs are so limiting now is 'cause they're designed that way. Microsoft knows the average user wouldn't understand chaining together various commands, so they write a crutch program that works for 75% of the users. Everyone else more or less copies Microsoft's GUIs, so what you have are very few GUIs designed for advanced users. And even then, the "advanced" GUIs you see are mainly just the idiot dialog boxes with extra checkboxes.

So I'm sorry that I'm arguing a point you don't feel like arguing--it just irks me when people state that one way is the best way to do things, no discussion (I'm not really talking about you specifically here, just the general population of technical users).

[ Parent ]
Some practical advice (4.00 / 2) (#36)
by evin on Sat Jul 07, 2001 at 05:22:57 PM EST

If you use emacs, try M-x grep, which will display the results in one buffer and you can press enter on them and have them loaded in another buffer. Very nice.

And you get the various benefits of grep over windows find: regular expressions, pipes, etc.

[ Parent ]

Yeah (3.00 / 1) (#38)
by psctsh on Sat Jul 07, 2001 at 05:55:12 PM EST

I know, and I made everything seem overly complicated in my post for effect. Obviously there are better ways around it (Ironically, a better grep through the use of a GUI), and I really don't have a problem with alt+tabbing back between my shell and emacs. And yes, I know that 'M-x shell' opens a shell in emacs, it's just that the win2k dos shell kicks ass. And I hate the fact that you can't ctrl+tab through every buffer in emacs (sure, there's always lisp--but when I tried reading a few scripts, the experience ended with me crying). C-x b just gets on my nerves sometimes...

So thanks for the concern, but part of my post was play-acting (does hyperbole apply to non-poetry?), and part of it was the fact that I haven't slept since thursday afternoon. My mind's not at it's sharpest right now, and dammit if my posts aren't really long rambles. Oh how I long to return to my formerly concise posts...

[ Parent ]
Re: Yeah (4.00 / 2) (#43)
by cooldev on Sat Jul 07, 2001 at 08:08:47 PM EST

sure, there's always lisp--but when I tried reading a few scripts, the experience ended with me crying

This post is somewhat off topic, but I laughed when I read this, so I had to help the author out. Try this in your .emacs file. It'll map ctrl-tab to flip between buffers.

(global-set-key [C-tab] 'bury-buffer)

On a related note eshell kicks some serious ass, especially compared to Win2k's CMD. But, like most command lines, it's not really for newbies...

[ Parent ]
Correct link (4.50 / 2) (#44)
by cooldev on Sat Jul 07, 2001 at 08:12:31 PM EST

WTF, seems that Kuro5hin is escaping the quotes around the href. Lame.


[ Parent ]
Huh? (3.00 / 1) (#49)
by Tachys on Sat Jul 07, 2001 at 10:37:06 PM EST

I have no idea what you just said.

[ Parent ]
newbie vs. expert (4.80 / 5) (#9)
by b0r3d on Sat Jul 07, 2001 at 04:22:34 AM EST

A number of user interface folks (Jef Raskin for one, in his book The Humane Interface) argue that the newbie vs. expert user problem is largely a myth. Human limitations, both cognitive and physical, put significantly more restrictions on good user interface design than this supposed dichotomy. Examples of such limitations are that the human mind has a limited short term memory, and certain physical actions (such as moving a hand from the keyboard to mouse) take longer than others.

A visible interface is one where all the commands can be determined by the user using the system (not including an external source, such as a help file). A command prompt ain't this, that's for sure. A well designed menu system can be, but many are not. This seems to be what you're referring to when you describe a "newbie friendly" system, but at the same time, there's no reason it should automatically detract from a user establishing interface habits and improving their interface performance (i.e. becoming an expert user). Also, for any task, there's a relatively simple way to calculate average speeds, given average physiological data about how long it takes for a person to do some basic tasks (select with the mouse, press a key, etc.)

However, existing GUI interfaces rarely implement these principles well, and people also form emotional attachment to interfaces which they've developed habits for (whether or not those habits are actually efficient), so trying to judge between the value of the two paradigms, command line vs. GUI, is muddled. So, both paradigms will continue to be used for a significant period of time, each with their pros and cons, and discussions like this will continue, largely irrelevant, until interface design is approached from a more humane perspective, to borrow Raskin's adjective.

all commands determined by using the system (3.00 / 2) (#35)
by evin on Sat Jul 07, 2001 at 05:13:49 PM EST

Well, bash lets me do tab-tab [Display all 1511 possibilities? (y or n)] to list all commands in my path. Arguably this isn't terribly useful if you don't know the first few letters of the command, but I'd take it any day over using some huge hierarchial menu to select commands.

Why are help files out? If I'm trying to find a command or how it works in GNU, I read the info pages. If I'm trying to find a command in MS-Word, I read their help pages. Getting an info page is just another command within the system, and the MS help pages are just another menu option...

For people who only use computers a few hours a week, perhaps "visual"/"intuitive" interfaces are the way to go, but otherwise they don't make any sense to me.

[ Parent ]

but where do you find out about tab-tab? (3.50 / 2) (#37)
by b0r3d on Sat Jul 07, 2001 at 05:24:24 PM EST

That is an invisible command. A help file is a kludge for a poorly designed interface. Yes, sure, I use them to when I need to learn more about a program, but if it was better designed (or so the theory goes), I wouldn't have to search for that information in a source external to the interface of the program (I'm limiting the interface of the program to the part that actually lets you accomplish the task invovled). Admittedly, this level of design is pretty difficult with the interface inertia that we have today.

[ Parent ]
It's an issue of expressiveness (3.75 / 4) (#11)
by vgi on Sat Jul 07, 2001 at 05:00:11 AM EST

Van Jacobson, at a Usenix keynote speech some years back, characterized the difference between Windows (GUI) and Unix (cmdline) as a difference in expressiveness. He used writing as an analogy.

With Windows you have a large but nevertheless limited number of sentences that you string together to make paragraphs. The sentences are very useful, but are picked by someone else.

With Unix, you have words, the ability to create new words, and a grammer that allows you to create an infinite number of sentences that you can then string together to make paragraphs of your own choosing.

A Question of Opacity (4.50 / 4) (#17)
by _Quinn on Sat Jul 07, 2001 at 07:21:51 AM EST

The problem I have with all the newbie interfaces I've seen is that their learning curve exists completely independently of the expert's. It's a nice, easy curve, for the most part, it just doesn't go very far; you have to turn around and try a different path to progress. That's why a lot of people like the command-line; the initial curve is steeper, but you could* write a webserver in shell-script; the basic commands compose into more complicated ones.

The proposals I've liked the best for new interfaces all address this, by making GUI actions composable in a consistent and dependable way; the back-end basically involves completly componetizing the desktop and apps, which is why (it looks like) only KDE or GNOME has a prayer of doing anything like this any time soon.

* If you try this at home, post it to k5 when you're done. :)

Reality Maintenance Group, Silver City Construction Co., Ltd.

Wow that must have been some file (3.60 / 5) (#19)
by Tachys on Sat Jul 07, 2001 at 07:40:43 AM EST

<p>Neal Stephenson's "well-reasoned" article?</p>

<p>It seems he has declared war on the GUI, because this powerbook deleted an important file</p>

<p>He talks about how MPW is like a CLI and how the apple people made it that way because the GUI gets in the way. Oh please, they probably made it like that because they needed a way to create a GUI in the first place and the CLI was what they knew. He should check the Development tools that come with Mac OS X. Very nice GUI, just love the Interface Builder. I actually care about getting a program's source code. Because I can then open interface builder change the keybind and the menus.</p>

<p>He talks about how a car would be dangerous to drive if they had GUIs. Well lets see what would happen if cars had CLIs. I going to run into that car! need to make a quick turn!

Unknown Command
Unknown Command

Or was it steer?

Unknown Command
Unknown Command
Need Arguments

Arguments?!? Need to check the man pag...


Automation (3.50 / 2) (#20)
by jneves on Sat Jul 07, 2001 at 08:46:19 AM EST

Today, the CLI (Command Line Interface) biggest advatage is how easy it is to automate. You just pick a couple of commands you wrote, put them on a file and reexecute them. Then features like flow control and variables simply add versatility.

We don't have this ability on GUI's right now. I was hopeful when I first tried GTK and it added a -record and -playback options to every executable. Unfortunatly this feature was incomple at the time, and got completly whortless as GTK evolved. Maybe one day...

macros? (4.00 / 2) (#26)
by rebelcool on Sat Jul 07, 2001 at 12:21:45 PM EST

macros have been around for ages. I used these in windows 3.1 all the time... though once 95 came out i never really needed to anymore.

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

No. Not macros. (3.00 / 1) (#32)
by jneves on Sat Jul 07, 2001 at 03:39:32 PM EST

Automation means easily repeating what you normally do. Macros, in fact, are a new language you have to learn. Learning more than a language (as in way to interact with the system) is more than can be expected from a normal user (I mean my mother and my sister; my father doesn't use computers).

[ Parent ]
No, he meant macros (4.00 / 1) (#34)
by psctsh on Sat Jul 07, 2001 at 04:33:17 PM EST

Win 3.1 macro recorder--records keystrokes and mouse clicks/movement. It's not a scripting language.

So you're mother and sister would have trouble clicking "record" and then operating the computer as usual?

Ok, ok, bad example, as my parents don't understand why word won't read in power point presentations correctly; getting them to understand win3.1 macros is entirely out of the question. But Rebelcool wasn't talking about scripting macros, he was talking about the macros in terms of win3.1

[ Parent ]
not a language. (4.00 / 2) (#40)
by rebelcool on Sat Jul 07, 2001 at 06:37:12 PM EST

macro is perhaps the most widely tossed about word in computers...

I meant the old windows macro recorder. You clicked a record button and it would record your mouse movements and keystrokes so you could automate repetitive tasks.

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

As opposed too? (3.00 / 1) (#52)
by Tachys on Sat Jul 07, 2001 at 10:49:15 PM EST

Learning a lauguage to just use the computer in the first place?

Any game that gets banned by the Austrailian govt can't be all bad... - Armaphine

[ Parent ]
You always need to learn a language (none / 0) (#60)
by jneves on Sun Jul 08, 2001 at 04:07:54 PM EST

I know I'm using a paradigm that's not usual for most technical people, but when you learn to use a computer, you are, in practice, learning a new language, a new way to interact. Most "normal" people know this, and that's the biggest difficulty they have, it's the "it's so different" problem.

[ Parent ]
Visual Languages (3.00 / 1) (#21)
by jneves on Sat Jul 07, 2001 at 09:00:08 AM EST

At this time people are programming GUIs a little like progrecial;page=article#attentionamming was done in assembly: everybody defines their own languages. Look and Feel standards are, in fact, a first try at visual languages, but fail to evolve. Usually a look is defined and some standard buttons and shorcuts but it stops there.

For me, Lego's RCX language for Mindstorms is the first language that effectively goes one step further and allows definition of flow control. Let's see how these kind of languages evolve.

You need to do it all. (4.40 / 5) (#23)
by localroger on Sat Jul 07, 2001 at 10:31:23 AM EST

Windoze is not just a GUI system. Even on 2000 (and I haven't tried it, but I'm betting on ME) you hit START, RUN, and type CMD. Guess what pops up? You can then proceed to write .BAT files to automate your system and issue wildcard-laden commands to your heart's content.

Many Windoze apps also support command line arguments. You can use these, for example, to automatically run a VB app in the IDE and pass it arguments as if it was compiled.

Think of how you would answer the question "How do you underline something in Word?" You could highlight it and hit control-U, you could hit control-U before typing it, you could click the underline icon on the font toolbar instead of using control-U, or you could go through the menu system (which has a different series of keyboard shortcuts). And that's not even considering Wordperfect emulation mode.

While there are a lot of things wrong with Microsoft it has to be said that they have gotten this part right. Even as they have been hiding these tools from newbies so as not to frighten them, they have been building hidden expert methods into their products. This is the point of including VBA in everything. Usually when you see a Windoze app that forces you to the mouse it's either (1) something that really needs a pointing device like a publishing program or game, or (2) wasn't written by Microsoft.

The comment about forcing the newbies to learn to climb Everest is well taken. But a better example would be Pike's Peak. If you can't climb it, you can drive. And if you don't want to face that steep road with all the switchbacks, you can take a train. It's not that the mountain is shorter, but you can miss some of the scenery on the way and get to the top more easily. All the methods are available, and you can pick the one that works best for you.

I can haz blog!

What do you want to do today? (4.50 / 4) (#25)
by Sawzall on Sat Jul 07, 2001 at 11:53:22 AM EST

Well, if you are 99% of the users of a computer system of some sort (ignoring OS or hardware platform), you want to write a letter, or answer your email, or download some porn or MP3. Reliably, efficently, and simply. That's all.

And for whom are systems commercially developed? That 99%. Once you leave your passions aside, these are just tools. Most of us have a hammer at home. It is likely a simple one. It solves 99% of your hammering needs.

So while the power of a particular OS may be important to those supporting it, the reality is that the one that enables the user to be productive is best. GUI's are good for some applications. In accounting areas, they are often a problem since one has difficulty mousing ahead, while typing ahead is common. There is a zen quality to simple. It would be a joy to see that movement in computing. There is such a movement in my other hobby - audio. Absurdly, you usually have to pay more for it. Perhaps it is because simple perfection is much harder than adding buttons and blinking lights.

Hah (4.80 / 5) (#29)
by regeya on Sat Jul 07, 2001 at 12:46:08 PM EST

This is slightly off topic, but relevant, I think.

Yesterday I watched a chanop in a FreeBSD chatroom (and allegedly the chanop was a fBSD developer) repeatedly kickban some poor slob who was trying to get help with installing VMWare. The poor sap was getting an error message that included some header files that contained the word "linux" in them, so the savvy chanop kept kicking, with the message, "FreeBSD is not Linux!"

Further explanation was given by the chanop (not a direct quote, but paraphrased from memory): "VMWare is a binary-only release, and the error given was a compilation error, so the error was obviously not from installing VMWare, but was just a troll."

Which is a nice theory, but if the chanop had bothered to look at the pkg-descr for vmware, he would have read:

This is the Linux version of the VMware virtual machine emulator made to run on FreeBSD using the Linux compatibility mode. VMware can be used to run Microsoft MS-DOS, Windows 95/98/NT/2000, Linux, FreeBSD, or any other operating system that runs on the i486.

Official VMware, Inc. web site:
WWW: http://www.vmware.com/

We all are thankful to Vladimir N. Silyaev for porting vmmon/vmnet modules to FreeBSD. Have a look at his page for the latest information:


and ayuh, folks, even on Linux VMWare needs kernel modules to be even remotely useful. Anyone who had ever used VMWare before should have known that. Instead, the chanop used arrogance and limited experience to make a rash decision to kickban an innocent FreeBSDer who just needed a little help.

Moral: when you get to a point where you can make such snap decisions without thinking, and when you think you've got it all figured out, and you start thinking that people are asking stupid questions, you need to take a deep breath, analyze what's going on, and not make brash decisions because someday, oh someday, you're going to be the one who doesn't know what this "clueless moron" knows by heart, and if you'd like to be treated nicely when asking about it, don't treat the person like a moron right now. Be nice, listen, and figure out exactly what it is that this person is getting at.

The same holds true for user interfaces for computers: just because the accountant down the block doesn't understand the UNIX command line doesn't make the accountant a moron, no more than you taking your tax forms to the accountant to have the accountant do your taxes for you makes you a moron.

[ yokelpunk | kuro5hin diary ]

Like driving. (5.00 / 1) (#46)
by Kaki Nix Sain on Sat Jul 07, 2001 at 09:42:56 PM EST

This seems quite similar to something my father said when first teaching me to drive (I guess sometime around the age of 9 or 10). It was something like "there will come many times when you think that you are a good driver and don't need to worry about it, at those times you are more dangerous than you are right now." :)

[ Parent ]

On time, intuition, and conceptual understanding (4.33 / 9) (#39)
by xWakawaka on Sat Jul 07, 2001 at 06:08:41 PM EST

On time, intuition, and conceptual understanding.

The aspect of this debate that is most interesting is not the "so-easy-your-grandmother-could-be-emailing-in-minutes" (where even Microsoft is not good). The interesting thing here is the vast middle ground between newbie and l337 h4X0r (nearly everyone). This is where Microsoft (If you'll forgive the pun) excels, hrm.

I'll use myself as an example (dons asbestos undies). Let's say I want to set up a machine to be a DNS and HTTP server. I understand, conceptually, DNS and HTTP. I understand that I need hostnames and IP addresses in my DNS and I understand that an HTTP server will dish out documents stored in a certain folder. At the same time lets say I need to pound a nail into a board on my wall. For both the server and the nail I'm going to need tools: Software on the one hand and a hammer on the other.

EXHIBIT A: To pound the nail into the wall. I aquire a hammer and, even though I am not a carpenter (and even more so am ignorant of both the history and culture surrounding carpentry), within seconds I can figure out how the hammer can be best (or at least adequately) used to take care of the nail. Success!

EHIBIT B: In the case of my DNS server I'd like to be able to punch in my hostnames and IPs, push the DNS "Go" button and be done with it. Similar to the hammer- it's a matter of seconds to figure out HOW to do what I understand I want to do. This does exist, I do it all the time. When I need to update my DNS server I push the update button. Contrast that to the following scenario:


  • hmmm. I don't know how to install BIND. Let's see.. man pages... okay... maybe we start here...
  • k, I don't know what a tarball is but I see the word source in it so presumably its a compressed source code package of some sort.
  • okay now I have to figure out the syntax of the uncompress utility (If I even have one). that's fine. I'll need that again anyway.
  • well... I know it's embarrassing to admit this, but I'm not really a programmer, so I don't really know whether this is working or not but I guess I'll figure out what these scripts are all about at hope for the best
  • yeah... well you're going to make fun of me but I'm don't code much (at all) and I'm not really expert with a compiler, but I'll do it just like it says on the "man" page and hope for the best.
  • should I be concerned about the compiler warnings and errors? It seems we've got a ways to go in this process and it would be nice to know if I've already botched it up.
  • okay again you're going to laugh (not with me) but I don't know what to do here. I'll try very hard to figure it out from the man pages
  • okay I think its installed though I have no idea if its all proper. Now where do I punch in my numbers?
  • okay I'll try.
  • There's absolutely nothing here on the syntax of the BIND file. This is going to take some doing.
  • I did it! I figured out the syntax! It's wonderful, My DNS server is wonderful!
  • Uh oh, the latest BIND exploit du jour is out. I hope upgrading is easy...

A note for the literalists who have entirely missed the point and and now preparing to correct and insult me: This is an amalgamation of my first several software experiences on FreeBSD and Linux. It may not reflect the current BIND installation procedure.

What was that about a hammer?

While admitteldy any tool with more configuartion options will be more flexible than any simpler tool- raw plutonium is also more "flexible" than a working nuclear reactor- and the difference between exhibits A, B, and C will dictate my choice of tools. I'm not interested in being a l337 BIND hacker, I (and millions like me) am interested in having an adequate, working site as quickly as possible.

Bad Examples (3.50 / 2) (#61)
by Matrix on Sun Jul 08, 2001 at 04:10:34 PM EST

EXIBIT B: In the case of my DNS server I'd like to be able to punch in my hostnames and IPs, push the DNS "Go" button and be done with it. Similar to the hammer- it's a matter of seconds to figure out HOW to do what I understand I want to do. This does exist, I do it all the time. When I need to update my DNS server I push the update button.

Yes, but what if you want to do more than just punch in your hostnames and IPs? What if you want to do something more complicated, or even a slightly more intricate version of the above scenario? Your proposed GUI then does nothing but get in the way, and if that's the only way to configure the program, as is the case with many Windows programs, then you're screwed.

GUIs are more limited than the command line or text config files by nature. You'll never find one that can replace them. Try telling swat to display all the possible config options sometime - kind of overwhelming, isn't it? At least with printed or online documentation and a text editor, I can only look at what I need to.

And your Exibit C completely ruins your argument. I don't care if you think I'm a literalist - comparing a Linux/BSD process from two to three years ago to a Windows one today is like comparing WordPerfect 5.x's ease of learning to Word 97. Especially if you're comparing a DNS server designed for newbies to BIND - there are, and were, servers that are/were far more newbie-friendly and secure.

"...Pulling together is the aim of despotism and tyranny. Free men pull in all kinds of directions. It's the only way to make progress."
- Lord Vetinari, pg 312 of the Truth, a Discworld novel by Terry Pratchett
[ Parent ]

gui vs cli (4.33 / 3) (#69)
by kubalaa on Mon Jul 09, 2001 at 06:58:51 AM EST

Yes, but what if you want to do more... Your proposed GUI then does nothing but get in the way...

I don't see how it "gets in the way"; presumably it takes you less than a second to click "Cancel." Certainly a lot less time than it takes you to read and memorize the format of a config file.

GUIs are more limited than the command line or text config files by nature.

That would be true if by GUI you meant being limited to pointing and clicking. Fortunately that's not true. As it stands the conceptual difference between a GUI and a CLI is that the CLI is single-threaded in interaction while a GUI is multi-threaded. I'm not talking about programmatic threads, but information flow; can inputs and outputs occur simultaneously. On a CLI you may send jobs to the background and so on but as far as you're concerned there is only one input and one output for everything. It forces you to become good at memorization and recall, because you only have one path through time and the console's "short-term memory" isn't very good. So we've evolved elaborate structured conventions, like config files and scripts, for encapsulating a series of interactions which are conceptually simultaneous.

In a GUI, you are still limited to one input thread because you only have one keyboard, but it's a lot easier to switch its target, and there are many many output threads. An atomic unit of interactions can be represented as a dialog, and an application can be wrapped in a window. You don't have to memorize all possible state transitions because the GUI can show them to you in an organized way. Almost any information can be grasped more quickly in a structured layout; some information can't be presented any other way (like pictures).

Try telling swat to display all the possible config options sometime - kind of overwhelming, isn't it?

It's been my experience that an overwhelming configuration system is badly designed. You should only need to know about what you need to change, so unless your ideas themselves are overwhelming there shouldn't be any difficulty. There are a few ways to simplify things. One is that no matter how many configuration options there are, there are usually a small number of distinct modes people fall into which the program should know about. Even if one of these is not sufficient, it's always easier to tweak than start from scratch. Organization never hurts either, nor does good documentation with lots of examples. And something people never seem to think of: intelligent defaults. If nobody uses the default configuration, then that's a bad sign; if I'm not picky there's no reason I should need to touch anything to get the most reasonable behaviour.

[ Parent ]

A Quick Reply (none / 0) (#78)
by Matrix on Tue Jul 10, 2001 at 09:52:18 PM EST

I was mainly just being difficult - congrats for handling it so well. ;-) IceWM and WindowMaker both have config tools that do what you describe, and do it rather well. The Linux kernel's xconfig tool's another good example.

However, there are advantages to text config files and scripting. Speed, flexibility and automation. From experience, an expert can write a config file by hand a lot faster than it would take to generate the same config file through a tabbed (or whatever) GUI config tool. Hand-editing a config file's also more flexible - you know exactly what you're putting in, and you can format it to your liking, not the liking of whoever wrote your config tool. As for the automation of scripting, I don't think that needs commenting on.

And I don't memorize config file formats. Never have, and probably never will. I'll either run off a copy of the man page and find what I need in there. But only if the config file's poorly designed - any decent parser allows for comments, and any decent software author will describe the format of the config file and the options within the file itself. So you don't need 'multithreaded' I/O - everything's all in once place, conveniently laid out.

"...Pulling together is the aim of despotism and tyranny. Free men pull in all kinds of directions. It's the only way to make progress."
- Lord Vetinari, pg 312 of the Truth, a Discworld novel by Terry Pratchett
[ Parent ]

languages are fine (none / 0) (#79)
by kubalaa on Fri Jul 13, 2001 at 08:48:54 AM EST

I'm not denigrating computer languages. Scriptability is great. Nor am I saying that everything is better presented visually and without words. I'm just saying that having a layer of interaction beyond that available on an 80x25 console never hurts and often helps, even if it's just window managament. And as long as we have this graphical environment, there are many tasks which, scripted on the command line, would be much easier to learn with a visual metaphor. (And yes, we should still have the scripting ability for people who can use it). That's the beauty of GUI, many possible presentations of the same thing, as opposed to a CLI, where there's only one (text).

[ Parent ]
Text? (none / 0) (#80)
by Matrix on Fri Jul 13, 2001 at 12:56:51 PM EST

The GUI only has one possible presentation for something: graphics. Doesn't make it any more or less useful. Just because something's presented entirely in text doesn't affect the presentation of the thing - there are a number of ways one can present information using just text. (For example, what about a curses interface to config? Just as easy to learn, and much lower system requirements.) There's quite a lot of things one can do on just an 80x25 console.

That's not to say that a GUI isn't a good option to have - I'm just saying its not the only option, and its not, by nature, easier to learn or use than an interface that presents itself through text. Its how the interface functions that's important, not the medium it presents itself in.

"...Pulling together is the aim of despotism and tyranny. Free men pull in all kinds of directions. It's the only way to make progress."
- Lord Vetinari, pg 312 of the Truth, a Discworld novel by Terry Pratchett
[ Parent ]

still disagree (none / 0) (#81)
by kubalaa on Fri Jul 13, 2001 at 03:33:50 PM EST

Graphics is a superset of text. This means a GUI can present text as well as anything else. Plus there's an issue of resolution. A glance at ASCII art shows you the limitations of one-character resolution. You're right that presentation isn't so important, but there are pure physical and technical limitations to a GUI that a CLI doesn't have. It's like saying that a Game Gear offers all the entertainment possibilities of a Playstation 2; sure, games are about a lot more than graphics but better graphics never hurt anybody and the level of immersion they add is very powerful.

[ Parent ]
re: experts and newbies (3.60 / 5) (#41)
by qwerty2 on Sat Jul 07, 2001 at 06:48:32 PM EST

Every now and then, like all major flamewar topics, the question of how newbie-friendly a Toast Develpoment System (TDS) should be gets reseurrected. On the one hand, we have folks claiming that CBI (Chrome Box Interfaces) and polish are either inessential / deficient / contrary to the culture and philosophy of the TDS in question, etc. On the other hand, you have folks that point out that the CBI operating systems are very newbie friendly, that the other camp is blind to the enormous strides being made in push-button toasters and toaster ovens simply because the focus of improvements is on the end user. Can't we all just get along?

Perhaps the most eloquent defense that I have read of the whole Bread-On-Stick-Over-Open-Flame (BOSOOF) vs the CBI argument was written by Emeril Lagasse. His arguments for the primacy of the BOSOOF are well reasoned. In it , Mr. Lagasse forcefully makes the point that when push comes to shove, a CBI's bread-toasting capabilities will be limited by the visions of its designers, whereas the toasting options open to the BOSOOF user are without limits...

Whats your point? (2.50 / 2) (#53)
by 42 on Sat Jul 07, 2001 at 10:59:19 PM EST

Maybe I am being dense here, but I dont understand the underlying meaning of your post. Are you trying for satire? In that case, you are satirizing the wrong bit - the intro. Are you trying to rebut my argument? I dont see a rebuttal here. Or is this a Slashdot style "funny" post - if so, I'm not sure you should get points for it. This is the technology section - not Humour.

[ Parent ]

YDGI (none / 0) (#76)
by davidmb on Tue Jul 10, 2001 at 11:32:10 AM EST

It seemed to me to be a perfect summing up of the old CLI vs. GUI argument that users of a GUI are limited by the designers' imaginations, whereas CLI users have almost unlimited flexibility.

As with the bread-on-a-stick approach, most people don't need that much flexibility. Those that do, go out and start their own fires. They have the knowledge and the inclination to do so.

As always with this debate, it quickly turns into a holy war, with neither side realising that they have no real reason to quarrel.

I didn't realise humour was disallowed on K5, where in the rules does it say that?
[ Parent ]
"Expert use" and ease of use (4.00 / 5) (#56)
by WWWWolf on Sun Jul 08, 2001 at 05:42:31 AM EST

Some rambling on "expert" programs...

Typically, people think that "expert needs" need a complicated and powerful interface.

Well, that's true. But "experts" also need an easy interface to things. A good user interface makes easy things easy, while not making complicated things impossible.

A good example on this misthinking: A clueless computer book author once described EDLIN.COM (a particularly hard-to-use editor) as "primarily intended for programmers". Now, what did real MS-DOS programmers use? Not the "hard" editor, but rather a simple but powerful editor called qedit.

Do experts choose their work software by their unforgiving interface? No, they buy what they buy to get their job done.

I don't need to invent a new type of drill to make a hole to the wall, I can buy a pre-packaged, ready-to-use drill and guidebook "How to drill holes to your walls without electrocuting yourself, causing pipe leaks or collapsing the whole building".

My job? Graphics and web design, mostly. Some years ago, I would have gladly bought a good graphics program. Nowadays, I use GIMP. I chose it because it costs less than other programs and gets my job done. It's also a good example of good UI design: It's easy enough to learn, but even true experts can find more and more new cool features under the hood. GIMP is a very powerful program for "dumb users" and script maniacs alike.

I'll take two examples of my experiences here. Both are about things that I'll rather do in Windows at the moment, mostly because the software is, I think, too expertish on Linux side.

Sound editing. I have found an excellent non-linear sound editing tool for Linux, and it's called Ecasound (comes with well-equipped distributions). Very cool for making all sorts of modifications to sound files. Problems? Yeah, it's cool that I can do all sorts of effects from shell scripts, probably cool if I'm mass-converting stuff and need to add same fade-in/out effect on all files, but I don't want to remember how to write a kilobyte of commands to do that for one file! There are not too many interesting GUI sound editors for Linux...

Video capture, editing and encoding: Linux video capture works - in theory. Looks like I need a vastly faster disk drive and stuff for that, though, and the capture software (streamer) isn't too forgiving and segfaults all the time. Video editing software (Broadcast2000) is nice, but rather... clumsy. (If you're making an UI, at least make it usable and obvious...

Encoding MPEG program streams is an entirely new chapter, then. This is, I'd say, illegally hard. For example, how should it work on command line?

$ mpeg_encoder -v --profile=videocd videoclip.avi videoclip.mpg
Encoding MPEG-1 program stream
videoclip.avi: AVI, MJPEG compressed, 320x200 @ 25fps, 44100 Hz 16bit 1 channel, 37542 frames (00:25:02)
INFO: Resizing video to 352x288
INFO: Splitting audio to 2 channels
Encoding video stream, frame 3137/37542 (8% done)...

That's how. Now, how does it work in Real World? I would need to "explode" the AVI/QuickTime either into separate frames and sound file or separate QuickTime video (soundless) and .wav audio files, which requires special tools.

After three hours, a 10-second test clip that I captured was MPEGed. I used streamer (part of xawtv) and mpegtools packages, and the quicktime clip was split to video and audio parts via broadcast2000. Video picture flickered, was WAY below designated framerate and sound was out of synch. But hey, I wasn't an expert, maybe that's why.

Never mind I had never had such experiences in Windows98SE with "amateur" drool-proof tools like VirtualDub and bbMPEG. I have no idea do the professional digital video people have that Linux-style hell with Adobe Premiere... but hey, they're professionals, don't blame me, I just wanted to convert some TV programs into VideoCD format.

Now, I'm not saying this stuff totally sucks. It's just painful for the uninitiated to use! All I wanted was to capture some stuff and store that as VideoCD-compliant MPEG. In Windows (and Mac, I'm sure), no matter how "expert-preferred" or not the program is, the simple things are simple. In Linux, it seems, sometimes the painful tasks are painful, but so are the easy tasks.

Yes, I know, the main reason why people haven't made proper tools for Linux is that they're not needed here. I have seen a big attitude problem here: For example, when some people asked support for SBLive!'s some arcane features, people just said "who the hell needs that?" Yeah, just make the drivers capable of playing MP3s, keep 99% of the users happy...

If there's anything you should remember when making stuff, here's the thing: Simple things simple. Hard things not impossible.

-- Weyfour WWWWolf, a lupine technomancer from the cold north...

DIY (re: proper tools) (none / 0) (#58)
by hjones on Sun Jul 08, 2001 at 08:38:20 AM EST

If you need it, then it is needed. Proof by example. Therefore it should be written. Therefore write it. That's how open source happens. If we all were willing to wait until someone else came along and developed what we wanted, we'd all still be using closed source.
"Nietzsche is dead, but given the way of men, there may still be caves for thousands of years in which his shadow will be shown. And we -- we small-minded weaklings, we still have to vanquish his shadow too." - The Antinietzsche
[ Parent ]
Hope lives... (none / 0) (#68)
by WWWWolf on Mon Jul 09, 2001 at 03:07:35 AM EST

If you need it, then it is needed. Proof by example. Therefore it should be written. Therefore write it.

*sigh* I wish I had time and expertise. =/

Fortunately, there are libraries to do this sort of stuff, and even some sort of (non-compiling perpetually-segfaulting) version of the video encoder I described, so all hope is not lost. Now, if only the v4l worked... =)

-- Weyfour WWWWolf, a lupine technomancer from the cold north...

[ Parent ]
"Easy to Use" vs. "Easy to Learn&qu (5.00 / 2) (#59)
by der on Sun Jul 08, 2001 at 01:45:34 PM EST

This discussion often pops up (as the article mentions), but there's a distinction that usually never gets made that's very important to the discussion (IMO - see topic). Now, I'm about to say something here, and many may thing I'm retarded or something, but read the rest of my comment eh? :)

Windows Is Not Easy To Use.

Still with me? Windows is easy to learn. It's 'padded' for newbies, and it is easier to learn for them than, say, blackbox (which I pick for my example because I happen to be running it right now, no real other reason).

This is a bad example, but it kind of gets my point across: Moving windows. In Windows, you drag on the titlebar and the window moves to where you drag. In Blackbox, and most popular X11 wm's, you can hold ALT and left-click anywhere on the window, and drag the window freely in the same way.

The chances of a newbie figuring this out on their own is pretty damn slim. Therefore, the Windows method is Easy to Learn, but the Blackbox method is Easy to Use, since navigating the mouse to a little ~15 pixel high title bar is a whole hell of a lot more difficult than clicking on an entire window.

Perhaps a better example I should have used is menu entries vs. hotkeys (pressing CTRL+S is alot easier than navigating to File->Save, for example) but you get my point... and yes, I'm aware that most Windows apps have menu hotkeys (although not enough). :)

So, I see it as more of a 'battle' between 'Easy to Use' and 'Easy to Learn' camps, rather than 'Easy to Use' vs. 'Hard to Use'. I mean, noone, with the exception of a few masochistic nutbags, really want an interface that is hard to use, there's no benefit whatsoever.

Agree with a but.. (none / 0) (#71)
by Rift on Mon Jul 09, 2001 at 03:22:20 PM EST

I agree with you on this one, but I think the author is not trying to say that windows is what's needed for new users, but that any gui is needed. to further your window moving comparison, alt+click anywhere may be easier to use than click on the titlebar, but is typing 'xwinsetpos Eterm +42.5 -6.5'? It's a bit harder to learn, that's for sure

It seems his argument is yes, the command line gives more power (you could eval commands inside the command line to give exacting and dynamic positions, for example), but I'd argue that it's definately harder to use. (I know where I want it visually, but not in exact coordinates!)

Yes, I know you probably wouldn't have any windows on a non-gui platform, but I was trying to fit the clarification in.

To this particular author's point, I think that the new people do need something. But I'd like to see a command builder, or something like it - here's my vision: You need to see how an interface is configured. In windows 2K, you'd right-click on 'My network places' and choose properties. You'd then right click on the 'connection' you want to view, and again choose properties. This is easy to learn, but difficult to do repetitively. In linux, you'd 'ifconfig eth0'. What I'd like to see in gnome or kde is a tool where you'd signify "I want to see eth0's properties", perhaps by right clicking in the device tree or some similar point-and-grunt interface. It THEN shows you the command it is issuing, along with a term window showing the output it also lets you change this command. This is the same for any system configuration utility : you can pick different options and devices, but it simply generates a command, shows it to you, and runs it. Perhaps a bit of reference if wanted on how it came up with those options. In this way, people could teach themselves to work in an command-line environment. It won't take 'em to the top level, but it'll give them a leg up, while NOT removing the ability to run in 'expert' mode. It lets them migrate to using the command line, instead of making them choose one or the other.

Yes, it's flawed and a bit cumbersome, but it's the best I've come up with yet. I'd love to see some ideas on a transitional environment / toolset, instead of two camps not budging on the issue.

A pen is to a car what a meteor is to a _____
[ Parent ]
Agree as well. :) (3.00 / 1) (#75)
by der on Tue Jul 10, 2001 at 09:37:51 AM EST

I wasn't really 'shooting down' the author's point (I should have made that clearer), I just felt it needed distinction in an argument about power vs. 'Ease of Use', because, like my comment said, learning and using are very seperate things. You are right, though, GUI's are better at some things, just as CLI's are better at others.

As it happens, I'm sortof (privately) working on a framebuffer-based CLI/GUI combined environment right now, but it may never see the light of day and I do not speak of it for this reason. :)

[ Parent ]
Command line (4.50 / 2) (#66)
by strlen on Sun Jul 08, 2001 at 09:24:24 PM EST

Command line has the advantage that it encourages understanding of the inner-workings, and it makes it much easier thing to do. Only a very complex, and un-intuitive GUI (which defies the whole point of a GUI) will be able to provide that. Now, not everyone needs to understand what they're doing, but then not everyone needs to be an OS designed for expert in mind (unless its a specifically designed, embded version of the above).

An example of a confusing, and needless GUI for instance is the bios setup screen. Compare for instance Phoenix BIOS with SPARC's open-boot. I find Open-Boot way better, same with DEC's eeprom. I get accent to a command line, I do not have to make changes to the settings, I can automate things a lot easier. For instance on a SPARC, in order to netboot, all i need to type is "boot net", on a PC's I need to select "Network" option in the BIOS, and then I have to disable network boot upon the next reboot.

GUIs also have the disadvantage of requiring a human to work with them, while with a command-line I can have a script handle it (for the bios case, i can have the script write to the serial port when booting the SPARC machine over serial console. Perhaps GUIs make it easier for the newbie, but they often make it impossible for the expert.

[T]he strongest man in the world is he who stands most alone. - Henrik Ibsen.
Even experts don't know everything :) (none / 0) (#72)
by dgwatson on Mon Jul 09, 2001 at 03:47:54 PM EST

I think that even experts want GUIs for some things - mainly things which aren't done very often. The BIOS example you gave - it happens that the option you wanted was very intuitive. But suppose you didn't know what the proper option was. Which would be faster? Using a GUI, or looking it up in the docs? Of course the GUI is faster.

One very BAD command-line-only BIOS is the OpenFirmware they have on Macs - the commands are totally cryptic, and just a pain in general. If they gave you the option to use a nice GUI, it would help things out tremendously, but for some reason that was neglected, leading to an almost unusable interface.

I think that for most things the GUI is sufficient, but there should always be the option to do things by command-line. This way the experts are happy, and those who don't need additional options are oblivious. Just as long as the command-line is usable. :)

[ Parent ]
resolution (none / 0) (#73)
by strlen on Mon Jul 09, 2001 at 06:43:42 PM EST

ok.. then a good way to be have the command line display "type GUI to enter the graphical mode". sun's BIOS is very nice, it even includes its own documentation available straight from the bios. command line perhaps should serve as a primary interface, and a GUI should be only a front-end to such.

[T]he strongest man in the world is he who stands most alone. - Henrik Ibsen.
[ Parent ]
Oh, come on with the "intuitive" already (5.00 / 2) (#70)
by ksandstr on Mon Jul 09, 2001 at 08:49:29 AM EST

Nearly-quoting someone whose name I can't remember: ``The only intuitive interface is the nipple. After that, it's all learned.''.

The battle of the experts and the newbies | 81 comments (77 topical, 4 editorial, 0 hidden)
Display: Sort:


All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!