Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/5/84; site umd5.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!seismo!umcp-cs!cvl!umd5!zben From: zben@umd5.UUCP Newsgroups: net.text Subject: Re: Hyphenation, Re: Why Hyphenate Message-ID: <811@umd5.UUCP> Date: Sun, 8-Dec-85 01:54:55 EST Article-I.D.: umd5.811 Posted: Sun Dec 8 01:54:55 1985 Date-Received: Mon, 9-Dec-85 03:25:43 EST References: <471@harvard.ARPA> <773@mmintl.UUCP> <734@tpvax.fluke.UUCP> <731@othervax.UUCP> <803@umd5.UUCP> <733@othervax.UUCP> Reply-To: zben@umd5.UUCP (Ben Cranston) Distribution: net Organization: U of Md, CSC, College Park, Md Lines: 145 Summary: And the bits go on... In article <733@othervax.UUCP> ray@othervax.UUCP (Raymond D. Dunn) responds to my perhaps too-hastily posted flame: >In article <803@umd5.UUCP> zben@umd5.UUCP (Ben Cranston) responds to my >earlier posting: >>> It *IS* by definition possible to implement hyphenation solely by >>> dictionary. If the dictionary is large enough, ... >> "record"... verb "re-cord" noun "rec-rd" ... >To be fair, I missed examples of this type (even if I don't >necessarily agree with your hyphenation of "rec-ord"). >However this does *not* contradict the dictionary argument, in fact >it enhances it. >Assuming a parser was used to determine the part of speech of a word, >no practical hyphenation algorithm could be devised to hyphenate >words accordingly. The dictionary of course *could* easily be >constructed to contain different hyphenation points for different >uses of a word when necessary. All true, and my posting was probably out of line. I just thought the claim "it can be done solely by dictionary" a bit too overly-general to pass without at least a token challenge... >>> WYSIWYG systems (with the associated demise of much of the graphic >>> arts industry) are becoming increasingly practical and popular, from >>> Interleave to the good old "Mac"... >> WYSIWYG systems have their proponents and their uses. They are VERY good >> for novice users, and given the way this field is growing I should think >> that "novice users" are going to be the MAJORITY of users until the entire >> society is computer literate. (This much like "automobile literate" was >> the thing to be when I was a teenager - something 19 year old males can be >> macho about...) >By your definition then, the majority of automobile users are >novices, and always will be. Their literacy does not extend further >than the use of five or six controls. There is no desire in the >majority, nor *need*, to become "automobile literate" in your sense, >the user interface has been designed that way. The same argument >applies to computer systems. I seem to remember a posting from Brian some time ago making an analogy between some task (which escapes me) and the design of carborators. He claimed there were number of people in the country who can actually design such a beast, that it is fraught with black magic, etc. I believe him - I can barely manage a rebuild :-) Now, does this qualify or disqualify me as "automobile literate"? After all, I don't smelt my own silicon either... >> However, there are times when the WYSIWYG paradigm breaks down badly. As >> a somewhat strained analogy, a strict WYSIWYG system might have you use a >> mouse to pick out letters from a menu, rather than using a conventional >> keyboard..... >Not just a strained analogy, totally irrelevant. Its like saying "a >keyboard *might* have just one key which you hit repeatedly until the >character of choice appears, thus any computer system which uses a >keyboard is ...". >We are discussing WYSIWYG systems, and the ability of the general >user to do typesetting, not the pros and cons "of mice over >keyboards" (gosh there's a title for a paper (:-)). WYSIWYG implies >an *approach*, not necessarily a specific user interface. I don't see the two approaches as mutual exclusives, either. A screen with one window on the source script, another window on output document, and real-time updating (:-) would be just dandy. And yes, I am quite aware of the resources such a beast would consume. The 4k by 4k bitmapped terminal wouldn't come cheap either. But, the availability of such a beast could really help with the training of users (more on this later). >OK, so you're trying to make a point on "efficiency". Good, that's >what I'm doing as well. With complex tasks like typesetting, to >reduce this to a measure of keystroke counts is absurd. >The use of a traditional typesetting system requires much dedication >and training, and the ability to visualise the mapping from embedded >commands to the resulting typeset page. (Even with an expert, >several trial runs on the hardcopy typesetter, or to a "soft" screen, >are often required before the desired effect is achieved). >Many people do not, and can never, have this ability, nor should they >be *required* to train themselves for tasks ancilliary to their >mainstream interest. They didn't in the past, they turned to an >"expert" (and paid him big bucks). They shouldn't have to now, they >turn to a computer. Their literacy need only be how to drive the >thing in a natural way to them, not to be able to manipulate the >nuts and bolts. >*That* is efficiency! If people could CHEAPLY answer questions like "what would happen if we decided to use Basketball Oversize instead of Bimbo Stencil for that table on page three" (experimental approach with system described above) it could help a great deal in helping people *develop* such abilities. Of course, your argument is that they should not be *forced* to develop those abilities. I can only claim that *someone* will, because the very high-level ideas of how *I* want to "drive the thing" will have to be somehow translated into the low-level commands to the output device. If that takes an expert and big bucks, OK. If it takes a computer, you will be spending some bucks for that solution too. Isn't your "in a way natural to them" a bit ambitious? It seems to me that here you subsume a lot of the functionality of that "expert" who you are cutting out of the circuit because his "bucks" are too "big". You run the risk of turning people loose with too much freedom and too little guidance. SOMEBODY with SOME amount of graphics art knowlege and experience is going to have to be around. >A last point. Compare this area of expertise with what has happened >in the computerisation of other disciplines (spreadsheets, data >managers, report generators, and the birth of the prime example, >expert systems). Ya know, I'd feel a whole lot better about these expert systems if we knew more about how bad rules would affect system performance. Its just like us dumb old Humans to make conflicting rules and then refuse to acknowlege the conflicts, and then some poor innocent gets really screwed. I think one of the things really wrong with the present scheme of things is that those people who really have the clout to make decisions and change things are hidden away from the world and kept apart from the public by massive burocracies. If you don't know what I mean, try complaining to the lady behind the desk at the airline counter at an airport. Sure, she's hired to be there and talk to you, but you can yell at her until you're blue in the face and it still won't get back to that incompetent manager three levels up the totem pole. And now, not only are they hiding behind people, but you're going to have them hide behind computers too. Not to mention the possibility of some brass hat general promulgating a rule that "airplanes from Cuba are to be nuked without warning" into SDI, and ending up French-frying the last of the Cuban capitalists out... Other disciplines? OK, companies are processing more bits with fewer workers than ever before, and that may well be your idea of success. But when things DO mess up, its a doozy. That recent SNAFU over the wire-transfer switch in New York would have been hilarious except that it had a measurable effect on the national economy... -- Ben Cranston ...{seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben zben@umd2.umd.edu