Computer Old Farts Forum
 help / color / mirror / Atom feed
* [COFF] [TUHS] Algol 68 and Unix (was cron and at ...)
       [not found]   ` <20201217143558.GD13268@mcvoy.com>
@ 2020-12-17 15:22     ` clemc
  2020-12-17 15:50       ` [COFF] [SPAM] " lm
  0 siblings, 1 reply; 10+ messages in thread
From: clemc @ 2020-12-17 15:22 UTC (permalink / raw)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4373 bytes --]

Moving to COFF since this is really not UNIX as much as programming
philosophy.

On Thu, Dec 17, 2020 at 9:36 AM Larry McVoy <lm at mcvoy.com> wrote:

> So the C version was easier for me to understand.  But it sort of
> lost something, I didn't really understand Steve's version, not at any
> deep level.  But it made more sense, somehow, than the C version did.
>
 I'm not too hard on Steve as herein lies the dichotomy that we call
programming.   Looking back the BourneGOL macros were clearly convenient
for him as the original author and allow him to express ideas that he had
well in his source.  They helped him to create the original and were
comforting in the way he was used to.   Plus, as Larry notes, the action of
transpiling loses that (BTW -- look some time at comments in the C version
of advent and you can still vestiges of the original Fortran).

But the problem is that when we create a new program, we can easily forget
that it might live forever[1] - particularly if you are a researcher trying
to advance and explore a set of ideas (which of course is what Steve was at
the time).  And as has been noted in many other essays, the true cost of SW
is in the maintenance of it, not the original creation.  So making
something easy to understand, particularly in the future without the
context, starts to become extremely attractive - particularly when it has a
long life and frankly impact beyond what is was originally considered.

It's funny, coming across BourneGOL help to validate/teach/glue into me an
important concept when programming for real -> the idea of "least
astonishment" or "social acceptance" of your work.  Just because you
understand it and like it might not be the same for your sisters and
brothers in the community.  There is no such thing as a private program.
The moment a program leaves your desk/terminal, it will be considered and
analyzed by others.

So back to the time and seeing BourneGOL for the first time, please
consider that in the mid-70s, I was coming to C from BLISS, SAIL, Algol-W
as my HLLs, so I was used to BEGIN/END style programming and bracketing
lining up 4 spaces under the next line with B/E in the same column.   The
White Book did not yet exist, but what would become 'one-true bracing
style' later described in K&R was used in the code base for Fifth and Sixth
Edition.  When I first saw that, it just looked wrong to me. But I was
coming from a different social setting and was using a different set of
social norms to evaluate this new language and the code written in it.

At some point  I took CMU's SW engineering course where we had to swap code
3 different times with other groups for the team projects, and I had come
to realize how important making things be understood by the next team was.
So, I quickly learned to accept K&R style and like Ron and Larry cursed
Steve a little.  And while I admire Steve for his work and both ADB and
Bourne Shell were tools I loved and used daily, when I tried to maintain
them I had wished that Steve had thought about those that would come after
- but I do accept that was not on his radar.

That lesson has served me well for many years as a professional and it's a
lesson I try to teach with my younger engineers in particular.  It's not
about being 100% easy for you now, it is about being easy for someone other
than you that has to understand your code in the future.   Simply use the
social norms of the environment you live and work ("do as the Romans" if
you will).   Even if it is a little harder now, learn the community norms,
and use them.

FWIW:  You can actually date some of my learnings BTW with fsck (where we
did not apply this rule).  Ted and I have come from MTS and
TSS respectively (*i.e.* IBM 360), which you remember from this first few
versions had all errors in UPPER CASE (we kept that style from the IBM
system -- not the traditional UNIX style). For many years after its success
and the program spreading like wildfire within the UNIX community, I would
run it on a system and be reminded of my failure to learn that lesson yet.

Clem

[1] BTW: the corollary to living forever, is that the worst hacks you do
seem to be the ones that live the longest.


ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20201217/cb9a76ee/attachment.htm>


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [COFF] [SPAM] Re: [TUHS] Algol 68 and Unix (was cron and at ...)
  2020-12-17 15:22     ` [COFF] [TUHS] Algol 68 and Unix (was cron and at ...) clemc
@ 2020-12-17 15:50       ` lm
  2020-12-17 17:57         ` imp
  0 siblings, 1 reply; 10+ messages in thread
From: lm @ 2020-12-17 15:50 UTC (permalink / raw)


I feel like I could have written everything that Clem said (except for the
BLISS, SAIL, Algol-W parts, I didn't experience that).  But the sentiment
contained in this email is pretty much exactly how I think.  I really feel
like Clem and I were separated at birth or something :-)

I told my people that it doesn't matter who wrote it 6 months from now,
even if it was you, you are going to have to relearn the code to fix a
bug in it.  So make it easy on yourself, and everyone else, don't be
clever unless it is absolutely necessary.  All of my core team were
dramatically smarter than me and I think that made me even more important.
Having me around, and leading, meant that the code had to be simple 
enough that I understood it (there were some exceptions).  Which meant
we could support it.  We usually knew what the bug was within a couple
of minutes after the bug report came in.  Not always but an astoundingly
high percentage of the time.  That wouldn't be true if I had let every
"clever" hunk of code in.  That shit adds up.  Dumber is better.

On Thu, Dec 17, 2020 at 10:22:39AM -0500, Clem Cole wrote:
> Moving to COFF since this is really not UNIX as much as programming
> philosophy.
> 
> On Thu, Dec 17, 2020 at 9:36 AM Larry McVoy <lm at mcvoy.com> wrote:
> 
> > So the C version was easier for me to understand.  But it sort of
> > lost something, I didn't really understand Steve's version, not at any
> > deep level.  But it made more sense, somehow, than the C version did.
> >
>  I'm not too hard on Steve as herein lies the dichotomy that we call
> programming.   Looking back the BourneGOL macros were clearly convenient
> for him as the original author and allow him to express ideas that he had
> well in his source.  They helped him to create the original and were
> comforting in the way he was used to.   Plus, as Larry notes, the action of
> transpiling loses that (BTW -- look some time at comments in the C version
> of advent and you can still vestiges of the original Fortran).
> 
> But the problem is that when we create a new program, we can easily forget
> that it might live forever[1] - particularly if you are a researcher trying
> to advance and explore a set of ideas (which of course is what Steve was at
> the time).  And as has been noted in many other essays, the true cost of SW
> is in the maintenance of it, not the original creation.  So making
> something easy to understand, particularly in the future without the
> context, starts to become extremely attractive - particularly when it has a
> long life and frankly impact beyond what is was originally considered.
> 
> It's funny, coming across BourneGOL help to validate/teach/glue into me an
> important concept when programming for real -> the idea of "least
> astonishment" or "social acceptance" of your work.  Just because you
> understand it and like it might not be the same for your sisters and
> brothers in the community.  There is no such thing as a private program.
> The moment a program leaves your desk/terminal, it will be considered and
> analyzed by others.
> 
> So back to the time and seeing BourneGOL for the first time, please
> consider that in the mid-70s, I was coming to C from BLISS, SAIL, Algol-W
> as my HLLs, so I was used to BEGIN/END style programming and bracketing
> lining up 4 spaces under the next line with B/E in the same column.   The
> White Book did not yet exist, but what would become 'one-true bracing
> style' later described in K&R was used in the code base for Fifth and Sixth
> Edition.  When I first saw that, it just looked wrong to me. But I was
> coming from a different social setting and was using a different set of
> social norms to evaluate this new language and the code written in it.
> 
> At some point  I took CMU's SW engineering course where we had to swap code
> 3 different times with other groups for the team projects, and I had come
> to realize how important making things be understood by the next team was.
> So, I quickly learned to accept K&R style and like Ron and Larry cursed
> Steve a little.  And while I admire Steve for his work and both ADB and
> Bourne Shell were tools I loved and used daily, when I tried to maintain
> them I had wished that Steve had thought about those that would come after
> - but I do accept that was not on his radar.
> 
> That lesson has served me well for many years as a professional and it's a
> lesson I try to teach with my younger engineers in particular.  It's not
> about being 100% easy for you now, it is about being easy for someone other
> than you that has to understand your code in the future.   Simply use the
> social norms of the environment you live and work ("do as the Romans" if
> you will).   Even if it is a little harder now, learn the community norms,
> and use them.
> 
> FWIW:  You can actually date some of my learnings BTW with fsck (where we
> did not apply this rule).  Ted and I have come from MTS and
> TSS respectively (*i.e.* IBM 360), which you remember from this first few
> versions had all errors in UPPER CASE (we kept that style from the IBM
> system -- not the traditional UNIX style). For many years after its success
> and the program spreading like wildfire within the UNIX community, I would
> run it on a system and be reminded of my failure to learn that lesson yet.
> 
> Clem
> 
> [1] BTW: the corollary to living forever, is that the worst hacks you do
> seem to be the ones that live the longest.
> 
> 
> ???

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [COFF] [SPAM] Re: [TUHS] Algol 68 and Unix (was cron and at ...)
  2020-12-17 15:50       ` [COFF] [SPAM] " lm
@ 2020-12-17 17:57         ` imp
  2020-12-17 18:00           ` lm
  0 siblings, 1 reply; 10+ messages in thread
From: imp @ 2020-12-17 17:57 UTC (permalink / raw)


On Thu, Dec 17, 2020 at 8:50 AM Larry McVoy <lm at mcvoy.com> wrote:

> I told my people that it doesn't matter who wrote it 6 months from now,
> even if it was you, you are going to have to relearn the code to fix a
> bug in it.
>

This goes double or triple for open source. 6 months from now, the odds are
50/50 the original contributor is busy, unavailable at the moment or
otherwise gone  if it wasn't one of the current top 20 contributors.

Clever is almost always wrong... It's only right if the code is performance
critical and the cleverness gives better performance in a meaningful way.
And even then the bias is against being too clever.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20201217/7996943c/attachment-0001.htm>


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [COFF] [SPAM] Re: [TUHS] Algol 68 and Unix (was cron and at ...)
  2020-12-17 17:57         ` imp
@ 2020-12-17 18:00           ` lm
  2020-12-17 18:30             ` [COFF] " 
  2020-12-17 21:10             ` [COFF] [SPAM] " clemc
  0 siblings, 2 replies; 10+ messages in thread
From: lm @ 2020-12-17 18:00 UTC (permalink / raw)


On Thu, Dec 17, 2020 at 10:57:13AM -0700, Warner Losh wrote:
> On Thu, Dec 17, 2020 at 8:50 AM Larry McVoy <lm at mcvoy.com> wrote:
> 
> > I told my people that it doesn't matter who wrote it 6 months from now,
> > even if it was you, you are going to have to relearn the code to fix a
> > bug in it.
> >
> 
> This goes double or triple for open source. 6 months from now, the odds are
> 50/50 the original contributor is busy, unavailable at the moment or
> otherwise gone  if it wasn't one of the current top 20 contributors.
> 
> Clever is almost always wrong... It's only right if the code is performance
> critical and the cleverness gives better performance in a meaningful way.
> And even then the bias is against being too clever.

Most old guys get it.  But my guys were seasoned and still would try and 
slip stuff in.  

I think it is part of being really smart, it's a puzzle for them and they
"win" if they can do something clever.  I always replied "It is write once,
read many.  Optimize for reads".  It's depressing how much of my job was
pounding that message home year after year.


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [COFF] [TUHS] Algol 68 and Unix (was cron and at ...)
  2020-12-17 18:00           ` lm
@ 2020-12-17 18:30             ` 
  2020-12-17 21:10             ` [COFF] [SPAM] " clemc
  1 sibling, 0 replies; 10+ messages in thread
From:  @ 2020-12-17 18:30 UTC (permalink / raw)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2297 bytes --]

On 17 Dec 2020 10:00 -0800, from lm at mcvoy.com (Larry McVoy):
> Most old guys get it.  But my guys were seasoned and still would try and 
> slip stuff in.  
> 
> I think it is part of being really smart, it's a puzzle for them and they
> "win" if they can do something clever.  I always replied "It is write once,
> read many.  Optimize for reads".  It's depressing how much of my job was
> pounding that message home year after year.

I would rather say to optimize for debugging, which in my experience
happen even more often than (casual) reads. My personal experience is
that most code pretty much just sits there until there's (a) a bug
involving it in some manner, or (b) a new feature that requires
somehow modifying it. When you're trying to figure out why in the
$DEITY $EXPLETIVE $VOLUME the code doesn't do what you think it
should, _any_ amount of "clever" is usually too much.

Yes, it might save a few lines of code somewhere.

Yes, it might be fun to play with a brand new language or compiler or
framework feature.

Yes, every once in a long while there's actually an actual, good
reason to go the "clever" route because it provides some _significant_
advantage. Performance for performance-critical code is one such
example. (I think that so far, professionally, I've written _one_
piece of code where performance was actually critical enough to
warrant getting clever. More often, trying to be clever has just ended
up confusing the compiler.)

But if it takes the next person a week to figure out why the code
doesn't work right when a more direct approach would have made the
error obvious at a glance without any significant downsides other than
that it doesn't use Feature X, then almost every time that's going to
be a really, really, _really_ bad trade-off.

What was that saying again? The person who will need to fix the bugs
in or build upon your code is a sociopathic axe murderer who knows
where you live, so write your code accordingly?

For me, I try quite hard to steer clear of "clever" unless the
cleverness offers some seriously compelling advantage.

And I don't even consider myself particularly old.

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
 “Remember when, on the Internet, nobody cared that you were a dog?”



^ permalink raw reply	[flat|nested] 10+ messages in thread

* [COFF] [SPAM] Re: [TUHS] Algol 68 and Unix (was cron and at ...)
  2020-12-17 18:00           ` lm
  2020-12-17 18:30             ` [COFF] " 
@ 2020-12-17 21:10             ` clemc
  2020-12-18 14:43               ` lm
  1 sibling, 1 reply; 10+ messages in thread
From: clemc @ 2020-12-17 21:10 UTC (permalink / raw)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4484 bytes --]

On Thu, Dec 17, 2020 at 1:00 PM Larry McVoy <lm at mcvoy.com> wrote:

> I think it is part of being really smart, it's a puzzle for them and they
> "win" if they can do something clever.  I always replied "It is write once,
> read many.  Optimize for reads".
>
Amen to that bro.

And at the risk of getting either Jon or Ted (or both probably) I think
that what astonished me when Jon and I were discussing how the Linux FS
stuff got spliced in with so many macros and indirections, frameworks, *et
al*. earlier in the summer (i.e. when Jon was trying to build up his newest
idea); the Linux kernel code for the FS interface was so 'clever' (ney
complex and indirect) that was no longer clear what in the code did what to
either of us (and Jon and I are hardly neophyte C programmers).   As Ted
fairly points out it works and seems to be reasonably fast in practice, and
the Linux kernel team has created test code for some of it all which is far
better than the coding practice in a lot of the rest of the FOSS community
at large. But I suggest that sometimes just because *you can do something,
doesn't mean you should *(tipping my cap to Rob's '*cat -v harmful*'
observation of years gone by).

As a side note, I will say there is another vector to this same curse.
It's the new guy coming into the project and deciding what is there is
crap, they can not understand and they can do a better job.   IMO this is
a problem that is rampant in many FOSS community projects, but I used to
see it at DEC >>all the time<< and still run into it at Intel these days.
Picking on DEC and using Tru64 as an example, it took 3 extra years to get
Tru64 out the door from the original OSF/1 codebase because of it.  Every
major subsystem was rewritten.  Not saying what they got from OSF was
perfect, but DEC could have shipped Tru64 with the original terminal
handler/SCSI/memory/graphics/100% 64-bit clean ... and replaced the code
later with 'better' implementations.

The bottom line for me is that I rather give up a tiny amount of the
absolute speed for long-term scale and maintenance cost (then again it one
of the reasons while I'm a microkernel fan too).  Unless this new
feature/rewrite something that is really going to make or break me, I
rather make what works today, and evolve over time when I have a revenue
stream (*i.e.* OSF/1 was good enough for most of Alpha, but Tru64 was
amazing -- it just took three years].   Plus, as Warner points out, the
original author will be long gone - which only play farther into my
thinking of simple is clear is better in the long run.  No just in FOSS,
again, DEC/Intel, we have people retire or go elsewhere all the time (plus
we get a new set of VPs that reset the corporate direction every 18-24
months).

My basic thinking is you should pick the one or two specific features that
really matter for your product and you need to ensure that its value is
exposed and very much available to the customer.  The rest needs to be simple,
clear, and works, and you're done.  Get on to the next thing.

BTW: this is not just a system SW issue.  I suspect it's more fundamentally
human when people get excited by their own ideas and what they can do and
don't stop to think about the true ramifications of the effort.   One of my
all-time favorite papers is Tom Lyon and Joe Skudlarek's wonderful 1985
tome 'All the Chips That Fit' which bemoans the hardware equivalent of this
same problem [which if you have never read, as a system person you should].

Also, it's also not a computer business only issue.  I have another story,
I'm not sure if I have told here before, which I call the 'Milacron
problem.'  I use it to explain to our younger engineers why creating
something new is not always the right way.    Cincinnati-Milacron is one of
the oldest, largest, and most respected machine tool manufacturers in the
world. My HBS brother ran the robot division and later the machine tool
group at one point.  Milacron can make anything -- period.   That is their
business.   So what happens, ever newly minted Mech E wants to make his own
hydraulic values for their project.  At some point in the 80s, Milacron had
over 5000 different hydraulic values in their internal parts catalog
because no one would take the time to see if one from a previous project
would work.

Clem

ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20201217/c14e6401/attachment.htm>


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [COFF] [SPAM] Re: [TUHS] Algol 68 and Unix (was cron and at ...)
  2020-12-17 21:10             ` [COFF] [SPAM] " clemc
@ 2020-12-18 14:43               ` lm
  2020-12-18 15:46                 ` clemc
  2020-12-18 17:41                 ` tytso
  0 siblings, 2 replies; 10+ messages in thread
From: lm @ 2020-12-18 14:43 UTC (permalink / raw)


On Thu, Dec 17, 2020 at 04:10:03PM -0500, Clem Cole wrote:
> On Thu, Dec 17, 2020 at 1:00 PM Larry McVoy <lm at mcvoy.com> wrote:
> 
> > I think it is part of being really smart, it's a puzzle for them and they
> > "win" if they can do something clever.  I always replied "It is write once,
> > read many.  Optimize for reads".
> >
> Amen to that bro.
> 
> As a side note, I will say there is another vector to this same curse.
> It's the new guy coming into the project and deciding what is there is
> crap, they can not understand and they can do a better job.   

Source management to the rescue.  I hired an extremely smart guy (he
reads papers on string theory, the physics ones, for fun).  Taught him
how to use our tools.  Gave him a bug to fix.  He looks at the source
file and goes "This is crap, I'm gonna rewrite it so it is clean".
Then remembers I showed him how he could see how the file evolved.
So he looks at the first version of the file.  It is *exactly* what he
was going to write.  Huh.  He starts going through the history.  Oh,
this wart is for IRIX.  This wart is for windows 2000 that reuses PIDs
right away.  This wart is for NFS.  Etc.

In the end, he added another wart to fix the bug and left the file alone.
I did say he was smart.


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [COFF] [SPAM] Re: [TUHS] Algol 68 and Unix (was cron and at ...)
  2020-12-18 14:43               ` lm
@ 2020-12-18 15:46                 ` clemc
  2020-12-18 17:41                 ` tytso
  1 sibling, 0 replies; 10+ messages in thread
From: clemc @ 2020-12-18 15:46 UTC (permalink / raw)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1563 bytes --]

Excellent!
ᐧ

On Fri, Dec 18, 2020 at 9:43 AM Larry McVoy <lm at mcvoy.com> wrote:

> On Thu, Dec 17, 2020 at 04:10:03PM -0500, Clem Cole wrote:
> > On Thu, Dec 17, 2020 at 1:00 PM Larry McVoy <lm at mcvoy.com> wrote:
> >
> > > I think it is part of being really smart, it's a puzzle for them and
> they
> > > "win" if they can do something clever.  I always replied "It is write
> once,
> > > read many.  Optimize for reads".
> > >
> > Amen to that bro.
> >
> > As a side note, I will say there is another vector to this same curse.
> > It's the new guy coming into the project and deciding what is there is
> > crap, they can not understand and they can do a better job.
>
> Source management to the rescue.  I hired an extremely smart guy (he
> reads papers on string theory, the physics ones, for fun).  Taught him
> how to use our tools.  Gave him a bug to fix.  He looks at the source
> file and goes "This is crap, I'm gonna rewrite it so it is clean".
> Then remembers I showed him how he could see how the file evolved.
> So he looks at the first version of the file.  It is *exactly* what he
> was going to write.  Huh.  He starts going through the history.  Oh,
> this wart is for IRIX.  This wart is for windows 2000 that reuses PIDs
> right away.  This wart is for NFS.  Etc.
>
> In the end, he added another wart to fix the bug and left the file alone.
> I did say he was smart.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20201218/b2caefed/attachment.htm>


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [COFF] [SPAM] Re: [TUHS] Algol 68 and Unix (was cron and at ...)
  2020-12-18 14:43               ` lm
  2020-12-18 15:46                 ` clemc
@ 2020-12-18 17:41                 ` tytso
  2020-12-18 19:24                   ` [COFF] " lm
  1 sibling, 1 reply; 10+ messages in thread
From: tytso @ 2020-12-18 17:41 UTC (permalink / raw)


On Fri, Dec 18, 2020 at 06:43:32AM -0800, Larry McVoy wrote:
> Source management to the rescue.  I hired an extremely smart guy (he
> reads papers on string theory, the physics ones, for fun).  Taught him
> how to use our tools.  Gave him a bug to fix.  He looks at the source
> file and goes "This is crap, I'm gonna rewrite it so it is clean".
> Then remembers I showed him how he could see how the file evolved.
> So he looks at the first version of the file.  It is *exactly* what he
> was going to write.  Huh.  He starts going through the history.  Oh,
> this wart is for IRIX.  This wart is for windows 2000 that reuses PIDs
> right away.  This wart is for NFS.  Etc.
> 
> In the end, he added another wart to fix the bug and left the file alone.
> I did say he was smart.

....and this is why when I do code reviews, I'm asking for
improvements in the commit (or CL) description at least as much as I
am pointing out issues in the code itself.  In some cases, when the
contributor is someone for whom English is not their first language,
I'll end up rewriting the commit description as well.  Code archeology
is *definitely* a powerful tool, but this relies on the source control
metadata is sufficiently rich; in some cases, having links to bug
trackers or mailing list discussions are super-useful.

	    	    	 	     	 - Ted


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [COFF] [TUHS] Algol 68 and Unix (was cron and at ...)
  2020-12-18 17:41                 ` tytso
@ 2020-12-18 19:24                   ` lm
  0 siblings, 0 replies; 10+ messages in thread
From: lm @ 2020-12-18 19:24 UTC (permalink / raw)


On Fri, Dec 18, 2020 at 12:41:58PM -0500, Theodore Y. Ts'o wrote:
> Code archeology
> is *definitely* a powerful tool, but this relies on the source control
> metadata is sufficiently rich; in some cases, having links to bug
> trackers or mailing list discussions are super-useful.
> 
> 	    	    	 	     	 - Ted

Believe it or not, this is one of my major complaints about Git, it only
has commit comments, there are no per file comments (because there is no
per file meta data other than contents, type, and permissions).

BitKeeper has full per file meta data including comments, user who made
the change, etc.  Which means you can have commits that have more than
one author.

The GUI tool we built for checkins had 3 panes:

	list 
	of
	files
	that
	are
	changed
	--------------
	space
	for
	comments
	-------------
	diffs
	for
	current
	file

The ChangeSet file, which is just another version controlled file that
is the manifest for the repository, its graph is the same graph as Git
has, is always the last file of the list of files, but here is the trick:
the diffs for the ChangeSet file were all the comments you just typed
in.  So what do people do?  On the files, they tended to say what they
did to that file, some bread crumbs specific to that file.  On the 
ChangeSet file, seeing all those comments, they tended "up level" their
comments and provide more of a "what" than a "how".

Intel looked at the quality of the checkin comments done at the command
line vs those done with the GUI tool and mandated the use of GUI tool,
the comments were _that_ much more useful.


^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2020-12-18 19:24 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <CAKH6PiVLgdPVEGvGfyVAwNMz66=0huVyvRY90E+PduwG4ssVRQ@mail.gmail.com>
     [not found] ` <0EA02917-243E-4612-9F7E-D370EE0A7C2E@ronnatalie.com>
     [not found]   ` <20201217143558.GD13268@mcvoy.com>
2020-12-17 15:22     ` [COFF] [TUHS] Algol 68 and Unix (was cron and at ...) clemc
2020-12-17 15:50       ` [COFF] [SPAM] " lm
2020-12-17 17:57         ` imp
2020-12-17 18:00           ` lm
2020-12-17 18:30             ` [COFF] " 
2020-12-17 21:10             ` [COFF] [SPAM] " clemc
2020-12-18 14:43               ` lm
2020-12-18 15:46                 ` clemc
2020-12-18 17:41                 ` tytso
2020-12-18 19:24                   ` [COFF] " lm

Computer Old Farts Forum

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/coff

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 coff coff/ http://inbox.vuxu.org/coff \
		coff@minnie.tuhs.org
	public-inbox-index coff

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.coff


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git