🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: net.text
Article #89

Re: Hyphenation, Re: Why Hyphenate

#89
From: zben
Date: Sun, 08 Dec 1985 06:54
145 lines
8447 bytes
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 <small integer> 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
Technical Details
Message-ID: <811@umd5.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!seismo!umcp-cs!cvl!umd5!zben
References: <471@harvard.ARPA> <773@mmintl.UUCP> <734@tpvax.fluke.UUCP> <etc> <731@othervax.UUCP> <803@umd5.UUCP> <733@othervax.UUCP>

Show Full Headers
Complete Article Headers
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: arc1-ca.pugleaf.net!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> <etc> <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...