command line vs gui
in [General Linux]
|
Prev: micro solution backpack cd-writer hell
Next: "...error while loading shared libraries: libg2c.so.0"
From: blmblm on 9 Dec 2005 05:12 In article <87ek4nwmyf.fsf(a)informatik.uni-freiburg.de>, Lee Sau Dan <danlee(a)informatik.uni-freiburg.de> wrote: >>>>>> "blmblm" == blmblm <blmblm(a)myrealbox.com> writes: > > blmblm> If one is a native Chinese speaker who is attempting, as > blmblm> an adult, to learn English, English is difficult. > >I AM a native speaker of Cantonese who learnt English at school and >German as an adult. I don't find English or German difficult. Good for you -- and you do seem to be fluent with written English. (When you say "learnt at school" -- starting when? if early enough, it's not a good experiment in learning languages as an adult.) But my experience has been that many people whose first language is Chinese are not so fluent. Maybe it's just that they're not trying as hard, or maybe there's just more individual variation than either of us had suspected? [ snip ] -- | B. L. Massingill | ObDisclaimer: I don't speak for my employers; they return the favor.
From: blmblm on 9 Dec 2005 05:22 In article <h66m63-lof.ln1(a)news.it.uc3m.es>, Peter T. Breuer <ptb(a)oboe.it.uc3m.es> wrote: >In comp.os.linux.misc Lee Sau Dan <danlee(a)informatik.uni-freiburg.de> wrote: >>>>>>> "Peter" == Peter T Breuer <ptb(a)oboe.it.uc3m.es> writes: [ snip ] >> Peter> just as a billion or so can read and write chinese. > >> But many people find that difficult, too! > >No - they all find it very easy. I studied a little chinese from a >book, and I can tell you it was easy. The classic symbols had nice >visual meanings that I could easily understand without the inconvenience >of having to translate to sounds, and listen to the result in my head. >For example, the word for "trouble" is a picture of two women under one >roof. The word for "love" is a picture of a woman and a child. "child >"looks like a swaddled baby. "Sun" is a stylised circle (a square). >"Moon" is a stylised circle with a dot in it (square with bar). >"Bright" is sun and moon together. "Big" is a man with his arms >stretched wide. "Man" looks like a pair of legs and a trunk. > >All very easy. I leave you to intuit the meaning of the symbol >consisting of a man next to an open doorway. Reviewing your examples .... Once you have the symbol and the meaning, okay, the association can seem plausible. I'm skeptical that if you have only the symbols you can guess the meaning. Why should "two women under one roof" mean "trouble" rather than, say, "polygamy", or "sisterhood", or ....? I don't have a clue what "man next to an open doorway" might mean. Maybe one gets better at guessing meanings with practice, or maybe my brain's just not wired in the way it would need to be for this to be easy. -- | B. L. Massingill | ObDisclaimer: I don't speak for my employers; they return the favor.
From: blmblm on 9 Dec 2005 05:43 In article <3osm63-kcg.ln1(a)news.it.uc3m.es>, Peter T. Breuer <ptb(a)oboe.it.uc3m.es> wrote: >In comp.os.linux.misc Tobias Brox <tobias(a)stud.cs.uit.no> wrote: >> - While Breuer is correct that any boolean expression can be >> normalized, I think he is overlooking that it's actually possible >> to mix _actions_ into the boolean expressions given to find - and >> honestly, I also overlooked that. I think a boolean expression >> with side effects cannot be normalized. Particularly the "prune" >> action is not catered for in the interface below. > >That's true - but then it's an ill-thought out feature of find in the >sense that the extra complexity allowed by embedding various execs at >once in a search expression is not wanted. What they MEANT to do was >apply an action at each of the selected subset of nodes and leaves in >the file hierarchy. > >That's simply a final coup-de-grace on the end of the filter chain. I don't seem to be very good at comprehending your meaning from your written words, but oh well, one more try .... "find" allows me to search a hierarchy for files that match criterion A or criterion B, and apply action AA to the ones that match A and action BB to the ones that match B. As far as I can tell, this is not possible with your proposed GUI. I *think* what you're saying is that it doesn't need to be (possible with your GUI), because no one actually wants to do what I just described, and so the fact that "find" allows it is poor design. True? > >> Ok, load up a monospacefont if you don't already have one, and here we >> go: > >[loadsa work snipped! Wow!] I'll second the "wow!" about the amount of work Tobias put into his explanation .... -- | B. L. Massingill | ObDisclaimer: I don't speak for my employers; they return the favor.
From: blmblm on 9 Dec 2005 05:45 In article <0n8m63-p8n.ln1(a)news.it.uc3m.es>, Peter T. Breuer <ptb(a)oboe.it.uc3m.es> wrote: >In comp.os.linux.misc Lee Sau Dan <danlee(a)informatik.uni-freiburg.de> wrote: >>>>>>> "Peter" == Peter T Breuer <ptb(a)oboe.it.uc3m.es> writes: > >> >> Which two checkboxes? There seem to be three involved/needed. > >> Peter> OK, ok - check A and C on the first panel, then "again", >> Peter> then unclick A and check B instead (maintaining C checked) >> Peter> on the new panel. Then click "finish/search". > >> Have you still not realized that your descriptions have been >> confusing? > >They're not confusing and there is no confusion. The above exchange is >because *I* didn't read what *he* had written as a spec, not the other >way round. Politically correct language-usage quibble: If the "he" of your sentence is me (blmblm(a)myrealbox.com), you have the wrong gender for your pronoun. [ snip ] -- | B. L. Massingill | ObDisclaimer: I don't speak for my employers; they return the favor.
From: blmblm on 9 Dec 2005 05:52
In article <acgm63-f0f.ln1(a)mail.binaryfoundry.ca>, John-Paul Stewart <jpstewart(a)binaryfoundry.ca> wrote: >blmblm(a)myrealbox.com wrote: >> >> That's what I generally assume too, but I vaguely remember hearing >> about a study Apple conducted many years ago that demonstrated that >> people *think* a CLI is faster, but if you do actual measurements of >> how long tasks take, it turns out the point and click is as fast or >> faster. No, I don't (want to) believe it, but it could be true?? > >How complex were the commands being entered? Were the CLI users >proficient typists? I can certainly understand how a point-and-click >GUI is faster than hunt-and-peck typing on the CLI. But if you can type >quickly (using proper technique or otherwise...as long as its fast), I >would expect typing in a command to be a lot faster (especially since >your hands don't have to leave the keyboard). These are all good questions, as are the ones asked by other people who responded to my post. But the question I was asking is whether perhaps this is a case in which what we would expect (that the CLI would be faster) is in fact not true. Sometimes that happens, no? I think I'm just going to have to try a little harder to track down this supposed long-ago Apple study. (I think I had hoped that someone here would say "oh, I remember that!" and supply some details.) My vague recollection is that it was done before Apple committed themselves in such a big way to GUIs, so it might be less biased than people think. Or not. -- | B. L. Massingill | ObDisclaimer: I don't speak for my employers; they return the favor. |