Thursday, September 13, 2007

Re: [BLUG] C/C++

On Thu, Sep 13, 2007 at 03:05:13PM +0000, Mark Krenz wrote:
> On Thu, Sep 13, 2007 at 02:54:25PM GMT, Michel Salim [msalim@indiana.edu] said the following:
> >
> > Not sure it's a good idea to learn a language, an editor *and* a build
> > system all at once!
> >
>
> As opposed to what? Learning Visual studio? Which is a language an
> editor and a build system? I guess I don't see your point. The
> difference is that if she learns vi or emacs, she can carry those skills
> with her other places.

You can start with any editor. Screen can help a lot. Have one screen
window allocated for a shell to run make and test the program. Have one
screen window allocated to run 'man' on functions. Then have two or more
screen windows allocated for editing files.

This is still frequently the way I prefer to develop. It is easily portable
to any editor. (And I have used several.)

Most build systems are very easy for simple things. GNU Make is actually
less easy than much of the competition, however it is easy for people to
do simple things poorly so people fail to understand how they're misusing
it. (Make is the reason there are so many "make" alternatives.) The big
benefit of knowing a little about it is that it is so commonly available.

GUI develoment environments have been popular since the development of
EMACS (the first IDE). All other IDEs were first attempts at gaining a
subset of the features available in EMACS. If you want a complete IDE,
you may want to learn EMACS.

Please note: Anyone in their right mind will tell you that MS Visual
Studio has some unmatched debugging features. You won't be able to find
anything coming very close to the features, if that is your standard.
Like many applications, while extra features can be nice, they're not
actually needed to get work done. You may be surprised with how many
projects use printf() for debugging.

The more graphical heavy development environments have their place,
certainly, however most people will eventually need to do some remote
debugging, remote development, or remote testing. You will likely need
to become comfortable in an environment with TTY access. You may as
well start now. Even for GUI development, if you manage to properly
seperate your application logic from the GUI interface it can greatly
increase testing options. Command-line tools are more easily automated,
and a seperate library for the application logic allows a variety of
interfaces to be made available -- including text-based interfaces.

Cheers,
Steven Black

_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

No comments: