Date: Fri, 12 Nov 2010 00:16:46 -0700 From: Chad Perrin <perrin@apotheon.com> To: freebsd-questions@freebsd.org Subject: Re: Tips for installing windows and freeBSD both.. anyone?? Message-ID: <20101112071646.GF37058@guilt.hydra> In-Reply-To: <AANLkTi=E7oow_Ej6Fgm6%2BqWJ%2B_Azse4VFsjUoQoKMLv_@mail.gmail.com> References: <201011100009.oAA09mfG024502@mail.r-bonomi.com> <AANLkTi=KNcjf6bo52=D9ioh7c8Fu%2BTHOzusvEdA_KRt6@mail.gmail.com> <20101112011934.GC35128@guilt.hydra> <AANLkTi=E7oow_Ej6Fgm6%2BqWJ%2B_Azse4VFsjUoQoKMLv_@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--E7i4zwmWs5DOuDSH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 11, 2010 at 09:21:51PM -0800, Rob Farmer wrote: >=20 > Well, our info about this situation is limited, so it is hard to say > exactly what happened. This is true, but I think you assumed some things that were not implied by the description of the situation, and that you missed or ignored other parts of the description, and thus leapt to conclusions about why decisions were made when those conclusions were not the most reasonable. >=20 > Switching to a GUI doesn't preclude multiple people working in > parallel, which is why I think the file format or whatever changed > too, and that was really the problem. In this case, it was clearly stated that the guy combined everything into a single "workbook" so that only one person at a time could work on it. No, a GUI in general does not preclude people working on it, but most GUI programs do, especially when everything's tied together in a single document (for some definition of "document") as was done in this case. Thus, the person's desire to use a particular GUI setup resulted in a process that precluded multiple people working on it at the same time. >=20 > My reading of the anecdote was that the batch file was indeed easy to > use, but it no longer worked when the GUI switch was made. Again, that > isn't really a reflection on the GUI, since there are ways to automate > this kind of thing (for Windows, AutoIt was mentioned, plus there are > probably solutions that are more native to the application). Yes, it was easy to use but no longer working when the entire process was changed and file formats were altered for no reason other than to start using a particular piece of software -- and to avoid using anything else. Usually, when someone changes a process for the express purpose of using nothing but the tools for the new process, the tools for the old process are out by definition, regardless of whether they're GUI tools. My point, though, was that your statement that this anecdote somehow proves that CLI tools are difficult to use was totally unsupported by the explanation of what happened. >=20 > I'm not saying the CLI is universally bad - if you gain competence > with a set of programs that you use frequently, it can be very > efficient. It does make it hard to enter a new area, though - you've > got to learn some before you can do anything. That can pay off, if you > keep using that program, but if it is a one-off or occasional thing > (like the svn tagging example earlier in this thread), it's probably > not worthwhile. While you argue that it increases flexibility, which > is true in some ways, it also decreases flexibility by limiting me to > the programs I know or am willing to read documentation for. I never > read documentation for GUI programs - I jump right in and look through > the menus to find what I need or realize the program isn't adequate > and move on. =2E . . or fail to notice that the program might actually be adequate because you did not bother to press F11. It sounds like in some respects we're violently agreeing with each other. On one hand, I think that CLI programs can be great for frequent tasks, especially if you have something like the Unix pipeline at your disposal to automate complex tasks, and that GUIs have some discoverability advantages; on the other hand, you think that GUI programs can be great for cases where someone does not want to take the time to learn a better way to do something, perhaps because he does not perform the tasks very often, but if you do something often enough it might make sense to learn a more efficient CLI-based way to do it. Another difference in our apparent approaches to this is that I think it's a good idea to favor CLI tools when at all reasonable to do so, while you seem to think it's a good idea to favor GUI tools when at all reasonable to do so. We agree on the extremes, but not in the middle, in other words. I just wish that we could agree without it feeling like you're trying to convince people they shouldn't ever bother learning how to use CLI tools unless they absolutely have to. --=20 Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] --E7i4zwmWs5DOuDSH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkzc6d4ACgkQ9mn/Pj01uKVPGwCg4GZgo6THBmpEcWpq7344C6lV jLkAn2g1T5qiEgQPBLk2V0kdMJFMa0tX =4R8N -----END PGP SIGNATURE----- --E7i4zwmWs5DOuDSH--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101112071646.GF37058>