John Max Skaller<maxtal@suphys.physics.su.oz.au> writes:

>    Unfortunately, there are some misconceptions about STL.
> One is that is OUGHT to be "user friendly".
>
> -- edited out --
>
>   To make STL into a "user friendly" library is a silly idea.
> Instead, the idea is to use STL to implement a completely separate
> application library.

The idea that a low level library need not be user friendly doesn't
sustain scrutiny. The fact is, since such a library
will be used again & again & again & .... a very small investment
of time in improving the usability of the library will repay
itself thousands of times over. It is crucial that any library
be well designed from the point of view of the library user. So
instead I see ease-of-use as a design goal for any library.

I don't think STL cuts it in this regard. In fact, one of the
major design goals - to use templates with generic algorithms
to reduce code duplication - is of no interest to users. So
STL is very elegant, very object-oriented, but as a library not
very good. Maybe library designers should read Norman's book
"The design of everyday things" as a reminder of what they ought
not to be doing.

Finally, you have to remember that the intended use of STL isn't
necessarily what it will be used for. You might say that DOS or
UNIX need not be user friendly, because end-users will always
be running "friendlier" programs. But in fact both ended up being
used by end-users directly, which led to the "DOS for Idiots"
and "Unix for Idiots" book industry. Wait for "STL for idiots"
because, like it or not, we WILL have to use it without a nice
app. library wrapper, especially in small projects.

William McIlhagga.


[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article <439g17$nlv@engnews2.Eng.Sun.COM>, William McIlhaqqa writes...
>
>The idea that a low level library need not be user friendly doesn't
>sustain scrutiny. The fact is, since such a library
>will be used again & again & again & .... a very small investment
>of time in improving the usability of the library will repay
>itself thousands of times over. It is crucial that any library
>be well designed from the point of view of the library user. So
>instead I see ease-of-use as a design goal for any library.
>

I concur wholeheartedly. Any class library should be designed with
ease-of-use firmly in mind. During heated discussion about reuse, one of
my colleagues stated: "Design for *use*!" This sentiment being that if
someone doesn't use a class in the first place, they are not very likely
to reuse it.

A word that seems to come up more and more regarding class library and
framework design is "approachability". During his tour-de-force with
James Rumbaugh, Grady Booch admitted that his design of the C++ Booch
Components was not approachable--an important lesson for himself and
other object-oriented designers. My experience with the Booch Components
confirms this: they are powerful and elegant with consitency across the
library; once you understand how one container works, you can understand
them all. Unfortunately it requires considerable mental effort to get
your arms around that first container. I encountered resistance getting
other developers to adopt the Booch Components due to the steep learning
curve.

I have not yet witnessed that power and elegance need be sacrificed to
render a class design comprehensible; it just requires a more effort and
usually several iterations.

Also, good documentation doesn't hurt.

-------------------------------
Christopher Thames
World Fusion Software
cthames@worldfusion.com
-------------------------------

[Moderator's note: this discussion was originally on whether or not
the STL was well designed as an easily usable user-level container
class library and on whether that actually was, or should have been,
one of the STL's design goals.  If you follow up to this post, please
make sure that your responses are relevant to the C++ standard.  More
general discussions about designing OO libraries should go to
comp.object instead.  mha.]

---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]