The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: jon@fourwinds.com (Jon Steinhart)
Subject: Running V8 ... [ really basic tools ]
Date: Mon, 16 Oct 2017 12:28:11 -0700	[thread overview]
Message-ID: <201710161928.v9GJSB8Y028111@darkstar.fourwinds.com> (raw)
In-Reply-To: <20171016191640.mqqbf7cp6yfyb6se@matica.foolinux.mooo.com>

Ian Zimmerman writes:
> On 2017-10-16 09:39, Jon Steinhart wrote:
> > 
> > I have a similar and maybe even more extreme position.  When I was a
> > manager I placed restrictions on the tools and customizations for
> > members of my team.  My goal was to make sure that any team member
> > could go over to any other team member's desk and get stuff done.  I
> > strongly pushed vi as an editor because it was "standard"; as Clem
> > said every emacs seemed to be different.  I prohibited the
> > redefinition of the vi key bindings and also any shell aliases that
> > replaced standard commands.  Nothing worse for productivity than going
> > to help out a colleague and then discovering that they the redefined
> > "ls" as "rm"!
> 
> As an Emacs user, obviously I disagree :P
> 
> How many keystrokes are needed to do a given edit with Emacs versus vi,
> and in particular such an artificially frozen version of vi?
> 
> This is not just laziness (though as we know laziness is a virtue in
> programmers).  It's a health issue with RSI.
> 
> And I disagree with restrictions on shell tools as well.  They may
> have made for a uniform predictable environment on one project and one
> job.  But what if an engineer moved on?  Do you really expect him to
> reinvent the wheel all over again everytime?
> 
> As an example of the level of tool I mean: today I decided I had to stop
> using the perl-rename program in my scripts, because different
> distributions install it under different names.  It is very painful to
> do this: there is no such tool in basic Unix.  Of course I can hack my
> own in maybe 10-15 lines of shell code, but that is exactly the kind of
> thing you would prohibit.

Emacs is a lot more "stable" these days; there aren't as many versions
floating around.

No way to answer your question about keystrokes; it really depends on what
you're doing.  I would guess that it's a wash.  Of course, this depends on
your point of view.  I remember a big argument decades ago with Ed Post of
Real Programmers Don't Use Pascal fame.  He was claiming that emacs was
superior because it was "modeless".  Someone else in the car stumped him by
asking the question "Isn't holding down the meta key a mode?"  So vi may
require hitting escape, but emacs is very heavy on the shift key usage so
as I said, it's likely a wash.

I didn't prohibit people from creating their own tools and shortcuts.
I prevented them from using existing utility names for their tools and
shortcuts.  That meant that when they asked someone else in the group
to take a look at a problem that that person could actually do so instead
of causing damage.

And yes, I would prohibit you making a program called perl-rename if it
did something different than perl-rename.  I wouldn't care if it was
identical.  Not sure why you wouldn't set your path to find it wherever
it was or just make a link.

Jon


  reply	other threads:[~2017-10-16 19:28 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-16 11:58 [TUHS} Running V8 Doug McIlroy
2017-10-16 15:41 ` Don Hopkins
2017-10-17 11:47   ` Tony Finch
2017-10-17 14:30     ` Larry McVoy
2017-10-17 14:50     ` Don Hopkins
2017-10-16 16:28 ` Clem Cole
2017-10-16 16:39   ` [TUHS} Running V8 ... [ really basic tools ] Jon Steinhart
2017-10-16 19:16     ` Ian Zimmerman
2017-10-16 19:28       ` Jon Steinhart [this message]
2017-10-17  1:15         ` Ian Zimmerman
2017-10-17  4:20           ` UNIX version 2*pi Don Hopkins
2017-10-17  6:08             ` Dave Horsfall
2017-10-17 18:23               ` Ron Natalie
2017-10-18  2:46                 ` Dave Horsfall
2017-10-18 10:15                   ` Ron Natalie
2017-10-16 16:38 ` [TUHS} Running V8 Will Senn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201710161928.v9GJSB8Y028111@darkstar.fourwinds.com \
    --to=jon@fourwinds.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).