Re: Re: gcc editor for newbie (Emacs or vim or ?)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On Tue, 2008-08-12 at 20:45 +0200, Mihai T. Lazarescu wrote:
> On Tue, Aug 12, 2008 at 10:48:10AM -0700, Florin Andrei wrote:
> 
> > MHR wrote:
> >>
> >> Vi is not the world's best editor
> >
> > Heh, understatement of the century.
> > It's an awful editor. I wish I could hire the person who came up with  
> > the user interface, only to have the satisfaction of having him/her  
> > fired five minutes later. With no severance package.
> >
> > It's one of the worst designs from a usability perspective. Yes, it's on  

Note: all pejorative terms originally "penned" in this reply have been
expunged in the interests of tolerance of ignorance.

Spoken like a "youngster" who has no knowledge of the history of how we
got where we are now. Vi, based not only on the things that Mihai
mentions below, was made available when memory and CPU was *expensive*
and people who did software development were generally *competent*. The
equipment of the day (ignoring very expensive mainframes, mostly IBM)
upon which UNIX, ed, and the whole *IX foundation was developed, were
along the lines of PDP 11/34 (later 11/70) with *big* (physically) slow
(absolutely) and small (capacity) disks and little memory. CPU power was
no great shakes either. One needed utilities that were very small and
efficient. "C" was relatively new, higher-level languages were too
inefficient and assembly language was still heavily used in many
applications and wherever CPU or memory capacities were of major
concern.

Machine efficiency was paramount and "user interface" was secondary
because of the relative costs and availability of resources - mechanical
and human.

Later (above time was mid '70s), a 16MHz 286 with a 10MB "blinding fast"
60ms average seek (IIRC?) HD and 64KB (*not* a typo, it was KB) of
memory and 12" monitor (monochrome "green" screen) was advertised in the
PC Tech Journal April 1984 (IIRC?) for "only" $10,995.

I never had a problem with the "user" interface - it was a huge advance
over SPF (what we had to use on IBM mainframes on 3270 terminals), IMO.
Of course, the COBOL programmers complained incessantly when I tried to
show them vi.

Anyway, back on track. The adequacy of the user interface really depends
very heavily on the desired goals and the user competence, learning
speed, primary tasks, ... etc. When I drive my Corvette 2 miles each way
to and from work (which I don't, never did) the "solution" doesn't fit
the application. A bike is better, or walking. Any software tools can be
so evaluated. For me, ed was great. Vi was even better. Emacs held no
attraction. For *you*, none of these may be suitable. That doesn't make
vi(m) what you chose to call it.

For all the years I used it, it was fine. Integrated Development
Environments were a nice step, but I still used and preferred vi within
them.

Well, 'nuff of my old fart rant about "youngsters".

> > every Unix system out there. Yes, it's very complex and can be powerful  
> > and can be extended to do a million things. Yes, you can train yourself  
> > so you learn it well enough so that the interface is not a problem 
> > anymore.
> > But all that does not negate the basic fact that it's one of the most  
> > un-intuitive and essentially broken user interface designs ever. But  

I presume you never had to use a context editor like "ed"? Or the stupid
MS editor that used to come on DOS? If so, you could not use the terms
"one of the most un-intuitive and essentially broken...". But, again,
the time these things were developed dictated much of their design.

> > we're stuck with it, which is unfortunate.
> >
> > Note: I'm not an Emacs fan. :-)
> 
> Looking in perspective vi grew up with UNIX.  At times when
> the output device just tilted from printers to CRTs the UNIX
> savvy perceived efficiency mainly in terms of reusing the
> legacy knowledge of ed, ex, and regex as well as resources,
> execution time, and fast and reliable command and display
> time on slow machines and interfaces.  In these regards vi(m)
> simply excelled then as it does today.
> 
> An intuitive interface shortens the learning curve.
> An efficient interface becomes a concern after that. vi came
> to serve in an environment where most were looking simply for
> efficiency, the way they perceived it back then.  And some of
> those rules are still effective today.

I'm afraid most of the really good rules are "broken" today. Best
example is the original credo of UNIX: "Do one thing and do it well".
That was the design philosophy then. Free software development
methodology tends to subvert that. Today, "design towards mediocrity" is
the credo, ecouraging the users and developers to be less competent,
imaginative and requiring less thought.

> 
> Of course I use vim to write this email. :)
> 
> Cheers,
> 
> Mihai
> <snip>

-- 
Bill

_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux