Re: SIL Toolbox and IPA Unicode 1.0

Philippe Caquant wrote:

> --- Amanda Babcock <ababcock@...> wrote:
>
>
>>Somehow it seems like every time I sit down to do
>>some useful conlanging or
>>Athabaskan-studying I spend two hours fighting with
>>my tools instead.  I need
>>better tools.  It's not just Windows; Kura was much
>>the same experience.
>>
>>Sigh.
>
>
> I very much know how you feel. This is the same for
> me, both in my job and at home. For ex, I have loaded
> 25 (TWENTY-FIVE) 'critical updates' for Windows XP
> Home, and I still have problems every time I connect
> to the list with Explorer. I just gave up and decided
> to use only Netscape.
Which isn't a bad idea, but have you ever thought of the complexity
of these things? Most human endevours pale in comparison to the
complexity involved in software. When you give out about the fact
that it's intolerable that software has flaws, you devalue the work
of the people who over the last fifty-odd years have strove to manage
the complexity inherent in software. Software Development can be reduced
to one core discipline: the management of complexity.

> But, as you, say, it's not only Microsoft, it's the general situation about the
> so-called "computer science".
Let's get one thing straight: Computer Science has nothing to do with
computers, despite the name. To quote Dijkstra, a man far smarter than
any of us:

     Computer science is no more about computers
         than astronomy is about telescopes.

> It is simply incredible: in the year 2004, we are still working like in
> stone age.
Yeah, the Internet is a stone-age tool. Google is a stone-age tool. TeX
and Framemaker are stone-age tools. Lisp is a stone-age tool...

> We should have lots of beautiful, handy, reliables, easy-to-use,
> communicating tools at hand.
Your car still break down, doesn't it? Software of the level of
complexity rarely has problems working, yet your car breaks down.

Actually, the galling thing is that you expect a comparatively
young discipline to be able to

> In fact, we're cursing every day the f...ing inventor
> of f...ing 'vi' (Unix) and hundreds of other f...ing
> tools of the same sort.
Then don't use it or write your own fucking one. Shucks, we *are*
talking about Universal Machines here.

> It's really Murphy's laws, every day, at every minute:
> - if there is the slightest possibility that something
> won't work, then it won't work
> - if there is absolutely no reason that something
> won't work, then it won't work neither, and dozens of
> new problems will arise you never dreamt of.
Then you should be surprised that anything in this world works, and
especially surprised that software works anywhere near as well as it
does.

> I think there are people whose job is to ensure that
> the user will never have the needed information at
> hand (this is a science called "ergonomy"). If you
> ever tried to find something in Word or Excel Help,
> you know what I mean: if you don't know exactly where
> to look, you will never get the information, except in
> case you view every help page one by one. The
> information is there, only they will do everything
> possible so that it can't be retrieved by a normal
> user.
But you see, there's enough stuff visible there to get you going.
Ergonomics isn't just about making *everything* accessible: that
would lead to information overload. it's about making things gradually
accessible.

And you know, there's a lot of work put into that kind of thing in
Informatics various subdisciplines. That doesn't mean that people
actually pay attention to any of it: clueless managers who go for
"industry standards", pressured developers who just want to get the
product out there, continuous commercial pressure...

You know, if I didn't have these pesky things called "users" and
"deadlines", I might be able to develop perfect software like I'd
like to, but then life intrudes.

> Language conceptors do the same: they feel an
> irrepressible need that their syntax, even for the
> most basic functions, will be just a little be
> different from the already existing languages (I
> recently discovered that some language, can't remember
> which one, uses a dot to mean "concatenate" !)
That's not uncommon: PHP and Perl do it. You're bitching about nothing
there. Most languages designers attempt to keep things familiar and only
change things if they can't think of any other clean way to do it.

And you're talking about two weakly typed languages. They have their
place. What should they do?

> So
> everything is done to make you lose as much time as
> possible on stupid details, when you are supposed to
> concentrate on functions and algorithms.
Different languages are different notations. It takes me about a week
to become familiar with one, and after that I barely have to think. I
don't consider myself incredibly talented developer (whatever I might
be told :-), so *that* shouldn't be too much trouble to most competent
people. Now, what bugs me is having to relearn a whole new set of APIs:
that's a real pain.

> And the problem is that earlier, you could specialize
> in one environment and be able to use it to write
> complete, well-working applications, with hardly any
> need to look at the doc from time to time. Now, to get
> a message "Hello, world !" on your screen, you have to
> master three dozens of different environments and
> languages, all interfering together, all of them more
> or less severely bugged; you never have the right
> version, you spend hours on the Web, getting viruses,
> spam, ads pop ups and various crap, to get some trick
> from some other unhappy user who might have had the
> same problem.
What are you talking about?

> So: 80% of your time is spoiled trying to master the
> tools and dealing with the bugs, 5% are left for
> creativity and production. That makes 85%. What about
> the remaining 15% ? Oh, just go running naked in the
> rain and yelling mad, in order to try to recover your
> mental balance.
That's life baby: it sucks, so deal with it.

--
Keith Gaughan -- talideon.com
The man who removes a mountain begins by carrying away small stones.

Reply