17 Oct
2017
17 Oct
'17
1:16 a.m.
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.
--
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.