Date: Wed, 10 Nov 2010 09:54:21 -0800 From: Chip Camden <sterling@camdensoftware.com> To: freebsd-questions@freebsd.org Subject: Re: Tips for installing windows and freeBSD both.. anyone?? Message-ID: <20101110175420.GA23184@libertas.local.camdensoftware.com> In-Reply-To: <AANLkTi=KNcjf6bo52=D9ioh7c8Fu%2BTHOzusvEdA_KRt6@mail.gmail.com> References: <201011100009.oAA09mfG024502@mail.r-bonomi.com> <AANLkTi=KNcjf6bo52=D9ioh7c8Fu%2BTHOzusvEdA_KRt6@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoth Rob Farmer on Tuesday, 09 November 2010: > On Tue, Nov 9, 2010 at 16:09, Robert Bonomi <bonomi@mail.r-bonomi.com> wr= ote: > > A GUI provids a =A0_fixed_ set of predefined operations that it is poss= ible to > > perform. > > > > IF your needs are met =3Dentirely=3D by the provided operations, great.= =A0If not, > > you're dead in the water, without any way to accomplish the task. >=20 > How is this different from the command line? If I have a set of data > and want to sort it in a way that "sort" doesn't have an argument for, > I'm just as dead in the water as with the GUI. In fact, with the GUI I > am probably better off because I can see that this is not supported > within the program, without having to use the documentation. I don't know how anyone who has done much automation could say such a thing. Command lines and pipes offer an exponentially greater set of possibilities than could ever be presented in a GUI. I don't know about others, but I spent many years being pro-GUI. I led the charge for getting software companies to port their applications to Windows and use IDEs for development. It is only recently that I have come to my senses. I should have known better. Back in the 80s when I worked on tax preparation software, the marketing department wanted a more demoable UI. So we put a ton of time into creating an interface that looked like the IRS forms, instead of the one we had where the user keyed in a code that indicated what line on what form they wanted to input, followed by the input itself. When we released this, the marketing department loved it, our customers' higher-ups thought it was nice, but the actual input operators hated it. They were evaluated on how much data they could enter, not on their enjoyment of the task. >=20 > > > > GUIs are great for the casual user, because they provide a consistent '= look&feel' > > acrross the spectrum of apps available under them, and, _generally_ wha= t you > > learn =A0from using one application 'generalizes' to any other app that= runs under > > the same GUI. > > > > OTOH, a GUI is the worst thing in the world for 'production' use. =A0It= absolutely > > _kills_ productivity for production tasks. =A0Automation for productivi= ty _REQUIRES_ > > a complete/comprehensive command =A0language. > > > > With a command language, you can 'automate' a series of operations by s= imply > > listing the commands in a file, and feeding that file to the command-pr= ocessor > > input. > > > > With a GUI there is no way to describe the series of mouse 'motions'/'c= licks'/ > > 'double-clicks'/'drags' and keypresses required to perform an operation. > > 'screen coordinates' are meaningless when a window, or icon, or button,= may be > > 'repositioned' at will. > > > > An _individual_ application may allow scripting via an internal command= language, > > but since it is internal to the app, and *not* part of the GUI, it does= n't > > 'generalize' (no guarantee that similar capability is present in any ot= her app) > > *AND* is utterly worthless for 'automating' annything that involves mor= e than > > the single app. >=20 > The CLI doesn't generalize either. How many ways are there to get > input into a program? >=20 > Some can open files on their own and the file is listed as an argument > (app input) > Some have a flag for input, which of course isn't consistent (app -in inp= ut) > Some have multiple flags for input, but which ones work depends on the > platform/implementation (such as GNU long flags) > Some need it provided to stdin > Some can process multiple types of input and are smart enough to > figure it out on their own while others need to be told what format > they are being given > Some can do multiple unrelated things in one instance (file a b) while > others can't (date +"%H" +"%M") > Some have historic idiosyncrasies, such as tar defaulting to a tape drive > Some have other strangeness, like java using aaa.class as input but > wanting you to list it without the .class extension, whilst javac > needs the .java extension > Some are just unusual for no obvious reason, like dd's xx=3Dyy thing > etc. >=20 > On the other hand, 99% of GUI apps that handle files have a File > > Open dialog that is provided via a toolkit and works the same > everywhere. >=20 > > > > Years ago, I worked at a place that, among other things, produced a ref= erence > > manual of statistical data for our cusotmers. =A0About 800 pages of tab= ular data, > > practically all of it updated on a staggered, monthly basis. =A0In the = 'early' > > days (MS-DOS vintage, before 'windows'), =A0each table was kept in a se= parate > > spreadsheet, which _did_ require the redundant entry of a _small_ amoun= t of > > the data. OTOH two (or more) differnt people could be updatdin differen= t paes > > simultaneously, regardless of whether or not they were 'related'. =A0An= d, at > > the end of the week, when it was time to send out the weeks 'updates' t= o the > > customers, =A0we had a simple little '.BAT file, each line of which; (a= ) invoked > > the spreadsheet =A0(b) specified the spreadsheet file to use, and (c) i= nvoked > > a 'start-up macro' that printed the contents of the spreadseet, and exi= ted > > the program. =A0Thus, on 'publication' day it was just type in the name= of the > > '.BAT file and everthing got printed. =A0It took an hour or two -- of _= machine_time_ > > that is, but _zero_ human intervention. > > > > Fast forward a few years, =A0a new-hire analyist (in a senior capacity)= felt > > humiliated at having to use this 'old' technology (they had Windows at = his > > prior employer), and made a big enough stink about it that the shop upg= raded > > to Windows just to keep him happy. He proceeds to bundle all 'his' spre= adsheets > > into a single workbook, so that only one person can be working on any o= f them > > at any given time, and, on 'publication day', somebody had to sit there= and > > click on each relevant/changed =A0sheet in the workbook, click on' file= ', click > > on print, select the page to print, and click 'doit'. =A0 What a *wonde= rful* > > productivity increase!! =A0We've now got a system that requires a -huma= n- to > > play babysitttr the machine. =A0For a couple of -hours- every week. =A0= all to save > > the complainer from having to enter a few numbers redundantly. >=20 > This isn't really a GUI problem, because the issue is the file format > changing such that your .bat no longer worked. If you retained the > original format or fixed the script, it would still work fine. >=20 > However, it still points out one of the biggest problems with the CLI > - there is a barrier to entry in knowing what commands to run with > what arguments to make everything work the way you want. File > Print > was easy for your office staff to figure out. The CLI equivalent > apparently wasn't. Perhaps a barrier to entry is a good thing for those who don't know what they're doing. >=20 > I think many here are underestimating the value of GUIs, because they > have been running many of these traditional UNIX commands for years > (or decades) and are also technically oriented enough that learning > them in the first place wasn't a big deal. >=20 > --=20 > Rob Farmer > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.o= rg" --=20 Sterling (Chip) Camden | sterling@camdensoftware.com | 2048D/3A978E4F http://camdensoftware.com | http://chipstips.com | http://chipsquips= .com --r5Pyd7+fXNt84Ff3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQEcBAEBAgAGBQJM2txKAAoJEIpckszW26+RYokH/RPdYpdkp+lE7jfJRSM8oFLP rnWZ/o2XacnexHRM/timRx7Om4x0wYFemVdDpOahWFUYhzmYMuUs0Ir5uKC0eXDk FLuwwya4B4+8UE5mBk+EzuCTsElJUuuUn5VAeWS+55p5yzS0wlr+XTJ6N8pi4psG QZDGe6j4Ci+KWkjXgIVXK3nGa++A08H6WRBlq1eVRoCAxFKz1VBqoJ00wrPAZ/OJ zTf56UFMYrlV7WkyWGma8w9wy2asBhhK7qQbkszqNl9WYnU7EnfBtTU/aK9gUOy+ HfDZlfGBXCaaTicG3dB2oUbXYvjWbfdDyHJGMxNf9m/8OqLmzLb513t0NtfavHs= =b3uJ -----END PGP SIGNATURE----- --r5Pyd7+fXNt84Ff3--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101110175420.GA23184>