[TUHS] earliest Unix roff

Jon Steinhart 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 mailing list