[Eug-lug] Computer time

[John Sechrest]

Jacob Meuser <jakemsr at jakemsr.com> writes:

 % On Sun, Jan 23, 2005 at 03:41:41PM -0800, Allen Brown wrote:

 % > > I don't like emacs because it tries to format my code for me.  I
 % > > condsider that unsupportive, and actually kinda rude.

 % > Like all things, it is configurable.  You can either set the
 % > configuration so that it formats to your style, or you can
 % > turn off formatting.

 % or I can not use programs that I dislike ...

 % seriously, with the wide choice of editors out there, why would I
 % spend time trying to figure out how to do that?


 Editors are tools. You can use the simple easy tools. Or you
 can use the tools that your father used. Or you can use the one that you 
 first learned.....

 or you can learn the tool that lets you get the job done best
 in the long term.

 I have often watched people hold fast to a tool because they like
 it, and yet not spend the time to learn another tool that would
 give them advantage in the long run.

 The reason you would choose to learn emacs is that 
 if it fits how you approach problems, then you can
 make an environment that makes you more effective.

 A macro here, a mode there and pretty soon you can do things
 in half the time, or a tenth of the time that others
 do the same thing. 

 Where you are doing similar things over and over, having a 
 way to automate it is important for the long run:


  System Admin rule:

  Do it once to learn it. 
  Do it the second time to document it.
  Do it the third time to automate it.

  And then stop doing it....

---

 So.. you would choose to learn an editor that was complex because
 it had the ability to give you leverage. Both VI and Emacs
 support automation at one level or another.

 Nano/pico/whatever don't. 

	  

 % > > UNIX _is_ a programming environment, made up of many simple tools,
 % > > doing one thing and doing it well.  that's why there is indent,
 % > > ctags, lint, sed, etc, etc.  knowing how to use those tools
 % > > individually is far more useful than knowing how a particular
 % > > program reimplements them.

 % > I agree.  But one of the things emacs can do is to run make
 % > and parse the editor error messages, putting me onto the
 % > correct line number in the appropriate file to fix each bug.
 % > None of the tools you mention do this.

 This is an example of the automation that I was talking about. 


 % true, but I don't find it troublesome to read the make output and go
 % to the line in the file.

 Then fine. Don't use the tool that gets you leverage. 

 When professional programmers are evaluated for productivity, 
 there is a range of productivity of 50:1. IE, the top programmers
 are 50 times more productive that the worst professional
 programmers. I know of no other profession that has this kind
 of range. 

 Much of that range is a function of tools and attitudes. If
 you want to manage your productivity, then you learn to 
 adapt your tools to be more effective. 

 I have watched people type in and edit lists of names over
 again to make them in the right formate, when if they had
 used emacs/vi and regular expressions, they would have
 been done in 5 minutes. 

 So the reason that you look at tools outside of your current
 tool is to find the places that people are effective and
 to gain some of that efficiency for yourself.

 If you can't want to gain it, fine... But don't be upset when
 others start being more effective...





-----
John Sechrest          .         Helping people use
                        .           computers and the Internet
                          .            more effectively
                             .                      
                                 .       Internet: sechrest at peak.org
                                      .   
                                              . http://www.peak.org/~sechrest