[TUHS] earliest Unix roff
jon at fourwinds.com
Tue Sep 17 03:32:15 AEST 2019
Larry McVoy writes:
> On Mon, Sep 16, 2019 at 07:19:05PM +0200, KatolaZ wrote:
> > On Mon, Sep 16, 2019 at 09:45:02AM -0700, Larry McVoy wrote:
> > [cut]
> > >
> > > Those who defend the choice of info over man just aren't real Unix
> > > people. And that's fine, Unix isn't the only choice, they can go
> > > run some other OS and be happy. But it's just rude to thrust info
> > > into a Unix system. And lame because they could have parsed man
> > > pages into info docs and then they are adopting the Unix way of
> > > doing things and actually adding value.
> > Sorry, but I totally don't see the point here.
> Jon put it well, the point is people expect to be able to say
> man foo
> and have that work. Until GNU came along, that's the way it was.
> GNU pushed a different system into the mix.
> The secondary point is they could have *added* to Unix by making a
> man2info command, I know they could have because I've done something
> similar, parsing man or -ms pages is trivial.
> GNU choose not to do that and I can't begin to express how wrong
> that was. GNU is not Unix for sure.
So I'm not really trying to be all that shameless, it's just that I've already
written down my opinions on this sort of stuff and don't need to retype it all.
>From a section entitled "The Value Proposition":
There's an overarching question that you should keep in mind when
working on a project: "Am I adding value?" I'm not talking about
the intrinsic value of accomplishing some task here; I'm talking
about increasing productivity.
If you're programming for a living, you need to meet whatever goals
your employer has set. But, of course, there's more than one way
to meet those goals. You could just do what you need to do to get
by. Or, you could put a little thought into things that might not
have occurred to management. For example, you might realize that
your code would be useful in another project and structure it so
it's easily reusable. Or, you might sense that you were tasked to
implement a special case of a more general problem and solve that
general problem instead, paving the way for future enhancements.
Of course, you should talk about this with management so that
they're not surprised.
You can add value to yourself by making sure that you're proficient
in a variety of technologies. Side projects are a common way to
get experience; it's equivalent to doing homework but more fun.
One classic way in which people attempt to add value is by
creating tools. This is trickier than it seems because sometimes
adding value for yourself reduces value for others. People often
create new tools because some feature that they think they need
is missing from existing ones. A good example is the make utility
(invented by Stuart Feldman at Bell Labs in 1976), which is used to
build large software packages. As time went on, new features were
needed. Some of these were added to make, but in many other cases,
people created well-intentioned but incompatible new utilities
that performed similar functions. (For example, I consulted for
a company once that wrote their own solely because they didn't
bother to completely read the make documentation and were unaware
that it would do exactly what they needed.) Now there's make,
cmake, dmake, imake, pick-a-letter-make, and other programs that
all do similar things in incompatible ways. The result is that
practitioners like you need to learn multiple tools in each category.
It makes everyone's life harder, not easier. It doesn't add
value—it detracts. Figure 15-1 sums up the situation nicely.
[ Figure 15-1 is the xkcd how standards proliferate cartoon ]
More information about the TUHS