I downloaded the .pdf version of "Thinking in C++" and I've begun to read that and I did yum groupinstall 'Development Tools' I'm a Newbie Desktop user, jumping into the deep end of the pool. Should I try to learn vi (Vim) (which obviously will help me, if I ever need to administer a remote box) or install Emacs or something else, for the gcc editor? An easy learning curve is strongly preferred, but, I am 100% aware of the advantages of vi. Recommendations? TIA!
On Sun, 10 Aug 2008 17:04:16 -0500 Lanny Marcus lmmailinglists@gmail.com wrote:
Should I try to learn vi (Vim) (which obviously will help me, if I ever need to administer a remote box) or install Emacs or something else, for the gcc editor?
That's the sort of question where, if you ask ten people for their opinion, you will get sixteen different answers. At least.
I personally use either vi or nedit, depending on what the current environment is and what I'm trying to accomplish.
On Sun, Aug 10, 2008 at 3:11 PM, Frank Cox theatre@sasktel.net wrote:
On Sun, 10 Aug 2008 17:04:16 -0500 Lanny Marcus lmmailinglists@gmail.com wrote:
Should I try to learn vi (Vim) (which obviously will help me, if I ever need to administer a remote box) or install Emacs or something else, for the gcc editor?
That's the sort of question where, if you ask ten people for their opinion, you will get sixteen different answers. At least.
I personally use either vi or nedit, depending on what the current environment is and what I'm trying to accomplish.
OK, I'm the second of the sixteen answers. I use vi and elvis (GUI editor 100% compatible with vi). I highly recommend you learn vi. You will never regret :-D
Akemi
On Sun, 2008-08-10 at 15:40 -0700, Akemi Yagi wrote:
On Sun, Aug 10, 2008 at 3:11 PM, Frank Cox theatre@sasktel.net wrote:
On Sun, 10 Aug 2008 17:04:16 -0500 Lanny Marcus lmmailinglists@gmail.com wrote:
Should I try to learn vi (Vim) (which obviously will help me, if I ever need to administer a remote box) or install Emacs or something else, for the gcc editor?
These two usually result in religious wars. Emacs is *very* powerful and customizable and extensible. Probably makes the learning curve longer. But it already has definitions for several languages. Vim also has some.
I never used emacs much as I already had a "cake walk" into vi (now vim) because it uses a lot of what you find in regex, which I was intimately familiar with, from heavy "ed" usage before vim was a gleam in someone's eye.
If you already have some familiarity with regex (grep, sed, et al), you'll probably find vim faster to learn.
Then I would suggest that. Otherwise, take a quick browse of the man pages for both, pick one or the other and use it (almost) exclusively. You'll quickly become competent if you use it a lot and take brief reads of succeeding sections in the man pages or tutorials.
<snip>
On Sun, Aug 10, 2008 at 6:43 PM, William L. Maltby CentOS4Bill@triad.rr.com wrote:
On Sun, 2008-08-10 at 15:40 -0700, Akemi Yagi wrote:
On Sun, Aug 10, 2008 at 3:11 PM, Frank Cox theatre@sasktel.net wrote:
On Sun, 10 Aug 2008 17:04:16 -0500 Lanny Marcus lmmailinglists@gmail.com wrote:
Should I try to learn vi (Vim) (which obviously will help me, if I ever need to administer a remote box) or install Emacs or something else, for the gcc editor?
These two usually result in religious wars. Emacs is *very* powerful and customizable and extensible. Probably makes the learning curve longer. But it already has definitions for several languages. Vim also has some.
Bill: I am going to have a *huge* learning curve with C++, so I am going to go with vi (vim) or something *very* close to it and avoid the long learning curve of Emacs. Emacs is a completely different breed. Apples to Oranges.
I never used emacs much as I already had a "cake walk" into vi (now vim) because it uses a lot of what you find in regex, which I was intimately familiar with, from heavy "ed" usage before vim was a gleam in someone's eye.
I used an Intel editor, years ago, that probably was something like vim. Prefer not to need to memorize, but if I use it often enough, I will learn it and be able to use it.
If you already have some familiarity with regex (grep, sed, et al), you'll probably find vim faster to learn.
No experience with those.
Then I would suggest that. Otherwise, take a quick browse of the man pages for both, pick one or the other and use it (almost) exclusively. You'll quickly become competent if you use it a lot and take brief reads of succeeding sections in the man pages or tutorials.
Vi or vim. I think Emacs would just cloud my mind, when I'm trying to absorb C++ Lanny
On Mon, 2008-08-11 at 11:04 -0500, Lanny Marcus wrote:
<snip>
Vi or vim. I think Emacs would just cloud my mind, when I'm trying to absorb C++ Lanny
If you have C experience, it'll be quick once you get your head around constructors, destructors, inheritance, templates (I never did enough of that to get it), et al.
It essentially implements a bunch of things we used to do as functions, libraries or modules when we recognized a strong re-usability potential, and formalizes all that to the object oriented model.
Good luck on it and I know you'll enjoy it once you see results.
<snip sig stuff>
On Mon, Aug 11, 2008 at 11:38 AM, William L. Maltby CentOS4Bill@triad.rr.com wrote:
On Mon, 2008-08-11 at 11:04 -0500, Lanny Marcus wrote:
<snip>
Vi or vim. I think Emacs would just cloud my mind, when I'm trying to absorb C++ Lanny
If you have C experience, it'll be quick once you get your head around constructors, destructors, inheritance, templates (I never did enough of that to get it), et al.
It essentially implements a bunch of things we used to do as functions, libraries or modules when we recognized a strong re-usability potential, and formalizes all that to the object oriented model.
Good luck on it and I know you'll enjoy it once you see results.
Thanks! Not much C experience. I'm an old Assembly Language guy. Trying to enter the 21st century now. C++ is a lot to learn and it looks like a lot of it has to do with the way things are done in OOP. The book is very long (878 pages) but well regarded.
On Mon, 2008-08-11 at 12:38 -0500, Lanny Marcus wrote:
On Mon, Aug 11, 2008 at 11:38 AM, William L. Maltby CentOS4Bill@triad.rr.com wrote:
On Mon, 2008-08-11 at 11:04 -0500, Lanny Marcus wrote:
<snip>
Vi or vim. I think Emacs would just cloud my mind, when I'm trying to absorb C++ Lanny
<snip>
Thanks! Not much C experience. I'm an old Assembly Language guy. Trying to
Ditto - IBM 360/370. Some things never leave. BALR 14, save area trace register 13, etc. I still love assembly. Speed and efficiency were my big thing.
enter the 21st century now. C++ is a lot to learn and it looks like a lot of it has to do with the way things are done in OOP. The book is very long (878 pages) but well regarded.
Yes, OOP is the whole purpose of C++. When it first came out, I dismissed it as "fluff" (OOP was really new then and initial specs and implementations had not much power). By the time C95 came out, things had started to look more useful. By now (I've not looked in a long time) I'm sure it deserves its highly regarded status.
<snip sig stuff>
Well, don't want to pollute the list further. I'll just say that you should grab some small snippets of a real application to peruse as you go through the book. It will help assimilation (no, not the Borg kind!) immensely.
Enjoy!
On Mon, Aug 11, 2008 at 1:07 PM, William L. Maltby CentOS4Bill@triad.rr.com wrote:
On Mon, 2008-08-11 at 12:38 -0500, Lanny Marcus wrote:
On Mon, Aug 11, 2008 at 11:38 AM, William L. Maltby CentOS4Bill@triad.rr.com wrote: Thanks! Not much C experience. I'm an old Assembly Language guy. Trying to
Ditto - IBM 360/370. Some things never leave. BALR 14, save area trace register 13, etc. I still love assembly. Speed and efficiency were my big thing.
I began with IBM 360/65 ALC on an airline reservation system <snip>
I finished the first chapter of the book. It is excellent. The author obviously worked in industry and knows what it is like, working in the real world.
Yes, OOP is the whole purpose of C++. When it first came out, I dismissed it as "fluff" (OOP was really new then and initial specs and implementations had not much power). By the time C95 came out, things had started to look more useful. By now (I've not looked in a long time) I'm sure it deserves its highly regarded status.
From reading the first chapter, I'm sure that is true. He wrote that
50 to 70% of projects end in failure. OOP should reduce that percentage.
Well, don't want to pollute the list further. I'll just say that you should grab some small snippets of a real application to peruse as you go through the book. It will help assimilation (no, not the Borg kind!) immensely.
I'll ask a former manager/colleague if he happens to have any code from a project he worked on that isn't classified, that he can send me.
On Sun, Aug 10, 2008 at 5:40 PM, Akemi Yagi amyagi@gmail.com wrote:
On Sun, Aug 10, 2008 at 3:11 PM, Frank Cox theatre@sasktel.net wrote:
On Sun, 10 Aug 2008 17:04:16 -0500 Lanny Marcus lmmailinglists@gmail.com wrote:
Should I try to learn vi (Vim) (which obviously will help me, if I ever need to administer a remote box) or install Emacs or something else, for the gcc editor?
That's the sort of question where, if you ask ten people for their opinion, you will get sixteen different answers. At least.
I personally use either vi or nedit, depending on what the current environment is and what I'm trying to accomplish.
OK, I'm the second of the sixteen answers. I use vi and elvis (GUI editor 100% compatible with vi). I highly recommend you learn vi. You will never regret :-D
Akemi: I think by the time I finished the question yesterday, I answered my own question. I am going to learn how to use vi (actually, vim). This is the first time I have heard of the elvis editor. As you wrote, I will not regret learning vi and the other editors might not be available in a remote box. Lanny
On Mon, Aug 11, 2008 at 6:40 AM, Akemi Yagi amyagi@gmail.com wrote:
On Sun, Aug 10, 2008 at 3:11 PM, Frank Cox theatre@sasktel.net wrote:
On Sun, 10 Aug 2008 17:04:16 -0500 Lanny Marcus lmmailinglists@gmail.com wrote:
Should I try to learn vi (Vim) (which obviously will help me, if I ever need to administer a remote box) or install Emacs or something else, for the gcc editor?
That's the sort of question where, if you ask ten people for their opinion, you will get sixteen different answers. At least.
I personally use either vi or nedit, depending on what the current environment is and what I'm trying to accomplish.
OK, I'm the second of the sixteen answers. I use vi and elvis (GUI editor 100% compatible with vi). I highly recommend you learn vi. You will never regret :-D
I also recommend you learn vi. There are one reason which is not vi related and I want to point it out here.
People using vi usually work on terminal ... if your are Linux or Win32/MinGW+MSYS user ... you are probably using 'bash'. The 'bash' has a edit mode called vi mode which allow you to edit command history via vi's search command '/' or '?'.
If you are using terminal command a lot ... this feature is your friend. It's a lot of better than using arrow key to fetch back the command history.
So, learn vi ... and you can share the same command when using terminal/bash.
Regards KC
Akemi _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Mon, Aug 11, 2008 at 4:04 PM, Kuang-Chun Cheng kcc1967@gmail.com wrote:
On Mon, Aug 11, 2008 at 6:40 AM, Akemi Yagi amyagi@gmail.com wrote:
On Sun, Aug 10, 2008 at 3:11 PM, Frank Cox theatre@sasktel.net wrote:
On Sun, 10 Aug 2008 17:04:16 -0500 Lanny Marcus lmmailinglists@gmail.com wrote:
Should I try to learn vi (Vim) (which obviously will help me, if I ever need to administer a remote box) or install Emacs or something else, for the gcc editor?
<snip>
I also recommend you learn vi. There are one reason which is not vi related and I want to point it out here.
People using vi usually work on terminal ... if your are Linux or Win32/MinGW+MSYS user ... you are probably using 'bash'. The 'bash' has a edit mode called vi mode which allow you to edit command history via vi's search command '/' or '?'.
If you are using terminal command a lot ... this feature is your friend. It's a lot of better than using arrow key to fetch back the command history.
So, learn vi ... and you can share the same command when using terminal/bash.
Thank you for pointing that out! Yes, bash is the shell.
On Mon, August 11, 2008 19:27, Lanny Marcus wrote:
On Mon, Aug 11, 2008 at 4:04 PM, Kuang-Chun Cheng kcc1967@gmail.com
So, learn vi ... and you can share the same command when using terminal/bash.
Thank you for pointing that out! Yes, bash is the shell.
The GNU readline library, which is where bash gets it's command-line editing, supports both emacs and vi modes, so you can have that commonality either way.
Personally I think the only vi command one needs to know is ":q!".
On Sun, Aug 10, 2008 at 05:04:16PM -0500, Lanny Marcus wrote:
I downloaded the .pdf version of "Thinking in C++" and I've begun to read that and I did yum groupinstall 'Development Tools' I'm a Newbie Desktop user, jumping into the deep end of the pool. Should I try to learn vi (Vim) (which obviously will help me, if I ever need to administer a remote box) or install Emacs or something else, for the gcc editor? An easy learning curve is strongly preferred, but, I am 100% aware of the advantages of vi. Recommendations? TIA!
gvim
There is almost no pain if you stick with gvim (vim). The help is full of helpfull stuff, the mouse works, syntax and keyword aware....
You might also look at Eclipse.
On Sun, Aug 10, 2008 at 6:19 PM, Nifty Cluster Mitch niftycluster@niftyegg.com wrote:
On Sun, Aug 10, 2008 at 05:04:16PM -0500, Lanny Marcus wrote:
I downloaded the .pdf version of "Thinking in C++" and I've begun to read that and I did yum groupinstall 'Development Tools' I'm a Newbie Desktop user, jumping into the deep end of the pool. Should I try to learn vi (Vim) (which obviously will help me, if I ever need to administer a remote box) or install Emacs or something else, for the gcc editor? An easy learning curve is strongly preferred, but, I am 100% aware of the advantages of vi. Recommendations? TIA!
gvim There is almost no pain if you stick with gvim (vim). The help is full of helpfull stuff, the mouse works, syntax and keyword aware....
gvim sounds interesting. Thanks! I tried to install it, but it's not in rpmforge. Is it in another yum repository?
You might also look at Eclipse.
First time I've heard of that one.
Lanny Marcus wrote:
On Sun, Aug 10, 2008 at 6:19 PM, Nifty Cluster Mitch niftycluster@niftyegg.com wrote:
On Sun, Aug 10, 2008 at 05:04:16PM -0500, Lanny Marcus wrote:
I downloaded the .pdf version of "Thinking in C++" and I've begun to read that and I did yum groupinstall 'Development Tools' I'm a Newbie Desktop user, jumping into the deep end of the pool. Should I try to learn vi (Vim) (which obviously will help me, if I ever need to administer a remote box) or install Emacs or something else, for the gcc editor? An easy learning curve is strongly preferred, but, I am 100% aware of the advantages of vi. Recommendations? TIA!
gvim There is almost no pain if you stick with gvim (vim). The help is full of helpfull stuff, the mouse works, syntax and keyword aware....
gvim sounds interesting. Thanks! I tried to install it, but it's not in rpmforge. Is it in another yum repository?
You might also look at Eclipse.
First time I've heard of that one.
Well Eclipse is more of an IDE (Integrated Development Environment) which I think having one that works across multiple languages is essential.
Emacs was the original IDE, but the GUI gives a lot more to the environment, contextual language reference, interface designing, etc. Though Emacs purists will argue that elisp modules exist to provide those, and they probably do, but GUI interface design tools, most likely they do not.
vi is an essential tool to learn though for system administration and quick-n-dirty coding, but to really develop a software system you need an IDE, preferably one that can handle multiple languages, has a GUI designer, language reference tools, and integrates with multiple revision control systems (rcs/cvs, subversion, git).
-Ross
______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof.
On Mon, Aug 11, 2008 at 11:09 AM, Ross S. W. Walker RWalker@medallion.com wrote: <snip>
Well Eclipse is more of an IDE (Integrated Development Environment) which I think having one that works across multiple languages is essential.
Emacs was the original IDE, but the GUI gives a lot more to the environment, contextual language reference, interface designing, etc. Though Emacs purists will argue that elisp modules exist to provide those, and they probably do, but GUI interface design tools, most likely they do not.
vi is an essential tool to learn though for system administration and quick-n-dirty coding, but to really develop a software system you need an IDE, preferably one that can handle multiple languages, has a GUI designer, language reference tools, and integrates with multiple revision control systems (rcs/cvs, subversion, git).
Ross: Thank you, for all of the above. It looks like I need to learn both vi and an IDE, for different tasks. Lanny
Lanny Marcus wrote:
On Sun, Aug 10, 2008 at 6:19 PM, Nifty Cluster Mitch
gvim There is almost no pain if you stick with gvim (vim). The help is full of helpfull stuff, the mouse works, syntax and keyword aware....
gvim sounds interesting. Thanks! I tried to install it, but it's not in rpmforge. Is it in another yum repository?
Yes, in base. It's what you get when you install vim-X11.
"yum provides *gvim*" can tell you things like that.
Cheers,
Ralph
On Mon, Aug 11, 2008 at 11:09 AM, Ralph Angenendt ra+centos@br-online.de wrote:
Lanny Marcus wrote:
On Sun, Aug 10, 2008 at 6:19 PM, Nifty Cluster Mitch
gvim There is almost no pain if you stick with gvim (vim). The help is full of helpfull stuff, the mouse works, syntax and keyword aware....
gvim sounds interesting. Thanks! I tried to install it, but it's not in rpmforge. Is it in another yum repository?
Yes, in base. It's what you get when you install vim-X11.
"yum provides *gvim*" can tell you things like that.
Thanks! I've got it now.
Installed: vim-X11.i386 2:7.0.109-3.el5.3
On Sun, Aug 10, 2008 at 6:19 PM, Nifty Cluster Mitch niftycluster@niftyegg.com wrote:
On Sun, Aug 10, 2008 at 05:04:16PM -0500, Lanny Marcus wrote:
I downloaded the .pdf version of "Thinking in C++" and I've begun to read that and I did yum groupinstall 'Development Tools' I'm a Newbie Desktop user, jumping into the deep end of the pool. Should I try to learn vi (Vim) (which obviously will help me, if I ever need to administer a remote box) or install Emacs or something else, for the gcc editor? An easy learning curve is strongly preferred, but, I am 100% aware of the advantages of vi. Recommendations? TIA!
gvim
There is almost no pain if you stick with gvim (vim). The help is full of helpfull stuff, the mouse works, syntax and keyword aware....
Thank you! gvim is slick. As you wrote, it has lots of help and it will be easy to learn how to use vi, by learning on gvim. Better than holding a cheat sheet or having a book open, trying to figure out what to do, when learning.
Lanny Marcus wrote:
I downloaded the .pdf version of "Thinking in C++" and I've begun to read that and I did yum groupinstall 'Development Tools' I'm a Newbie Desktop user, jumping into the deep end of the pool. Should I try to learn vi (Vim) (which obviously will help me, if I ever need to administer a remote box) or install Emacs or something else, for the gcc editor? An easy learning curve is strongly preferred, but, I am 100% aware of the advantages of vi. Recommendations? TIA! _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Hi,
I suggest to install Eclipse and CDT plugin and you get a full IDE
BR
Vaclav
On Sun, Aug 10, 2008 at 9:07 PM, Vaclav Mocek little.owl@email.cz wrote:
Lanny Marcus wrote:
I downloaded the .pdf version of "Thinking in C++" and I've begun to read that and I did yum groupinstall 'Development Tools' I'm a Newbie Desktop user, jumping into the deep end of the pool. Should I try to learn vi (Vim) (which obviously will help me, if I ever need to administer a remote box) or install Emacs or something else, for the gcc editor? An easy learning curve is strongly preferred, but, I am 100% aware of the advantages of vi. Recommendations? TIA!
<snip>
I suggest to install Eclipse and CDT plugin and you get a full IDE http://www.eclipse.org/cdt/
I will look at Eclipse, but one of my goals is to be able to fix problems on a remote box and that will probably require vi.
on 8-11-2008 9:06 AM Lanny Marcus spake the following:
On Sun, Aug 10, 2008 at 9:07 PM, Vaclav Mocek little.owl-PkL3B3/Gfv0@public.gmane.org wrote:
Lanny Marcus wrote:
I downloaded the .pdf version of "Thinking in C++" and I've begun to read that and I did yum groupinstall 'Development Tools' I'm a Newbie Desktop user, jumping into the deep end of the pool. Should I try to learn vi (Vim) (which obviously will help me, if I ever need to administer a remote box) or install Emacs or something else, for the gcc editor? An easy learning curve is strongly preferred, but, I am 100% aware of the advantages of vi. Recommendations? TIA!
<snip>
I suggest to install Eclipse and CDT plugin and you get a full IDE http://www.eclipse.org/cdt/
I will look at Eclipse, but one of my goals is to be able to fix problems on a remote box and that will probably require vi.
Then you shouldn't go wrong, because I have yet to be on a linux box or a bsd box that didn't have some form or emulation of vi installed.
On Mon, Aug 11, 2008 at 1:30 PM, Scott Silva ssilva@sgvwater.com wrote:
on 8-11-2008 9:06 AM Lanny Marcus spake the following:
<snip>
I will look at Eclipse, but one of my goals is to be able to fix problems on a remote box and that will probably require vi.
Then you shouldn't go wrong, because I have yet to be on a linux box or a bsd box that didn't have some form or emulation of vi installed.
vi is everywhere! But, apparently, I need to learn how to use Emacs or another IDE too, so there's another learning curve.
On Mon, Aug 11, 2008 at 5:20 PM, Lanny Marcus lmmailinglists@gmail.com wrote:
vi is everywhere! But, apparently, I need to learn how to use Emacs or another IDE too, so there's another learning curve.
I've been using vi (and vim and gvim) for more than twenty years and I've never "needed" an IDE. They're helpful in some situations, but if you're programming on a UNIX/Linux platform, vi can be enough. There is even a way to get vi to coordinate with some compilers such that you land on the line where a syntax error occurs, but even that wasn't required.
Vi is not the world's best editor, but it is in every single UNIX or Linux system out there, and there are advantages in knowing how to use it. I've used it long enough that I'm just not interested in other editors. As for IDEs, a great deal of what you need one for can often be accomplished just by having several windows open for the various tasks one needs for debugging.
My $0.02, and it's not available for spending on editor wars. :-)
mhr
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 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 we're stuck with it, which is unfortunate.
Note: I'm not an Emacs fan. :-)
On Tue, 12 Aug 2008 10:48:10 -0700 Florin Andrei florin@andrei.myip.org wrote:
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.
Viewed in the context of the time when it was originally created, it's a work of genius. There's a reason why it became the default text editor on Unix systems.
Frank Cox wrote:
On Tue, 12 Aug 2008 10:48:10 -0700 Florin Andrei florin@andrei.myip.org wrote:
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.
Viewed in the context of the time when it was originally created, it's a work of genius. There's a reason why it became the default text editor on Unix systems.
I don't deny that. Interlaced video, at the time it was invented, was a great idea. Now it's a huge harassment for anyone doing video processing. The steam engine was a huge step forward - a few hundred years ago. And look at it now.
On Tue, 12 Aug 2008 11:25:50 -0700 Florin Andrei florin@andrei.myip.org wrote:
Frank Cox wrote:
On Tue, 12 Aug 2008 10:48:10 -0700 Florin Andrei florin@andrei.myip.org wrote:
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.
Viewed in the context of the time when it was originally created, it's a work of genius. There's a reason why it became the default text editor on Unix systems.
I don't deny that.
You did above. Bill Joy invented vi, by the way. You might want to read about his accomplishments sometime.
Interlaced video, at the time it was invented, was a great idea. Now it's a huge harassment for anyone doing video processing.
Interlaced video is very useful to "extend" the apparent bandwidth of an analog video stream, and that's useful in many applications, both today and tomorrow. Remember, everything doesn't revolve around the television in your living room and the monitor on your desk.
The steam engine was a huge step forward - a few hundred years ago. And look at it now.
In view of the fact that a nuclear reactor is basically a big steam engine, I fail to see your point....
Well, when people start to fail to understand your metaphors (or switch to the uber-literal-minded mode and attack the imperfections in the comparisons you make, instead of debating the original topic), you know it's pointless to continue the discussion. ;-)
But the way this "discussion" evolved is a great illustration for why vi still survives today. If it was a rational decision, it would have died circa 1999.
Alright, time for me to disappear from this thread.
On Tue, Aug 12, 2008 at 03:27:28PM -0400, William L. Maltby wrote:
On Tue, 2008-08-12 at 20:45 +0200, Mihai T. Lazarescu wrote:
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.
I'm afraid that addressing the average needs is a widespread trend today even outside computing. Fortunate us that besides the shells of all-in-one programs we can find and work with those building blocks of the sound, original concepts.
My point was concerning Florin remark that the basic needs for building an efficient UI had changed so much over time.
The only additional UI standard device we have today is the mouse and we see an explosion of *G*UI. However, almost all modern GUI recognize the keyboard command efficiency and provide a range of shortcuts for power users. The best GUI even allow for user-configurable shortcuts and macros.
Through modal operation vi pushed this one step further, shortening the interaction with the keyboard. A host of frequently used commands are one key away once you get your mind set that text entering ends with ESC.
I can agree that shortening the keyboard interaction may not worth that much to many people. But this does not alter the fact that visually searching entries in menus takes a lot more that a keyboard shortcut for the same task. And a shortcut made of keys plus modifiers take longer than the same or less keys with less or no modifiers.
On Tue, Aug 12, 2008 at 12:06:35PM -0700, Florin Andrei wrote:
Well, when people start to fail to understand your metaphors (or switch to the uber-literal-minded mode and attack the imperfections in the comparisons you make, instead of debating the original topic), you know it's pointless to continue the discussion. ;-)
It's up to you to see the points addressing the original topic within the replies.
But the way this "discussion" evolved is a great illustration for why vi still survives today. If it was a rational decision, it would have died circa 1999.
You may also fail to see why the development of mutt started about that time, borrowing "obsoleties" from both vi and mail. I'm afraid this does not make mutt a less rational decision or less usefull program, nor make of its or vim young and quite active developers nostalgics blind to progress. :)
Alright, time for me to disappear from this thread.
Mihai
Florin Andrei wrote:
Frank Cox wrote:
On Tue, 12 Aug 2008 10:48:10 -0700 Florin Andrei florin@andrei.myip.org wrote:
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.
Viewed in the context of the time when it was originally created, it's a work of genius. There's a reason why it became the default text editor on Unix systems.
I don't deny that. Interlaced video, at the time it was invented, was a great idea. Now it's a huge harassment for anyone doing video processing. The steam engine was a huge step forward - a few hundred years ago. And look at it now.
If interlaced video powered by a steam engine works for me, why should I change?
My car is over 10 yrs old & runs fine - don't need a new one. My house was built 45 yrs ago & I like it - don't need a new one. I was born over 50 yrs ago & I don't need . . . well, ok - maybe there's room for improvement. :-)
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 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 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.
Of course I use vim to write this email. :)
Cheers,
Mihai
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>
On Tue, 12 Aug 2008 15:27:28 -0400 "William L. Maltby" CentOS4Bill@triad.rr.com wrote:
Or the stupid MS editor that used to come on DOS?
Edlin was good for automated remote script generation over a serial connection.
(We used to do kiosks with today's weather report and the special at the restaurant down the block (etc.) using fancy batch files and Opus (the Fidonet-compatible BBS ) to do updates.)
Lanny Marcus wrote:
On Mon, Aug 11, 2008 at 1:30 PM, Scott Silva ssilva@sgvwater.com wrote:
on 8-11-2008 9:06 AM Lanny Marcus spake the following:
<snip> >> I will look at Eclipse, but one of my goals is to be able to fix >> problems on a remote box and that will probably require vi. > > Then you shouldn't go wrong, because I have yet to be on a linux box > or a bsd box that didn't have some form or emulation of vi > installed.
vi is everywhere! But, apparently, I need to learn how to use Emacs or another IDE too, so there's another learning curve.
Just remember that you are using *vim* and not *vi* - which is a huge(!) difference. The core features are the same, but vim is so much more versatile than vi. And can be turned into an IDE (of some sorts) for programming.
http://vim.org/ has *lots* of informations, tipps, tricks, code snippets and other stuff.
Ralph
--On Monday, August 11, 2008 7:20 PM -0500 Lanny Marcus lmmailinglists@gmail.com wrote:
Then you shouldn't go wrong, because I have yet to be on a linux box or a bsd box that didn't have some form or emulation of vi installed.
vi is everywhere! But, apparently, I need to learn how to use Emacs or another IDE too, so there's another learning curve.
I agree, learn enough vi that you can deal with a minimal box for recovery situations.
I learned EMACS back when it was written in TECO on a Tops-10 system. I didn't find it particularly hard to master. There's a built-in tutorial system to teach you basic navigation commands (eg. forward/backward character/word/line/page) and the default keystrokes make some sense (eg. ctrl-F is forward char, ESC-F is forward word, substitute B for backward, ctrl-P for previous line, ctrl-N for next line, etc.). Take a half hour to go through the tutorial and you should be pretty comfortable with the basics.
vi derivatives are likely equally easy to master, but I've never been able to figure out the pattern for the keystrokes, so whenever I have to use it, I have to go look up the commands.
These days I use Lugaru Epsilon, a commercial EMACS clone available for several platforms. But I want to get used to the traditional EMACS shipped with most distros.
On Mon, Aug 11, 2008 at 07:20:22PM -0500, Lanny Marcus wrote:
On Mon, Aug 11, 2008 at 1:30 PM, Scott Silva <[1]ssilva@sgvwater.com> wrote:
on 8-11-2008 9:06 AM Lanny Marcus spake the following:
<snip> >> I will look at Eclipse, but one of my goals is to be able to fix problems >> on >> a remote box and that will probably require vi. > > Then you shouldn't go wrong, because I have yet to be on a linux box or a > bsd box that didn't have some form or emulation of vi installed. vi is everywhere! But, apparently, I need to learn how to use Emacs or another IDE too, so there's another learning curve.
A good IDE can help you manage and organize a local project.
Stick with vi/vim/gvim and "make" for a while.
Next add a revision control system (RCS) and patch to your tool kit.
Some class material takes advantage of a specific IDE to manage the various bits in a class. In a 'good' class they begin with small components. Then they begin to reuse those components and build larger projects. If you are working through such a tutorial -- go with the flow and use what ever tool set they do.
Eclipse is nice in that it can run both on Linux and Windows.... For a Java class it is a natural...
Does anyone out there use Eclipse or another IDE with a distributed revision control system like, git, mecurial, cvs, bitkeeper, etc...?
mcedit
"yum install mc" and you can start using it. Can't get more intuitive than that. I use it for PHP and C programming, and shell scripting.
On Mon, Aug 11, 2008 at 3:51 PM, Florin Andrei florin@andrei.myip.org wrote:
mcedit "yum install mc" and you can start using it. Can't get more intuitive than that. I use it for PHP and C programming, and shell scripting.
I think a friend used Midnight Commander, years ago. On Wikipedia, their description explains some interesting capabilities.
On 08/10/08 15:04, Lanny Marcus wrote:
I downloaded the .pdf version of "Thinking in C++" and I've begun to read that and I did yum groupinstall 'Development Tools' I'm a Newbie Desktop user, jumping into the deep end of the pool. Should I try to learn vi (Vim) (which obviously will help me, if I ever need to administer a remote box) or install Emacs or something else, for the gcc editor? An easy learning curve is strongly preferred, but, I am 100% aware of the advantages of vi. Recommendations? TIA!
I'm a Vim user myself, but I noticed one of our engineers using an editor which looked pretty nice. It's called "geany":
Looks like DAG has packaged it:
http://dag.wieers.com/rpm/packages/geany/
On Mon, 2008-08-11 at 18:03 -0700, Tim Utschig wrote:
On 08/10/08 15:04, Lanny Marcus wrote:
I downloaded the .pdf version of "Thinking in C++" and I've begun to read that and I did yum groupinstall 'Development Tools' I'm a Newbie Desktop user, jumping into the deep end of the pool. Should I try to learn vi (Vim) (which obviously will help me, if I ever need to administer a remote box) or install Emacs or something else, for the gcc editor? An easy learning curve is strongly preferred, but, I am 100% aware of the advantages of vi. Recommendations? TIA!
I'm a Vim user myself, but I noticed one of our engineers using an editor which looked pretty nice. It's called "geany":
http://geany.uvena.de/
geany is great; I use it all the time. The only issue I have with it is that it doesn't support gnome-vfs so you can't connect directly to a remote server and edit files there.
-
Akemi Yagi -
David Dyer-Bennet -
Florin Andrei -
Frank Cox -
Ignacio Vazquez-Abrams -
Kenneth Porter -
Kuang-Chun Cheng -
Lanny Marcus -
MHR -
Mihai T. Lazarescu -
Nifty Cluster Mitch -
Ralph Angenendt -
Ross S. W. Walker -
Scott Silva -
Spiro Harvey, Knossos Networks Ltd -
Tim Utschig -
Toby Bluhm -
Vaclav Mocek -
William L. Maltby