Linux Programmer's Toolbox

Ravi writes "What does it take to start writing programs for Linux? Most people will guess a text editor, knowledge of a programming language, the compiler and libraries of that language. Ask a professional programmer and he will differ with you. Insisting that while those things can help get you started, other things come into play in writing efficient programs such as, a debugger, memory profiler tools and above all a good understanding of the inner working of the Linux kernel and its processes." Read below for the rest of Ravi's review. Linux Programmer's Toolbox author John Fusco pages 622 publisher Prentice Hall rating 9 reviewer Ravi ISBN 0132198576 summary Teaches you the use of tools which help you become a better Linux programmer

The book The Linux Programmer's Toolbox by John Fusco is a storehouse of knowledge, which aims to make the average Linux/Windows programmer aware of the tools at his disposal, that can help him write better programs for Linux. The book is divided into 10 distinct chapters with the first 4 chapters describing various ways of boosting ones productivity while writing code.

In the very first chapter titled "Downloading and Installing Opensource tools", he talks about the different archive formats commonly used in Linux, various package managers such as Debian's own apt-get, Red Hat's Yum and how to properly authenticate the packages you download to ensure that they are not tampered with.

The second chapter deals with building tools from source. Here apart from describing the actual steps involved in compiling the sources, the author also delves into explaining the concept behind the MakeFile, the common variables used in implicit rules and so on. In this chapter one also gets to acquire an understanding of the tools used to create projects as well as examine how these tools work together in the build process.

The book has a chapter exclusively devoted to explaining ways of ambulating through the myriad of documents; tools such as man, info, as well as some of the not so obvious ones. One thing I like about this particular chapter is how the author has provided tables which list a number of recommended manual pages with a short description of each of them.

Linux doesn't have a comprehensive IDE on the lines of Microsoft Visual Studio to develop programs — at least not yet. Most Linux programming gurus are perfectly at home with coding using their favorite text editor. Any book of this stature would be incomplete without a mention of the different editors available for coding in Linux and their pros and cons. The 4th chapter of this book introduces the different editors including Vim and Emacs. There are numerous tips in this chapter to make writing code more efficient, productive and a pleasant experience for the average Linux programmer. As a Vi enthusiast, I couldn't help but admire how one can convert Vim editor to work as a code browser with the help of Ctags which is explained in detail.

The fifth chapter titled "What every developer should know about the kernel" is a turning point in the book and gives a comprehensive understanding of the working of the Linux kernel. It is by far the largest chapter — with nearly 100 pages devoted to this topic. In this chapter the author talks in lucid detail about the different modes in Linux, the process scheduler, device drivers, the I/O scheduler and the memory management in user space, understanding all of which is instrumental in writing better programs for Linux.

The next two chapters deal with Linux processes and the communication between processes. Here one gets to know more about the technical vagaries related to processes such as forking, cloning, process synchronization and the basics of inter process communication. The author has introduced several APIs and basic examples of each.

In the 8th chapter, the author introduces many tools that are installed by default in most Linux distributions which aid in debugging communication between processes. The tools include (but are not limited to) lsof, fuser, stat, hexdump, strace and so on. Each tool is accompanied by its usage and its output with a short discussion of the output.

In the 9th chapter titled "Performance Tuning", one gets to know more about fine tuning a Linux program. Here the author explains the factors affecting system performance as well as the tools for finding system performance issues.

Finally, the last chapter of the book explores some of the most common debugging tools and techniques for Linux. More specifically, I found the discussion on the use of GNU debugger quite informative.

At the end of each of the 10 chapters in the book, the author has provided a short synopsis of the tools that are used. Also many additional online resources have been listed where one can acquire more knowledge about the topic being covered. Throughout the book, noteworthy sections have been highlighted in dark background which makes it quite eye catching and also easy for quick reference.

The book is written with a slant towards the C language especially when depicting the examples in the latter half of the book, which can be understood considering that the bulk of the Linux kernel has been written using C.

Most programmers with a Windows background will be forced to make a paradigm shift while embarking to program for Linux. While the Windows programmers are used to taking deceptive comfort within the cozy confines of a Visual IDE, when they make the shift to write Linux programs, they are suddenly faced with the hard facts of programming as it really is. This book could be an ideal companion for this set of programmers who wish to lessen their learning curve and make programming for Linux a much more pleasurable experience.

I found this book to be an excellent resource for programmers (not necessarily only those with a Windows background) who wish to develop programs for Linux.

Ravi Kumar is a Linux enthusiast who maintains a blog related to Linux, Open Source and Free Software at linuxhelp.blogspot.com.

You can purchase Linux Programmer's Toolbox from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

All of these...

[Mockylock]

And a true hate for Windows OS.

Re:All of these...

[MyLongNickName]

And a bar of soap.

(yeah, right)

Re:All of these...

[gEvil (beta)]

And a bar.

Fixed that for you. ; )

Re:All of these...

[SloWave]

Hate for Windows comes automatically the first time a Windows Programmer sees how bad the wool has been pulled over their eyes when they finally have a chance to do Linux programming.

Re:All of these...

[Yoozer]

I'm honestly not trolling here but could you elaborate on that? (or is it one of those "if you have to ask, give up right now" things? ;) )

Re:All of these...

[MrNormS]

It may not be the case for everyone, but my first programming language was C, and I learned it on Windows. I got along just fine, but found most things much easier when I switched to Gentoo Linux. In retrospect, switching from Windows to Gentoo when I was 15 might have been silly, but I liked the system better and enjoyed understanding how everything works. That's just me. Sorry for the lack of details, but it's just a general thing.

Re:All of these...

[aztracker1]

From a C perspective, I can honestly understand that... I'm more into web development, and an absolute fan of ASP.Net, which is why I actively follow the mono project... I think MS does offer a lot in terms of higher level development tools (VB still being one of the most popular languages out there)... but I can't stand their politics.

Re:All of these...

[jlarocco]

Personally, I find programming under Linux orders of magnitude more enjoyable than under Windows.

First of all, the tools are better. There are compilers, debuggers, IDEs, profilers, memory leak detectors, unit test frameworks, UML modelling programs, documentation generators, parser/compiler generators, GUI designers, version control software, and just about any other tool you can imagine. Those things all exist for Windows too, but they're usually really expensive and don't work together as well as the Linux software.

And the programming APIs are a lot better. Posix is huge, but it's well documented, and it's followed closely enough by all the Unix and Unix-like operating systems. There are differences and incompatibilities, but they're almost always documented.

Then there are perks like the shell and command line tools. The Unix shell and related tools (grep, awk, sed, sort, ...) are incredibly powerful and IMHO unrivaled by anything on Windows. I have to use Windows at work, and almost every day I find myself doing some simple task that takes 3x longer than it should, simply because I don't have a decent shell.

Overall it probably comes down to personal preference and "If you have to ask...", but it's not all machismo.

Re:All of these...

[jsolan]

what about a foo?

Re:All of these...

[spikedvodka]

Then there are perks like the shell and command line tools. The Unix shell and related tools (grep, awk, sed, sort, ...) are incredibly powerful and IMHO unrivaled by anything on Windows. I have to use Windows at work, and almost every day I find myself doing some simple task that takes 3x longer than it should, simply because I don't have a decent shell. Being a *nix person myself, and also being forced to use windows at work. I have found cygwin to be a blessing, it makes my life so much easier, and I can use grep, awk, sed, sort, perl all day long, and it "just works"

Re:All of these...

[peterpi]

Ditto. Cygwin simply makes my job possible. I run it all day, every day and have done for the past six years.

Re:All of these...

[Zarf]

Hate for Windows comes automatically the first time a Windows Programmer sees how bad the wool has been pulled over their eyes when they finally have a chance to do Linux programming. I'm honestly not trolling here but could you elaborate on that? (or is it one of those "if you have to ask, give up right now" things? ;) ) I've erased several pages I had written... who's going to read all that? So, instead a bullet list:

• symbolic links
• The power of pipe: you can pipe output of one program to another...
• STDIN, STDOUT, STDERR are all standard and work well.
• everything is a file means everything is easy to get at...

  $ /dev/video0 > video.mpg

  captures video to your hard drive... c'mon! You gotta admit that's cool! ...that means whatever hardware you are using you just use the file for it.
• free SDK
• free documentation
• Posix is non-stupid
• IPC is multi-process programming made simple
• Whatever your of choice programming language you can write desktop applications that use the window tool kit of your choice.
• you can use Eclipse if you want to... or not...
• If you need to use socket streams networking you can
• Beryl rocks. Flaming windows are cool.

To be fair many Linux programs suck. They suck really really bad. But many are absolutely genius. Some Linux tricks simply can't be done with the same elegance on Windows. And by elegance I mean, fast, secure, and easy to understand and modify. You can write your own PVR in Linux using shell scripts... you can write shell scripts to do anything you want when a USB key is inserted... anything... not just pick from a list of approved actions... anything... think about that.

Depends on the project

[jshriverWVU]

All project's define their project tools.

Need to do web development? Try Zend + PHP
Driver or hardware layer coding? emacs/vi/gas/gcc
Cross-platform application? Java + eclipse

Re:Depends on the project

[Anonymous Coward]

Saying that Java is good because it works on all platforms is like saying that anal sex is good because it works on all sexes.

Re:Depends on the project

[Darktyco]

Driver or hardware layer coding? emacs/vi/gas/gcc I think you meant to say vi/emacs/gas/gcc

/duck

Re:Depends on the project

[OutOnARock]

You say that as if it were a bad thing.

Re:Depends on the project

[Anonymous Coward]

Well, it was designed in San Francisco by a man named Joy...

Re:Depends on the project

[donaldm]

Unfortunately many projects define their tools first without taking the time to understand what is required and achievable in the first place. An interesting balancing act between design by committee and practicality, since "required" may not actually be correct.

Operating Systems, programming languages, compilers, debuggers and even editors are tools to help you achieve your goals and they must not dominate the project in it's planning stages otherwise to quote "forever down the dark path you will go".

Actually what is even worse in the case of software development is coding before an appropriate solution and direction is fully defined. I actually call this the "Shotgun Approach to Programming", granted you may achieve some of your directives but in many cases you are going to have collateral damage which could be quite costly and embarrassing over the long term.

Re:Depends on the project

[brainhum]

I would also recommend any of the newer web frameworks if you're planning on doing any sort of large-scale web development. If you like Python programming, Pylons is my current favourite. If you're a Ruby fan, Ruby-on-Rails is the one to use. PHP for web is not really the 'default' choice anymore, not among the web developers I work with anyway.

Re:Depends on the project

[blueskies]

Funny. Except that most people don't plan on changing platforms when it comes to sex...and if they did they only have to worry about 2 platforms.

A good IDE

[jrwr00]

I wish linux did have a great IDE, but i guess Emacs is good enough :)

Re:A good IDE

[$RANDOMLUSER]

I wish linux did have a great IDE, but i guess Emacs is good enough :)

Great, now all I need is a decent text editor.

Re:A good IDE

[MobyTurbo]

Emacs would make an excellent operating system, if only if it had a good editor.

Re:A good IDE

[uberphear]

Try PyPE or jEdit.

Re:A good IDE

[Crizp]

Spreading the love for jEdit!

Re:A good IDE

[digitig]

Great, now all I need is a decent text editor. Teco? ;-)

Re:A good IDE

[Eideewt]

Emacs comes with viper-mode built in!

Re:A good IDE

[yahurd]

even if youll just compile VI on it :D

Re:A good IDE

[jabjoe]

You tried Codeblocks? Out of the free IDEs I've tried, I think it's the best, and it's crossplatform to boot. It even imports visual studio projects!

Re:A good IDE

[bensch128]

Slickedit, enough said.

Next!
Ben

IDE for Linux, yup

[jshriverWVU]

Linux doesn't have a comprehensive IDE on the lines of Microsoft Visual Studio to develop programs

C/C++ use Qt, kdevelop, or gnomes IDE
Java use Eclipse.

There are several IDE's for programming on a linux system. Also you have to define IDE, if you mean VS like then the previous should suffice. But there are also IDE's like rhide, but that is a bit old school.

Re:IDE for Linux, yup

[darth_linux]

C/C++ use Qt, kdevelop, or gnomes IDE

yeah in the case of a comprehensive look at what coding one can do in Linux, a look at kernel-level tools has its place. I, on the other hand, would rather focus on GUI development (and prefer KDE), so Qt is the way to go.

Re:IDE for Linux, yup

[dvice_null]

> There are several IDE's for programming on a linux system.

Code::Blocks is quite decent for that purpose and I personally use it. With other things, it offers a visual debugger (you can add brake points to the code and then step the code in the code view line by line and see the values of the variables). This is with the latest svn build at least. Haven't tried the stable version. http://www.codeblocks.org/

Re:IDE for Linux, yup

[Constantine XVI]

Eclipse also does Python and C++ via plugins (pydev and eclipse-cdt respectivley)

Re:IDE for Linux, yup

[Compholio]

Java use Eclipse.

Eclipse also does C/C++ if you install the "CDT" (C/C++ Development Tools) plugin.

Re:IDE for Linux, yup

[Doctor Memory]

Likewise, NetBeans does C/C++ and Ruby.

Re:IDE for Linux, yup

[LWATCDR]

Isn't Gnomes IDE called Adjunta?
Yes Eclipse CDT is very useful, I have never used KDevelope but Some people really like it. But giving the Devil his due VS under windows is a good IDE.

Re:IDE for Linux, yup

[j00r0m4nc3r]

I can't believe in this day and age someone would recommend starting with vi/vim. It's such an archaic modality. I'm not saying you can't be productive in vi (I used to be extremely proficient) or shouldn't know how to use it for emergencies, it just makes the entire system seem antiquated and stupid if you tell people that's how to code stuff in Linux. "Here's this crappy text-based editor, and then you can use these other command line tools to compile and then debug your program in text mode. Linux is pretty advanced!"

Re:IDE for Linux, yup

[Gospodin]

Note: for faster performance you should remove all brake points in your release build.

Re:IDE for Linux, yup

[bmk67]

Linux doesn't have a comprehensive IDE UNIX/Linux is a comprehensive IDE.

Re:IDE for Linux, yup

[Anonymous Coward]

And what about Ultimate++ ? ( http://www.ultimatepp.org/ )
It is a C++ cross-platform IDE and GUI
with multiple compiler support, visual designer,
with integrated code analysis and trasformation tools
debugger support integrated in the IDE, etc. etc.
Check the web site to see the Chameleon skinning support
( http://www.ultimatepp.org/www$uppweb$chss$en-us.ht ml )
lots of example applications
( http://www.ultimatepp.org/www$uppweb$examples$en-u s.html )
and full documentation for everything.

Re:IDE for Linux, yup

[howardd21]

Mod Parent MUCH higher-this is absolutely the case!

Re:IDE for Linux, yup

[bvankuik]

Except most programmers don't use a debugger. That makes an IDE less of value. I myself am proficient with both Eclipse/CDT as well as gdb but I have never met a programmer who used debuggers as extensively as myself.

Re:IDE for Linux, yup

[jgrahn]

it just makes the entire system seem antiquated and stupid if you tell people that's how to code stuff in Linux. "Here's this crappy text-based editor, and then you can use these other command line tools to compile and then debug your program in text mode. Linux is pretty advanced!"

IMNSHO, IDEs are overrated monolithic crap which wouldn't even exist if MS-DOS had had multitasking and didn't suck so much (Turbo Pascal and so on ...).

You mean when people ask me, I should lie and say "This neat, flawless program? Oh, I created it using Eclipse 0.1986 and the Blazemonger, C++ Elite Pro and SugarFish plugins. They're awsome! Linux rulez!" when in fact I "just" used emacs, a shell prompt or two and a handful of standard Unix tools?

Re:IDE for Linux, yup

[Trigun]

Maybe they write better code?

Re:IDE for Linux, yup

[insignificant1]

A statement like "[VIM] just makes the entire system seem antiquated and stupid" is foppish and itself ignorant. If text (and keyboard input) is antiquated, then I guess we should all get out of the programming game. Maybe do a little LabVIEW and then commit mass suicide.

In a way, [G]VI[M] and EMACS each represent a club. Clubs of people who took the temporary productivity hit to learn a difficult tool (and possibly put in extra hours to still make the deadline) with some promise of greater productivity in the end.

Is it a false promise? Maybe. There may be a little elitist ego in there, too, but I'd like to think that many who have learned those tools are people willing to put in effort for overall efficiency, and it seems to me to have been beneficial.

Each time I've coded a different "language" (Verilog, C, C++, javascript, Python, Magic VLSI text files, shell, SVG, POV-Ray, bill-of-materials files, SPICE models, config files, etc.) VIM has been there for me, equally handy and powerful. But it didn't look as pretty as Visual Studio, so I guess I shouldn't bother to tell anyone about it. And remember, these are not necessarily tools for a first-time programmer, but for a first-time Linux programmer.

Re:IDE for Linux, yup

[fireboy1919]

I personally use Eclipse for everything except .Net. That's about the only thing it doesn't do - it's truly a comprehensive IDE.

To be more specific, I'm using it to debug Java, Perl, php, ruby, and NSIS (Windows installers). It's also my database front-end (currently used with Oracle, MySQL, and SQL Server), and subversion client (with the best 3-way merging interface I've ever found), and trac (bug management) interface.

I don't use it for any other languages because that's all the ones I really use, but from dabbling I can see that there is pretty good support for python and C++ available for it.

It's almost an operating system in an IDE (kind of like Emacs is...only more graphical, and more focused around programming languages). Everything that languages have in common - mostly in how debugging can be done the same way for all of them.

I can't figure out why this monster isn't considered a universal IDE. Why is it still thought of as Java only?

Re:IDE for Linux, yup

[zakeria]

I would recommend it but then I've been using it for 12 years and its like a twelfth finger! very useful and automatically works!

Re:IDE for Linux, yup

[jma05]

It's Anjuta and KDevelop. Personally, I think CDT is quite at par with Visual C++. I never liked their MFC integration into their IDE after being spoilt on Delphi. But really, what is CDT missing as a modern C++ IDE?

Re:IDE for Linux, yup

[Laser Lou]

I can't believe in this day and age someone would recommend starting with vi/vim. It's such an archaic modality.

I agree with you in general, but on occasions when one must work in a command-line environment, what choice is there?

Re:IDE for Linux, yup

[Trogre]

Curse you, I just typed :q to close this thread in firefox!

True story.

Re:IDE for Linux, yup

[Anonymous Coward]

The older I get the more retro I get.
I like vim. The more you torture yourself
with it the the more you like pain.
Soon you start to feel that other programmers are
weak and pathetic when they complain about their IDE.

Re:IDE for Linux, yup

[PinkPanther]

To be more specific, I'm using it to debug Java, Perl, php, ruby, and NSIS (Windows installers). It's also my database front-end (currently used with Oracle, MySQL, and SQL Server), and subversion client (with the best 3-way merging interface I've ever found),

Off topic, I know, but which plugins are you using for the RDBMSes and for SVN ?

Thanks in advance.

Re:IDE for Linux, yup

[lanswitch]

This must be the dumbest idea i've heard since joining Microsoft.

Re:IDE for Linux, yup

[Hal_Porter]

As someone said to me, if you've never stepped though your code you don't really know what it's doing.

Funnily enough someone else dismissed this idea when I mentioned it to him, but stepping though his code in a Windows build crashed immediately because he messed up a pointer to a pointer dereference. On the embedded target where there was no MMU or debugging facilities it just silently corrupted random memory.

Re:IDE for Linux, yup

[Anonymous Coward]

Maybe, maybe not. I always strive for decent structure and architecture in the stuff i do. Most often that means having one or two 'magic' functions/classes that are pretty complicated, all for the sake of getting the the rest of the system well organized. Most often my customers are quite satisfied with the results. If i dont have a decent debugger i cannot do the hard stuff in the time allocated, it's that simple. Or to put it another way, if all of my code works at the first test without debugging it wasn't worth doing ;)

Re:IDE for Linux, yup

[tartley]

I really disagree that using Vim (or any other advanced, highly refined modern text editor) is a bad thing. It's a far more suitable for editing code than any text editor which is included 'out of the box' with an IDE. There are a thousand things I do to source code on a daily basis using standalone editors like Vim, which one could never do with, say Visual Studio's text editor. Execute an external script or program to manipulate the text-being-edited, for one example. Sorting lines of text. This is entirely in keeping with the UNIX philosophy of giving the user the power to construct an environment that bests suits them, made up from many small but highly specialised and powerful tools, rather than forcing them to do everything within the mediochre confines of one single monolithic application.

Re:IDE for Linux, yup

[Anonymous Coward]

Does it do everything that Understand does? Does it do everything Codesurfer does? How about DMS? CDT and Eclipse sure use large amounts of ram and cpu, but I don't see much payoff in terms of features for all that resource usage.

Re:IDE for Linux, yup

[aevans]

Dummy, try ctrl+x, ctrl+c

Re:IDE for Linux, yup

[LWATCDR]

Refactor.
When I try and Refactor and object I get a message that this feature is not enabled.
Another feature that it lacks is a GUI designer but that I can understand. What GUI tool kit would it support? KDE, GTK, FLTK???
Doesn't matter to me since I am not using it for GUI code.
If I start doing KDE stuff I will use KDevelop.

Re:IDE for Linux, yup

[jma05]

>> Does it do everything that .....?

Does Visual Studio do all that stuff? Of course not. You can always find features for ANY tool that some other tool has. The point of my post is CDT does nearly everything that a VS user expects.

>> Eclipse sure use large amounts of ram and cpu, but I don't see much payoff in terms of features for all that resource usage.

Sigh. Is this even an argument anymore? My 5 year old PC manages CDT just fine. Your PC must really suck.

Re:IDE for Linux, yup

[fireboy1919]

I use subclipse for version control. It's available from the same place you get subversion. :)

The other one is packaged by MyEclipse, for which I pay $50 a year (and well worth not having to worry about the details of plugin solidarity and to contribute to the future advancement of the IDE). I've no idea which packages they've combined to generate their RDBMS, but no doubt that they took it from somewhere.

Re:IDE for Linux, yup

[Drantin]

Look out! It's going straight for your head! Ooh! It just grazed your hair... ...That was a joke based on the misspelling of break.

Blulhsit

[DoofusOfDeath]

"What does it take to start writing programs for Linux? Most people will guess a text editor, knowledge of a programming language, the compiler and libraries of that language. Ask a professional programmer and he will differ with you. Insisting that while those things can help get you started, other things come into play in writing efficient programs such as, a debugger, memory profiler tools and above all a good understanding of the inner working of the Linux kernel and its processes."

You need to know about kernel internals to start writing programs on Linux? Sure - maybe if you start your programming on Linux by writing device drivers.

One out of 20, at most, projects I've done on Linux required anything more than an editor, a compiler, and the "print" statement. It's not that I write simple programs, it's just that in real life these usually end up being sufficient (especially if you program in Python or Java as opposed to C or C++).

Re:Blulhsit

[Anonymous Coward]

"a debugger, memory profiler", all things Linus wouldn't touch with a ten foot pole, if I understand things correctly.

I guess he's got the linux internals part down though.

Re:Blulhsit

[Anonymous Coward]

Blulhsit

How often do your programs actually work?

Re:Blulhsit

[megaditto]

This is not meant as a troll, but from what you said it sounds like you should have saved yourself a lot of time and simply used perl instead of C/C++ or Java.

Re:Blulhsit

[Doctor Memory]

Actually, a decent logging system goes a long way towards making a debugger unnecessary. They're a good tool to have, but if you're spending more time in the debugger than you are writing code, you're doing it wrong.

A profiler, though, should be mandatory. I remember the first time I used one, I was able to improve my code to the extent that over 90% of its run time was spent in the database driver. It's also educational to do things like move loop invariants (which the compiler should do for you) and see how much your code's efficiency improves. Playing around with code and a profiler is pretty much the only way you'll learn what things really improve performance, and which are just folklore.

Re:Blulhsit

[Anonymous Coward]

"You need to know about kernel internals to start writing programs on Linux?"

Yes, you do! The following demonstrates intimate kernel knowledge and comprehension; otherwise, you'd never get the desired results.

#include <stdio.h>
int main(int argc, char *argv[]) {
printf ("Hello World!\n");
return (0);
}

Re:Blulhsit

[bmk67]

Actually, a decent logging system goes a long way towards making a debugger unnecessary. They're a good tool to have, but if you're spending more time in the debugger than you are writing code, you're doing it wrong. I've been developing system applications for close to 25 years now, and I have found that this philosophy serves me well. I rarely use a debugger, I know how, but I have found that good application logs and a working knowledge of the source code allows me to debug code much quicker than a debugger does.

A profiler, though, should be mandatory. I remember the first time I used one, I was able to improve my code to the extent that over 90% of its run time was spent in the database driver. It's also educational to do things like move loop invariants (which the compiler should do for you) and see how much your code's efficiency improves. Playing around with code and a profiler is pretty much the only way you'll learn what things really improve performance, and which are just folklore. You're correct that modern compiler optimizations takes care of most of this. Profilers are useful, though perhaps not as useful as they used to be. I personally have not used one in years, with experience, you come to write fairly optimized code the first time through and the additional time spent profiling and refactoring isn't worth the effort if an experienced coder has done his job right. This is coming from someone who spends most of his time writing I/O intensive applications, not computationally intensive applications, so YMMV of course.

Re:Blulhsit

[jgrahn]

You need to know about kernel internals to start writing programs on Linux? Sure - maybe if you start your programming on Linux by writing device drivers.

That's what I thought, too.

But it is possible that that's just marketing-speak for the kinds of things Stevens covered in Advanced Programming in the UNIX Environment. Concepts like file descriptors, signals, fork(2) and exec*() ... If so, I think it's a good thing that it's in there.

Re:Blulhsit

[SLi]

And a memory debugger? I'm what you would call a professional programmer, and if you ask me if you need a memory debugger to start writing programs, then no, you don't.

Yes, Valgrind is great, and yes, I'd give it to any starter who needs to write something in C. But most programs would be better off written in some other language, like Python or Perl (or if you want or need static typing, I'd recommend something like SML or O'Caml). Or even Java. And I'm glad to claim that a huge portion of recent quality software for high level tasks is written in some language where you don't need the memory debugger, and that's the way it should be for high level programs.

The "instructions" given by the "professional programmer" seem in fact quite harmful to me. They make starting to program seem harder than it is. If you need to develop low level programs, then maybe yes, you need a memory debugger - and only then.

Re:Blulhsit

[BillAtHRST]

I hate to be the one to recommend a MS practice, but one of the tenets that "gurus" in the MS world (McConnell, et al.) have regularly espoused, and that is apparently SOP at MS, is that developers have to step through all new/changed code using the debugger.

IMHO, this is one of the best things you can do. Like other things that are good for you but not much fun, I don't do it nearly as much as I should, but every time I do I am rewarded with insights to improve my code that I would not have gotten otherwise.

In the "old days" this was known as "desk-checking" -- actually stepping through your code on paper, even before compiling. With PC's and IDE's a debugger does the job much better by letting you actually see the results of the assignments and tests in a way that is much easier than using pencil and paper.

Not to mention, debuggers come in pretty handy when you actually have bugs...

P.S. I recently debugged a SEGV bug which happened when an app's "shutdown" function was getting called at odd times -- turns out, library code was calling socket's shutdown function (on a separate thread) and because of linkage problems (the app's shutdown was declared extern "C"), that function was being called instead of the socket libraries'. Good luck finding that with printf...

Give me a good (visual) debugger (e.g., ddd) any day...

Re:Blulhsit

[BillAtHRST]

And while I'm on the subject, I use Eclipse with EPIC to debug Perl code. Again, good luck getting anything close to that level of productivity with "perl -d"...

Re:Blulhsit

[Anonymous Coward]

"I hate to be the one to recommend a MS practice, but one of the tenets that "gurus" in the MS world (McConnell, et al.) have regularly espoused, and that is apparently SOP at MS, is that developers have to step through all new/changed code using the debugger."

Yes. The only point you "forgot" to say is that that's true only due to current generation of code monkeys. For the most part they tend to have a blurred image of what they want to achieve (or are asked to achieve) and an even more blurred image about what they are coding really do. So stepping through the code is mandatory for they to have a more or less real experience about what the code does indeed (no matter what, since they don't really know what they are doing even after the stepping step their code will miserable fail on limit conditions nevertheless but, hey, that's what happens when you send childs to do a man's work).

Re:Blulhsit

[Anonymous Coward]

A good unit testing framework and comprehensive tests and you won't even need the logger much. (Mainly for tracking high level and emergent behaviors, and for debugging field installs.)

Re:Blulhsit

[Doctor Memory]

with experience, you come to write fairly optimized code the first time through and the additional time spent profiling and refactoring isn't worth the effort if an experienced coder has done his job right Quite right, and that's what I was getting at when I mentioned that a profiler allowed you to learn what optimization techniques worked best. Especially once you've gone through that first marathon optimization session, where you need to speed up your code by an order of magnitude or so. You take such things as lazy initialization, prefetching and caching to heart pretty quickly.

GP was spot on, too — profiling and optimization are to be done once your code already works, not during initial development. That allows you to create test cases you can use for regression testing during optimization. And it's surprising how little doing things in a straightforward fashion costs you, performance-wise, most of the time. I pretty much always write simple, easy-to-follow code anymore since (as someone else alluded to) most of my systems' run time gets eaten up in O/R mappers and other abstraction layers. Factor that in with the accrued latency due to remote database servers and web service calls, and the actual improvement you can get from efficient code becomes a pretty small part of the equation. That's why I enjoy the systems architecture part of my job, I have more control over the things that really affect performance nowadays.

Why would anyone want to program in Linux?

[Anonymous Coward]

It's a useless language. PL/1 and BASIC are more powerful.

Re:Why would anyone want to program in Linux?

[jimstapleton]

Is that Lisp Interface for Non-Unix eXtensions?

I've yet to try that one out?

Should I use
Written Interfaces Normalized Definitions On Wacky Systems instead?

or maybe
Freaky but Rational Enhanced Extensible Basic System Development?

how about
Machine Accessibly Control on Occult Systems eXtended?

Win32 dev bad? NOT for Delphi/Kylix & Win32/Li

[Anonymous Coward]

Well, there is Kylix (which is Delphi for Linux)!

Linux RAD/GUI Development

http://72.14.209.104/search?q=cache:A8yKIFPg_HYJ:w ww.uniforum.chi.il.us/slides/linuxGUIdev/LinuxGUID evelopment.ppt+%22Kylix%22+and+%22Qt%22&hl=en&ct=c lnk&cd=7&gl=us

Borland's Kylix allows you to (for the MOST part) easily & nearly instantly, no added work needed really (other than loading the code's text & gui's into the compiler IDE), to rather easily "port" your Win32 designed apps to Linux IF you avoid a few 'Windows specific things' like"

1.) Win32 API calls being used directly in code

2.) Windows registry work (does not exist on Linux afaik, lol)

3.) Some diff.'s/issues in the GUI interface in KDE vs. Windows (but, Kylix does the Qt lib, & Tcp/IP diff.'s that exist between Linux & Windows!)

(There may be more, but that is what I recall now...)

Keep it in mind - sometimes, having done code on Win32 OS is a GOOD THING, for rapid ports of it to Linux using Kylix (Delphi for Linux!)...

APK

My ToolBox

[warrior_s]

one compiler to compile them all : gcc
one debugger to debug them all: gdb
one memory profiler to profile them all: valgrind
and in the darkness bind them : *EMACS*

Re:My ToolBox

[Anonymous Coward]

"*EMACS*"

EMACS? whats that... anything like VI?...

Re:My ToolBox

[bmk67]

Why was the parent modded funny? His toolbox, minus EMACS, plus vim and cscope and some various libraries covers 95% of my needs.

Re:My ToolBox

[Zygamorph]

Shouldn't it be:

and in the darkness bind them : *ld*

Re:My ToolBox

[Xoq jay]

Finally enlightenment!... Shows us the path, gandalf..!

Re:My ToolBox

[trapni]

ok, funny, and I can even agree, but sorry about the last one, this is a matter of choise, and I'm definitely not an emacs-user (but from the other side, and yet still happy ;-)

Re:My ToolBox

[bensch128]

one memory profiler to profile them all: valgrind

Good but when the hell is valgrind going to run on arm?

Until then, us in embedded land are stuck with gprof. (Can oprofile even work properly on arm?)

Ben

Re:My Opinion

[MightyMartian]

Yeah, before ten years ago no one wrote complex programs.

Which ever tool provides the result

[Ngarrang]

"...While the Windows programmers are used to taking deceptive comfort within the cozy confines of a Visual IDE,..."

Deceptive comfort? And here I thought the visual IDE to be just as valid a tool as anything else, that being the one that solves the need of the programmer. Silly me. I guess I need to overdevelop my zealousy in computing.

Re:Which ever tool provides the result

[jimstapleton]

Agreed, those can be *really* nice for setting up your initial GUI, and you can still get under the hood later to make the changes you want if the IDE doesn't have the capabilities to make the GUI do everything you want (which it probably won't)

And, as someone else posted, you can get IDEs in Linux too, with plenty of pretty GUI stuff.

I'm just putting in this reply because I lack the mod points to give you the +1 insightful you deserve. (or at least +1 captain-obvious-that-everone-else-missed)

Re:Which ever tool provides the result

[Chandon Seldon]

And here I thought the visual IDE to be just as valid a tool as anything else, that being the one that solves the need of the programmer.

"Every tool is just as good as every other tool" is just as wrong as "my tool is always better than your tool". I suggest learning phrases like "I can do this faster with the tool I know than I can learn a new tool" and "Visual Studio is a better tool than vi when you're maintaining a form-heavy VB.NET program".

In the general case, I'd argue that Emacs in a *nix environment is the most powerful available toolkit for programming. That being said, the general case isn't what matters when you're doing something specific, and power isn't the only factor that influences people's choice of tools.

Do remember one thing though: It's hard to comment on how powerful a tool set is until you've actually used it seriously - I'd tend to think of this as applying primarily to Windows users who haven't learned *nix, but it applies just as much to me commenting about Visual Studio.

Re:Which ever tool provides the result

[disasm]

If you like IDE's try out openldev (openldev.org). It's written by the author of Foundations of GTK+ Development.

Sam

Re:Which ever tool provides the result

[CodeBuster]

I was thinking along the same lines when I read the phrase, "deceptive comfort" (talk about a loaded phrase) and promised myself that I wouldn't be dragged into the mud for yet another round of debate between the professional corporate programmer and the console cowboy, gcc hacking, linux uber geeks, but unfortunately my will is weak and so here we go again...

It has been my experience that a certain attitude, regarding the utility of more feature rich development tools, exists among Linux programmers which I find difficult to understand. They seem regard anything other than the most minimalist, zen-like, or spartan programming tools as either a complete waste of time or a highly suspect crutch for lesser (i.e. less worthy) programmers than themselves (not a flattering judgment in either case). It is my own opinion that such views are detrimental to the development of Linux as a platform since there are necessarily fewer professional programmers who take a whipping boy approach to their programming tools (i.e. *real* geeks use Emacs or VI and gcc and nothing else).

Visual Studio is less a "deceptive comfort", as the author chooses to put it, and more of a what a modern, productive, and efficient IDE *should* be (although it does fall short of that ideal sometimes). In my opinion, linux would be many times more successful if there were something more directly analogous to Visual Studio (Eclipse is getting there but it still has a ways to go) available for development. The "developer mindshare" among Linux geeks is comparatively low when weighed against, say the Windows platform and Visual Studio and whose fault is that? I leave that one as an exercise for the reader.

Re:Which ever tool provides the result

[__aamnbm3774]

I personally feel more insulted by the second half of that ridiculous sentence:

...when [Windows Developers] make the shift to write Linux programs, they are suddenly faced with the hard facts of programming as it really is.

MADNESS?!?! THIS...IS...PROGRAMMING!!!

Re:Which ever tool provides the result

[bit01]

modern, productive, and efficient IDE *should* be ...

Don't confuse a complex IDE with productivity. They are often not the same.

So called "rich development tools" frequently integrate badly with the rest of the environment and lose any benefits they might have because of it. They also fair badly when the GUI designer doesn't anticipate all possible needs; almost always the case. I find my productivity in a non-integrated environment is much the same as an IDE and often superior due to flexibility, scripting and the like. In other words IDE's often don't provide the benefits they purport to.

The "integration" in IDE is frequently just a marketing buzzword for "we own all the pieces" = "we own you".

---

Don't be a programmer-bureaucrat; someone who substitutes marketing buzzwords and software bloat for verifiable improvements.

Re:Which ever tool provides the result

[TekPolitik]

Visual Studio is less a "deceptive comfort", as the author chooses to put it, and more of a what a modern, productive, and efficient IDE *should* be

Curiously, in my team the developers who work without an IDE are significantly more productive, and produce code of much higher quality, than those who use Visual Studio.

Re:Which ever tool provides the result

[Ngarrang]

Chandon wrote, ""Every tool is just as good as every other tool" is just as wrong as "my tool is always better than your tool""

No, do not add interpretation where none is needed. My statement was, "Which ever tool provides the result." In one situation, a set of tools may work very well. In another situation, a different set of tools may be needed. Visual design tools. Text Editor + Compiler. Whatever. There is no one single tool that can provide all solutions optimally.

Some programmers have no choice with their tools and must use what they are given. Some have a lot of choice. For these programmers, hopefully they will keep an open mind and not be blinded by zealous loyalty to one way for all solutions. The plethora of software for Linux is proof that there are many ways of doing the same thing.

Re:Which ever tool provides the result

[fabs64]

And what of the myriad programmers who've spent years using IDE's and text editors, often starting with IDE's, who still prefer vim+gcc+gdb/ddd when writing C?

Oddly enough, I've always been able to type quicker than I can click around with the mouse.

Re:Which ever tool provides the result

[Moe1975]

between the professional corporate programmer and the console cowboy, gcc hacking, linux uber geeks

Reality shows us that the "console cowboy, gcc hacking, linux uber geeks" have produced, produce, and will continue to produce technologically SUPERIOR software when compared to anything produced by the "professional corporate programmer".

http://www.top500.org/stats/28/osfam/

"the most minimalist, zen-like, or spartan programming tools" are the very tools which have produced that which is more powerful than anything that CAN be produced with Visual Studio. See above link.

The "developer mindshare" among Linux geeks is comparatively low when weighed against, say the Windows platform and Visual Studio

Quantity is not synonymous with quality. It is those very point-and click-your-way-to-a-program "tools" such as VS which have made it possible for masses of folks (who would otherwise be in other fields) to piece together stuff for the windows platform.

I will leave the facts to be found at the above link as an exercise to the reader.

Re:Which ever tool provides the result

[slashbart]

> And what of the myriad programmers who've spent years using IDE's and text editors, often starting with IDE's, who still prefer vim+gcc+gdb/ddd when writing C?

Exactly!

I started with the Codewarrior IDE, and thought you really needed an IDE. Years later, when I started Linux programming, I was pretty much forced into learning editor/makefile/gdb/ddd/printf style programming. I wouldn't go back to an IDE for anything! My productivity is higher, my understanding of what is happening is higher.

No RSI thanks to vim!

Bart

P.S. multithreaded debugging of realtime systems pretty much requires printf (or something like it) style debugging, single stepping debuggers are pretty much useless for this kind of work.

My tools

[ggambett]

Editor - gedit for syntax highlighting
Compiler - gcc
Debugger - gdb
Mem Checker - valgrind
Build - make and a custom build system written in Python
Image processing - ImageMagick

That's it. Spartan, yes, but it forces me to write good code instead of relying in fancy tools :)

Re:My tools

[$RANDOMLUSER]

Archaeology - kompare

Re:My tools

[ggambett]

Hmm, yes, I forgot meld to compare and SVN for source control.

Re:My tools

[Anonymous Coward]

You didn't mention SciTE; it has great syntax-highlighting and, while it's not an IDE, it does have some simple features leaning in that direction:
Compiler error messages show in the output panel, and you can click them to go to the source line.
You can run the code in a mini-shell in the output window.

And it's cross-platform.

Re:My tools

[cabazorro]

gedit Spartan?
all you need is bash-xterm-vi
and vim if you want your nails done.
cscope and ctags to track your code
get your hair highlights with Perl and Ruby
to look fab.

Re:My tools

[Anonymous Coward]

I'm a gvim fan too, and I have decided to try some of the new IDE.
Since I need an IDE mainly for C/C++, I decided to give SUn Studio 12 a go.
After finding jvi (jvi.sourceforge.net), which makes the editor behave somehow like vim,
I have to say it _is_ a fine tool.

Re:My tools

[Anonymous Coward]

errr gedit for syntax highlighting?... vim and emacs provide syntax highlighting already... and you can use them over ssh too for those job that runs on a remote machine.

Re:My tools

[fabs64]

Just so you know, both gvim AND plain vim have tabs.
My personal use for that is to bind Ctrl-t to new-tab to be the same as firefox, with f11 and f12 being next and previous tab respectively, Ctrl-tab would be nice but I seem to recall it not working.

Re:My tools

[Anonymous Coward]

What about ... emacs? I know, I know, you're a vim user, so I may be blaspheming. But it might give you that oldschool unixy feeling, with lots of features and options and none of the bloat (at least by comparison with eclipse). Anyway, I thought it odd that you didn't even mention emacs. If you hate it, you hate it, fine. But if not, its a great editor/kitchen sink.

Re:My tools

[Anrego]

I'm not an vim eletist or anything, I've just never really extensively tried emacs.

I don`t really have anything against it, but for some reason have just never been able to find the time to learn it. It's on my list `o things to do some day ;)

For me..

[nrgy]

it is Eclipse. I'm no kernel hacker or huge application designer, over the years I've picked up c++ to create plug-ins for applications I use and also for making little tools designed for myself. For the longest time I tried finding an IDE on Linux but was unable to find one I actually liked. I've tried Anjuta and KDevelope, while I prefer Anjuta if I had to choose between the two I still didn't use it. It wasn't until about 3 months ago when I downloaded and tried out Eclipse that I was finally able to dump gedit and start using an IDE finally. For me KDevelope seemed a bit to much while Anjuta was just about right for my needs Ubuntu unfortunately used some messed up beta as the version in synaptic. I know thats not Anjuta's fault and I could of compiled an earlier version or spent some time maybe searching for a .deb file but I didn't want to spend the time doing that, besides gedit was doing just fine for my simple needs so it would of been a waste for something that wasn't all that important to me at the time. Anyways I'm glad I tried out Eclipse and am glad I gave it a shot because I really enjoying using it now over a simple text editor.

Sounds like a useful book, actually...

[abes]

I don't do nearly as much Linux coding as I used to (I'm a switcher). I certainly got by with Emacs, editing makefiles, and I've never been big on debuggers or profilers (std::cerr). Not to say this is either right or wrong -- much of it is personal preference. But that's what sounds good about the book, is that it gives a good amount of background of where to find the information. That's something that takes a while to learn. It's also nice to see books which are (potentially) more than just a regurgitation of the information. I own several O'Reilly books which are the same info you get in the docs. It seems to be a trend, as the Ogre3D book I recently got gave very little information which wasn't already online. Convenient to have in paper, perhaps .. worth $40, probably not. Would it hurt to try a little, and give examples that *aren't* already written? Maybe give some background that wouldn't be found elsewhere? Maybe an interview with the author? Is it really that hard to try?

On a slight tangent, I was never a big fan of the Visual Studios. While XCode is definitely not perfect, it works very well. Sometimes I still miss how Emacs did things, but not having to put together a Makefile, but still have a fairly complex build process is really nice. Having a real graphics UI that works well, also really nice.

For Linux there is the KDevelop program which is an attempt to copy Visual Studios using the KDE toolkit. Because of my general dislike of VS, I always preferred Emacs over it, but others might like it. I should probably also give a shout-out to code::blocks, which runs on Windows, Linux, and Mac. However, the last official update is quite old, so you'll probably have to use a nightly build, and the nightly builds are still fairly buggy. I finally gave up on using it, as it was causing more pain then actually helping me do anything. Again, it mostly copies VS, and so I'm not the biggest fan.

Re:Sounds like a useful book, actually...

[Anonymous Coward]

I used to really like Code::Blocks, but I too got tired of having to deal with nightlies. The developers don't think stable releases are important. They're going to be using the nightlies anyway, so there's no incentive for them to ever work towards a stable release.

Currently, although there's lots of good stuff out there, none of it seems to provide for a really good solution. Just lots of okay solutions.

Re:Sounds like a useful book, actually...

[bensch128]

On a slight tangent, I was never a big fan of the Visual Studios. While XCode is definitely not perfect, it works very well. Sometimes I still miss how Emacs did things, but not having to put together a Makefile, but still have a fairly complex build process is really nice. Having a real graphics UI that works well, also really nice.

Try slickedit. It has key bindings for emacs with a more user-friendly interface and it's tagging/auto-completion is the best in the market AFAIK. I think it was modelled on the emacs way but was adapted for lesser mortals. It's less configurable then emacs but alot more usable IMHO.

Ben

PS. I feel like a marketing troll for slickedit but I just really like the software. The more recent versions have strange bugs sometimes but mostly they've kept the quality high.

Re:My Opinion

[Bugs42]

The fact that you were able to get a job as a professional programmer hurts my soul.

What does it take?

[Anonymous Coward]

To answer the question in the summary: It depends on what you want to do.

It's more about knowledge than software. There are many different languages, compilers, editors and IDE's out there. I would say that there are a lot more options when developing on GNU/Linux than on most other platforms. If you want to do cross-platform development, Linux is a good development environment but you will need special knowledge to design a cross-platform project from the start. If you just want to do standard C, C++, Java, Ruby, Python, etc. then that is generally the same on Linux as anywhere else but as you try to do more advanced things, you may find that having knowledge of the underlying system or special libraries could be useful or required.

If you want to develop graphical apps, you will probably need to know how to use a widget toolkit whether that be GTK, Qt, WxWidgets, Swing, etc. Some of these are even cross platform.

As far as software goes, many developers use text editors like vim and emacs. GDB is a console-style debugger that has graphical front-ends available. If you want a graphical IDE, there are many choices: Dev C++, Eclipse, KDevelop, Anjuta...

My tools for GUI building

[green pizza]

* nedit for syntax highlighting (yeah, it requires LessTif or OpenMotif, still lighter than GTK)
* gcc is my compiler
* Xaw3D is my gui widget library (yeah, I know we know have FTLK, GTK, etc...)

You are being a bit conservative

[Anonymous Coward]

The vast majority of what gets written isn't in C or C++. It is in scripting languages. Occasionally, that doesn't work very well. Large applications written in Python (for instance) have been known to be bog slow. On the other hand, if an application becomes popular and supported, it is probably worth porting it to a lower level language.

One of my favorite applications is Moodle. It does a fine job of replacing WebCT. If the people who wrote it had to write it in C, my guess is that it would never have happened.

The computers we have now are so powerful that we don't usually have to worry about how we squander resources. We can just write an application (in Python or whatever) and get something useful much faster than we could if we had to write it in C.

Is there a place for things like memory profilers? Sure. In the embedded world we still have to worry about resources but that's not where the majority of programming is happening. I bet there are far more db applications with a Visual Basic front end than there are device drivers being written. You give a ratio of 20:1. My wag is closer to 100:1.

Re:You are being a bit conservative

[bmk67]

The computers we have now are so powerful that we don't usually have to worry about how we squander resources. I see people saying this and I have to shake my head. First of all, poorly written procedures are capable of wasting huge amounts of computing resources. Write a daemon that does I/O polling poorly and watch it waste an immense amount of CPU that could be used to run useful code.

If you're talking about applications for the typical home computer, you may have a point, although not one I would necessarily concede. I work in a commercial environment where we're always struggling with resource contention of one sort or another. We can't squander resources on our database servers where adding CPUs/memory to an existing box or adding another box would result in much higher licensing fees that we'd have to justify to bean counters who don't grok this shit. In our environment, adding another $20K box to the production environment means in reality that we've got to buy at least 4 boxes to account for local redundancy, the disaster recovery site, and our test environment. There's also the indirect costs of adding all of these boxes (our non-production data center is about maxed out in terms of floor load, HVAC capacity, etc etc etc).

The money saved by not buying those boxes pays the salaries of people who can spend a lot of time writing efficient code.

Re:Win32 dev bad? NOT for Delphi/Kylix & Win32

[jshriverWVU]

Kylix died a long time ago. From my understanding it sucked compared to Delphi and Borland never really supported it. Not trolling because I really wish it was still around. I just recently had to convert a lot of old Delphi code to linux so I had to translate it to C. Not hard work, but time consuming. If I could have just dumped it into Kylix it would have made life a lot more simple, and saved me a couple months.

Re:My Opinion

[Ant P.]

I can't remember the last time I saw a professional programmer that only spoke AOL.

After strange aeons, even Death may die!

[Number6.2]

I'm still waiting for the CTL-Ia CTL-Ia CTL-Ftagn! command!

Unless you are MacGuiver

[jimstapleton]

Then it takes a stick of bubblegum (actually, just the wrapper), a shoelace and a pair of toenail clippers.

Re:Unless you are MacGuiver

[Cryolithic]

It's MacGyver

A few tools...

[Savage-Rabbit]

What does it take to start writing programs for Linux? That depends on what you want to do. If you are wanting to develop in Java, PHP, Perl, Python or (dare I say it) .NET you are best of setting up some super user friendly distribution like SLED or Ubuntu and using a GUI tool like Eclipse or NetBeans.

If you want to move into the murky world of C/C++ development these are IMHO the basic tools:

• vim/emacs: Popular command line text editors, deciding which one to choose is like choosing a religion. There are also a few excellent GUI suites.
  
• make: Automate compiling.
  
• gdb: The GNU debugger.
  
• gcc: GNU project C complier.
  
• g++: GNU project C++ compiler.
  
• cscope: Search and navigate through huge code trees.
  
• man: Linux manual pages, the cause of much head scratching.
  
• grep: Limited substitute for some of the stuff cscope does. I love the '-r' option failing that use: find /directory -exec grep "pattern" {} \; -print
  
• doxygen: Like javadoc but less language specific.
  
• goolge code search: Indispensable if you are stuck or need hints on which is the best way to proceed. It allows you to compare different solutions other people have used.
  

There are many more tools but those are good start. It also helps to have a thick skin, getting to know which library does what, being persistent and making heavy use of search engines rather than posting every problem to mailing lists and newsgroups. Also remember that a lot of enterprise grade software can be had for free under various conditions. Just to name two examples... OS X actually ships with the Xcode development suite and Oracle offers various developer suites as well as many of it's products for download under a development license if you sign up for an Oracle account.

Re:A few tools...

[bfields]

grep: Limited substitute for some of the stuff cscope does. I love the '-r' option failing that use: find /directory -exec grep "pattern" {} \; -print

One small convenience git provides is "git grep", which does a recursive grep of your working directory, but just of paths that git is tracking. It's kind of surprising how often I find myself using that; it still doesn't quite replace cscope (plus vim keybindings) for me, but it's a heck of a lot better than the "find src/ -name '*.h' -o -name '*.c' | xargs grep" stuff that I used to find myself doing occasionally....

Mod parent up

[QuasiEvil]

I agree. Professional programmer here as well, and IDEs significantly improve my productivity and accuracy. IDEs aren't a new Windows thing - I still remember the Turbo C environment for DOS. Having an integrated, interactive debugger is incredibly useful...

Does it apply to 2.6.21+ kernels?

[andrewd18]

The fifth chapter titled "What every developer should know about the kernel" is a turning point in the book and gives a comprehensive understanding of the working of the Linux kernel. It is by far the largest chapter -- with nearly 100 pages devoted to this topic. In this chapter the author talks in lucid detail about the different modes in Linux, the process scheduler, device drivers, the I/O scheduler and the memory management in user space, understanding all of which is instrumental in writing better programs for Linux.

Does this apply to all the new realtime kernel stuff in 2.6.21+? As I understand it, a good portion of that got rewritten...

I have to say this doesn't sound like a good book.

[jd]

Good programmers think the most, design the cleanest, and write the least. Reusability is paramount, lines-of-code is unimportant. Good programmers also refer to reference manuals, sample code and other snippets, online texts and header files - you only need know A computer language for the structure, the rest can be gained by inference and reference. There is no debugger superior to appropriate printing of state in the code. A source debugger is helpful, but not very - I've got more mileage from debugging libraries and suitable test harnesses. The other tools are useless if you've any level of programming aptitude, except in very specialized circumstances. And even then, not much. I can inspect a binary file better in emacs, as it prints non-printable characters as escaped but leaves ordinary characters alone.

All in all, the book gives suggestions that will help you get a good grade at CS, and maybe Software Engineering, but probably not more formal courses (too little emphasis on the thinking part). It will help you write good programs, without a doubt, but not great programs and certainly not masterpieces. Nor will it help you with the history of programming (programmers predate text editors OR debuggers) or the future of programming (this book is only marginally useful on fourth- and fifth-generation languages, RAD, specification compilers, massively parallel programs, fuzzy logic, self-modifying code, and other such fun stuff).

All in all, there will be many people who will get great value from this text, but they will never be language-agnostic and they will never write the truly brilliant software that they are quite capable of. Yes, it's easy to criticise and harder to do, and it's most unlikely I would ever write a computer book. Mostly because nobody would be able to understand it - my writing style is hard enough to follow on Slashdot, I can guarantee you'd see people jumping off bridges if faced with 500+ pages of my degenerate writings. However, the fact is that there are many good books for novice programmers who want to be adequate, a few for adequate programmers to unlearn bad habits and become good programmers, far fewer that skip the middle step and go straight to good, and none at all that show someone how to go the extra mile that turns something good into something amazing.

That's the book I want to see someone write, and get reviewed on Slashdot.

Re:My Opinion

[ILuvRamen]

I meant computers couldn't run complex programs like they can today so everyone slimmed them down and didn't add stupid features that take up 99% of a modern processor for like a minute. I don't think it would be possible to write the newest version of Norton's security suite in notepad for example. And don't you dare say nobody writes complex programs for Linux cuz there's cool stuff out there

netbeans IDE 5.5 with C++ pack

[Anonymous Coward]

after 5 years of developing apps on Linux using C++, I prefer the following:

Debugger: gdb
Compiler: gcc 4x
IDE: Netbeans IDE 5.5 w/ C++ Pack (actually download all the cool packs)
GUI IDE: QT Trolltech
Images: Gimp !!!!!
Kernel: 2.6x
Build: Make
Version Control: Subversion

A lot of good "Linux" IDEs exist

[benhocking]

Depending, of course, on how one defines that. Regardless, Anjuta is a great IDE for C/C++ coding and Eclipse is a great IDE for Java coding.

Re:A lot of good "Linux" IDEs exist

[gtada]

Oh come on. You know the benchmark he's comparing to. Anjuta and Eclipse are okay, but a lot of devs are looking for an IDE as good as (or better than) Visual Studio on the Linux platform, particularly with the debugger.

I understand it takes time to get there, but then it has to be understood a lot of devs won't be interested until then.

Re:A lot of good "Linux" IDEs exist

[bberens]

My understanding is that Eclipse has plugins for development in other languages (particularly speaking of C/C++ here). Can anyone speak to how well those work if at all?

Re:A lot of good "Linux" IDEs exist

[NialScorva]

I found that the C++ development was difficult if the project size was too large. The "build automatically" feature was hopeless if it was turned on. It fires every time you save a file and usually didn't finish before the next save if you were doing tweaks. Autocompletion got to be extremely slow as the symbol tables increased, though that might have been partially to the templates I was using. Without those features, a lot of the appeal for Eclipse went away for me.

The caveats are that I was using the gcj compiled version that came with FC4, and was using this when FC4 was current. It may have gotten better, but C++ is such a complicated language there may still be issues.

Re:A lot of good "Linux" IDEs exist

[Anonymous Coward]

I understand it takes time to get there, but then it has to be understood a lot of devs won't be interested until then.

Perhaps a lot of monkeys won't be interested until Linux can provide all the same efficiency-destroying crutches that let them currently hobble through the process of hacking together buggy and WTF-ridden programs, but frankly we can do without their sort turning Linux into the hell that they've made Windows into.

Yes, I'm elitist. That's because it's the only logical position to take. The human race is never going to advance until we abandon our pathetic obsession with the blatantly untrue claim that everyone has equal potential, and acknowledge that most technical jobs require special skills that only a fraction of the population will ever possess. (Until we grow mature enough as a species to accept the harsh reality that eugenics is the only way we will ever put an end to poverty, overpopulation, and all the other major sources of suffering in the world.)

But I digress. To put it bluntly, programming is actually very hard, and no visual IDE, however "sophisticated", will give monkeys the ability to do it properly. So they should find jobs they are actually capable of, like stacking shelves or flipping burgers or swinging from tree to tree like nature intended, and leave programming to the intelligent elite, who, being intelligent, are capable of learning to use difficult-but-powerful tools like emacs or vim properly and thereby being vastly more productive than the monkeys who rely on point-and-drool crap like Visual Studio.

Mod me "troll" or "flamebait" if I've hurt your feelings, mod me down into oblivion if you can't handle what I've got to say - but you know it's true.

Re:A lot of good "Linux" IDEs exist

[aztracker1]

Personally, I don't mind operating without an IDE... I've done it before, do it all the time... I'm more likely to fire up my handy text editor for quick edits than to load a big IDE... However, a good IDE can improve productivity... Integrated source control is another nicety (though, I don't like source safe.. usually better to have a SVN/CVS plugin).

There are a lot of monkeys trying to write code out there, I will agree with that.. but I don't blame the tools so much for that, as I blame the twits who think they can be awesome coders because they saw some ignorant fool in a movie playing a l33t h4X0r role... Or think that being a web programmer is the key to making the big bucks. The advertising that technical trade schools push out is equally, if not more to blame... Sure, we can shove enough knowledge to pass an MCSD exam into your head in a few weeks, but won't actually teach you how to use that knowledge... It's all crap.

Re:A lot of good "Linux" IDEs exist

[toadlife]

Are you sure you're not actually a *BSD user?

Re:A lot of good "Linux" IDEs exist

[tomhudson]

I hope I never go back to an IDE, unless its something along the lines of Borland's text-mode BC++/Turbo C version. It never "got in my way." My current "IDE" is a half-dozen shells opened at different parts of my source and release tree so I can run vi to dash of a quick 2-liner shell script or perl script, run ctags or mc; several copies of kate with different session hsitories, on different monitors; firefox for quick web searches (and to pop in on /.); and kopete so that everyone in the office can communicate. An IDE? My desktops ARE my IDE.

The only tools you REALLY need:

1. Multiple shells open, each with its own command history, so you can jump back and forth;
2. Text editor of choice that does syntax hilighting and code folding (vi, kate);
3. make;
4. some perl script fu, and some bash scrpt fu, and some python snake oil (great for automated testing);
5. mc (F2, 3 is handy for making quick tarballs);
6. a net connection so you can look up stuff fast;
7. IMPORTANT: a shelf full of O'Reilly books - do NOT skimp;
8. 2 or more monitors - this is an almost absolute necessity for serious coding;
9. a project wiki to keep track of things, etc.,
10. fgrep -n, ctags, doxys for a first peak at other people's code

Also, not a tool but equally essential: plenty of liquids (coffee, soft drinks, booze).

Re:A lot of good "Linux" IDEs exist

[snapp_action]

Eclipse's C++ plugin (CDT) has actually fixed the parsing issue your mentioning as of version 4, which is about beta quality right now (final release June 22). I ran across the same thing and gave up on version 3, when I realized it would take 2 hours to index our product source code. I haven't benchmarked the latest version, but I understand it has been completely redone. In addition they've done a lot of usability tests and gotten rid of a lot of the complicated project set up. I tried out a simple hello world and got a working, debuggable, program in under 15 seconds. I'm hoping to see if it may be a viable alternative to Visual Studio here at work, simply because of its extensibility. In case you are interested in getting the download, go to http://www.eclipse.org/cdt/ and check it out.

Re:A lot of good "Linux" IDEs exist

[Anonymous Coward]

While I agree that spoon feeding is a bad for everyone, I find this attitude of being an "elite" quite noobish. Free software movment was started with the objective sharing and spreading your knowledge, as oppposed to being an "elite" because you know something better (and I think Open Source has inhereted this attirbuted as well :)).

I think Microsoft got all screwed up precisely because of this "elitist" attitude. Yes, some people lag behind in their understanding of technology, it doesnt mean you cant share your knowledge to get them upto par. It is just this knowledge which is the difference between being good and bad at something. SHARE your knowledge, its good for mankind :)

Re:A lot of good "Linux" IDEs exist

[brainhum]

If you're holding yourself out as a programmer, you definitely have to be able to write good code. But technology work is not made up solely of programmers. I work with programmers, *NIX administrators, graphic designers, UI designers, animators, illustrators, subject-matter experts (usually with PhDs in non-technical areas), clients who are not geeks, etc. There are a lot of jobs in technology that do not require you to write any code whatsoever.

It sounds like you are the alpha nerd on your development team, but you have been forced to work with programmers who were sub-par and now you're bitter. Why is that? Maybe the people you work with are new to the industry and fresh out of school. Maybe your company pays crappy wages and can only attract the code monkeys, people with zero interpersonal skills and other deficiencies that force them to only accept lower paying contracts. But, as an AC poster, we'll never know.

Everyone has a different skill set, not all are cut out for coding. There is a place for everyone though; the cubicle down the hall, your parents basement, or even at McDonalds. Some may have a knack for novel algorithms but have trouble attracting mates - not an uncommon affliction among programmers. Don't worry, there is a place for you! As my old Comp. Architecture prof once said: "If you can't get laid, you might as well write some good code."

BTW: My editor of choice is JEdit, and eugenics has been thoroughly discredited except by Nazis and others who are fond of brown shirts. You may want to rethink your affiliation in that regard.

Re:A lot of good "Linux" IDEs exist

[dido]

Booze? I don't know about you, but coding while alcohol-intoxicated has a distinctly negative effect on quality of code for me...

Re:A lot of good "Linux" IDEs exist

[tehcyder]

Yes, I'm elitist. That's because it's the only logical position to take. The human race is never going to advance until we abandon our pathetic obsession with the blatantly untrue claim that everyone has equal potential, and acknowledge that most technical jobs require special skills that only a fraction of the population will ever possess. (Until we grow mature enough as a species to accept the harsh reality that eugenics is the only way we will ever put an end to poverty, overpopulation, and all the other major sources of suffering in the world.)

Is that you shouting down there in the basement Timmy? If you don't behave, mummy's not going to give you a chocolate bar.

Re:A lot of good "Linux" IDEs exist

[tomhudson]

"Booze? I don't know about you, but coding while alcohol-intoxicated has a distinctly negative effect on quality of code for me..."

Who said anything about being intoxicated? Or even "having a bit of a buzz?"

That said, sometimes, when you're neck-deep trying to fix other people's crap undocumented code, taking a break and having everyone head down to the local pub for a clear-the-air brainstorming and bull session is just the ticket.

Re:A lot of good "Linux" IDEs exist

[NialScorva]

Very cool. I'll have to give it a try this weekend. That was about the only thing that would make me give up Emacs.

Re:A lot of good "Linux" IDEs exist

[mathgenius]

Bravo! What more is there to say ?

Re:A lot of good "Linux" IDEs exist

[Anonymous Coward]

I love how people that consider themselves good developers also seem to believe the limit to a programmer's productivity is their typing speed, and so any programmer that needs to take their hands off the keyboard to use the mouse is an idiot. Let's see, 100wpm*60mins in an hour * 4-6 productive hours in a day ... you must get at least 24,000 LOC written in a day.

And yes, laugh at Ballmer for saying "developers, developers, developers." Because you don't want crappy programs written for Linux. Programs which you would have the ability to use or not. Programs which might encourage more adoption of your OS and actually help popularize OSS. Because we all know Windows sucks not because of the insecure design and web browser but because you can buy a stupid shareware programs.

But you're "elitist" which I guess in this case means you want to feel special when you walk down the street in you Linux t-shirt.

Re:A lot of good "Linux" IDEs exist

[Anonymous Coward]

the harsh reality [is] that eugenics is the only way we will ever put an end to poverty, overpopulation, and all the other major sources of suffering in the world ... [the monkeys] should find jobs they are actually capable of, like stacking shelves or flipping burgers or swinging from tree to tree like nature intended, and leave programming to the intelligent elite ...

Please, for the love of God, tell me this was modded up for the humor value. Slashdotters, you don't actually think this way, do you? Surely this is not your real, sincere beliefs, and not the light in which you view your fellow human beings?

If it really is, this community has more problems than I ever imagined. Luckily, due to the ironic fact that most people who refer to non-kernel hackers as monkeys who shouldn't be allowed to breed aren't attractive on the singles market themselves, we won't even need a eugenics program. It'll sort itself out in a generation or two without our help.

Re:A lot of good "Linux" IDEs exist

[Anonymous Coward]

To put it bluntly, programming is actually very hard, and no visual IDE, however "sophisticated", will give monkeys the ability to do it properly.

To put it bluntly, if you think programming is "very hard," you're the idiot. Programming, on average, is simple. Some programming tasks are indeed difficult, but most are not, which is precisely why this profession attracts so many "monkeys." It also attracts a lot of kids, many of which do useful work. Please show me another profession where 14-year old kids without any formal training can build things on par with that of professionals.

If you were a string theorist, or something equally fancy-sounding, there might have been a point somewhere in your offensive, borderline-Nazi-like* rant, but now there isn't one. What you do isn't much more difficult than what a plumber or a brick layer does, but then again, I'm sure you'd vent your misplaced anger against all the monkey bricklayers had you been one of them. Sorry to burst your bubble, but it was probably a long time coming.

* Yeah, I'm fine with going all Godwin and ending this thread right here.

Re:A lot of good "Linux" IDEs exist

[Grahad]

You are right that not all people have equal potential, and your post seems to accurately reflect that. It is well established that there are multiple types of intelligence: logical, interpersonal etc. I don't know why being strong in logic / programming would make one elite when their interpersonal IQ seem to be lacking. It would make them a bit unbalanced if anything...

What is sad is that your arrogant attitude reflects how little you know about human potential. If given the proper environment almost all humans have the capacity to master technical subjects. It is amusing that you put technical skills so high on a pedestal when they really are logically very simple. A real challenge would be something a bit more academic.

There seems to be an attitude of arrogance in the tech industry, the belief that somehow the computer profession is superior to other technical trades. This type of thinking is unfounded and seems to be self correcting.

Re:Win32 dev bad? NOT for Delphi/Kylix & Win32

[Anonymous Coward]

Take a look at Lazarus. It's not meant to be 100% compatible with Delphi, but I imagine it would be much faster to port to that than to rewrite it in C.

Re:My Opinion

[MightyMartian]

I'll wager a good chunk of most modern programs is library bloat. You could and still can write some pretty damn complex software on minimal systems. The fact is that some very large and very complex software packages have been written using what we would consider antiquated tools. I'm not saying we should still use such tools, though I think there's an argument to be made that most programmers aren't sufficiently well-versed in the more esoteric methods, and sometimes that means they put a rather large amount of faith in the operating system and/or libraries doing what they want and doing it correctly.

Bah, vi is fine for simpletons

[benhocking]

Personally, I think all coding should be done using a hex editor and in machine language (none of that fancy assembly - it rots the brain!).

Re:Bah, vi is fine for simpletons

[Dogtanian]

Personally, I think all coding should be done using a hex editor and in machine language (none of that fancy assembly - it rots the brain!). Real Programmers use dip switches.

Re:My Opinion

[Anonymous Coward]

thank microsoft, apparently if it is syntactically correct it ships. :(

Just remember Knuth's warning...

[benhocking]

"Premature optimization is the root of all evil"

Re:Just remember Knuth's warning...

[PylonHead]

I also like:

The first rule of optimization is: Don't do it.
The second rule of optimization (for experts only) is: Don't do it yet.

Of course, in these cases, what they're really saying is, don't start out sacrificing simplicity to achieve what you imagine to be greater performance. When you have achieved correctness in your program, this is a good time to whip out your profiler and actually figure out what does need speeding up. Always measure the before and after performance of your application. Often enough you'll find that your brilliant optimization doesn't speed things up at all, or worse yet, makes it slower.

Re:Just remember Knuth's warning...

[NoOneInParticular]

Wise words from the time when people were debating the runtime implications of using a for loop versus a goto, or pre-incrementing versus post-incrementing integers. Nowadays, with layers upon layers of glue code, beans, clusters, databases, stack dumps 100s of levels deep, virtual machines running operating systems running virtual machines: we've created much greater evils than premature optimization ever did. Nowadays premature optimization is mostly harmless.

I sure wish some of these middle-ware pushers would have wasted some time doing some premature optimization: maybe that would have put some runtime realism in their heads, and some stop on the root of all evil: battling bloat with more bloat.

Re:Just remember Knuth's warning...

[Anonymous Coward]

Knuth probably meant such optimization that involves tradeoffs between readability and speed or something like that.

However, there are folks that instinctively come up O(n^4) algorithms for everything. Need to find an item? Use a linear search. Need to find another item for each item? Hey nest another loop there, etc. When you have 150000 lines of code like that, what do you do? Use a profiler?

Re:Just remember Knuth's warning...

[pclminion]

"Premature optimization is the root of all evil"

Such absolute statements aren't always helpful. What does "optimization" mean? Is the choice of the language itself an optimization? Many things are probably simpler to code up in a scripting language like Python than they would be in C. But does that mean that by choosing C I've already committed the sin of premature optimization?

What if I need to store a mapping between strings and integers? I could use a list of pairs, or a binary tree, or a hash table. The hash table is probably the most "efficient" of the three, depending on circumstances. But am I sinning by choosing it, when in theory a list of pairs could also work? "Don't prematurely optimize" does not mean the same thing as "Pick the slowest of all available techniques."

Re:Just remember Knuth's warning...

[aevans]

premature optimization == money? I'm going to unroll some loops in this webapp I've been working on... It's a social networking site for VOIP driven real estate day trading.

Re:Just remember Knuth's warning...

[Trogre]

I'd like to propose a third rule of optimization:
(For OpenOffice.org developers only) Do it now. Please, for the love of God, do it now!!!

Source control!

[eli173]

Ask a professional programmer, and a good source control system should be high in the list.

Re:Source control!

[jgrahn]

Ask a professional programmer, and a good source control system should be high in the list.

The reviewer didn't seem to mention it but, yes, that aspect is covered. At least according to the Amazon blurb.

I'll go a step further

[benhocking]

Back when we had to write code that would fit in about 590k or so, we would employ all sorts of "tricks" to reduce memory usage. The result was that the code was usually less readable and arguably more complex than it would otherwise be.

Need other things? Not really...

[fahrbot-bot]

...other things come into play in writing efficient programs such as, a debugger, memory profiler tools and above all a good understanding of the inner working of the Linux kernel and its processes...

Not really. I've written many, many programs for various Unix and Unix-like systems over the past 20 years and only rarely have I needed a debugger or memory profiler.

Furthermore, understanding the "inner workings ...", while beneficial, only really matters when writing programs that interact with said "inner workings".

In short, one doesn't need an IDE or SDK to develop quality software, just skill and experience -- though the former can be helpful when the latter are lacking.

My tools

[Anrego]

I seem to frequently shift between tools of choice on *nix. They all have their flaws, and all have their advantages, each of which becomes more or less relevant depending on what your working on. I find that:

Eclipse absolutely rules for working on a system dealing with multiple languages and database environments.It's perspective system is genius in my opinion, as it lets you easily switch from one "environment" to the next without having to close your work, and also lets you merge environments (ie. be working on a C++ source file with the database info in the side/bottom bars. It's major flaw though, in my opinion, is that it's too resource intensive. Even on a reasonably powerful machine, it tends to feel laggy. It also seems to have a few quarks due to its Java-ness.

Vim, well, like all *nix geeks I love vim. It's only real shortcoming in my opinion is when dealing with many source files, and while gvim supports tabs.. it's still clunky and awkward compared to most other GUI tools.

On that note, I am kind of warming to gvim lately. I used to scoff at it, but after forcing myself to try it, I am actually finding it fairly nice. Still feels like a cli app hacked to run in a GUI shell, but it doesn`t seem to take anything away from the vim experience.

Code::Blocks would be awesome, if it was a little more stable, and like eclipse, a little less bloated.

Anjuta.. well.. I didn't mind it, but I found its insistence that you do everything through its project management facilities a little annoying. I don't mind editors having project management features, but they shouldn't force their use.

gedit is fairly nice, although it's syntax highlighting is a little wonky (especially when it comes to things like treating apostrophes as single quotes...)

nedit is nice, but it suffers from the same wonky syntax highlighting issues gedit does.

kdevelop is in my opinion just plain overkill. If your working on a huge project it might be nice, but for a medium to small project, its just insane. Also feels very laggy.

In short, I don`t think there will ever be a perfect editor. Most developers are like me, that is, opinionated and picky. Little things will put us off an entire tool set.

My perfect editor would probably be an mix of vim and eclipse (less the bloat). But some people would want more vim, and some people would want more eclipse... and trying to make it customizable with plugins and massive sets of options is probably what contributes a lot of eclipses bloat (besides the Java).

Re:Win32 dev bad? NOT for Delphi/Kylix & Win32

[Anonymous Coward]

"Kylix died a long time ago" - by jshriverWVU (810740) on Wednesday June 13, @03:22PM (#19495745)

I had no idea that happened, & like yourself here:

"I really wish it was still around." - by jshriverWVU (810740) on Wednesday June 13, @03:22PM (#19495745)

You & I both - if no MAJOR changes to the Qt libs it calls have occurred for KDE? It ought to still work though... has this happened (major changes to Qt that make Kylix in its final version unusable for development on Linux)?

Thanks for the info., if you know of this happening... sounds like you might, because of your next reply quote below:

"I just recently had to convert a lot of old Delphi code to linux so I had to translate it to C. Not hard work, but time consuming. If I could have just dumped it into Kylix it would have made life a lot more simple, and saved me a couple months." - by jshriverWVU (810740) on Wednesday June 13, @03:22PM (#19495745)

You're right - it WOULD have saved you a great deal of time... too bad it's disco'd now!

APK

simple and effective KDE tools.

[twitter]

kdevelop is nice, but I don't do a lot of GUI programming. For what I do, Kate and kdbg work great.

Kate is a good GUI text editor and a joy to use. It has a file browser and quick picker for open files. Sessions act like project files, so you can quickly load all the files you need to work on. The editor itself has excellent syntax highlighting, tabs and split screens, so you can see multiple versions of the same file and compare it to others.

Kdbg is a GUI front end to the gnu debugger. It has all the usual things and a few nice extras all workable with a mouse. It has easy to manipulate step through, locals and watches. Variables that change are highlighted in red. One of the neat extras the watches has is the ability to do simple math and return values of functions used in your code. If you have a function dot_ab(a b) that returns dot products, you can put variables you are watching in and get back the answer you want.

Short and Sweet

[Anonymous Coward]

Bloodshed Software - Dev-C++ (A free C++ IDE for Windows and Linux for MinGW/GNU compiler.)
or
SciTE (Scintilla Text Editor with Extensions) platforms include Windows,Linux,and Mac

Both travel well on USB 2.0

Be Safe and Good Hunting...

Re:Win32 dev bad? NOT for Delphi/Kylix & Win32

[jshriverWVU]

Interesting, I did take a look at FPS (freepasal) and even with -D or whatever Delphi mode it still wouldn't work. Mostly because of the Win32 API calls. I even tried stripping all GUI-specific calls out making it a cli app first. Then ran under wine. Worked ok, but we needed it to be fast. In the end it was worth it porting to C.

On an odd note though, while doing the translation I did have my first look at Delphi for Windows, and to honest I was blown away. I still like emacs + gdb, but the Delphi IDE was pretty sweet. *waits to be flamed*

Re:Win32 dev bad? NOT for Delphi/Kylix & Win32

[jshriverWVU]

Not sure if it still work or not. You use to be able to download Kylix (free? eval?) and that doesnt appear to be the case anymore. So it's not even that it's not supported anymore, I can't even find it. With no distribution channels there are no legal ways of buying it. In the end would it even be worth it? It might have had potential but alas it's gone for better or worse.

No IDE? Say what?

[smcdow]

Linux doesn't have a comprehensive IDE on the lines of Microsoft Visual Studio to develop programs

Oh, please.

What about emacs?

Re:No IDE? Say what?

[ceeam]

More like: KDevelop, Eclipse, maybe Anjuta.

Re:No IDE? Say what?

[Anonymous Coward]

Marge: editor, debugger, compiler?
Aussie dude: EMACS?
Marge: EDITOR, DEBUGGER, COMPILER?
Aussie dude: EMACS?
Marge: E-D-I...
Aussie dude: E-M-A-C...

Re:No IDE? Say what?

[Anonymous Coward]

Yes, that's right, an IDE, not an OS.

Sheesh.

Yeesh.

[foo fighter]

Is the coverage of Make, et al, in Chapter 2 from the POV of using them to build stuff you've downloaded, or using them to build your own project? Same question for the coverage of packages (apt, rpm, etc.).

These can be a major bitch to figure out on your own, and are a pain in the ass even when you think you know what you're doing.

No coverage of source control?

No coverage of bug tracking?

And about this line: Linux doesn't have a comprehensive IDE on the lines of Microsoft Visual Studio to develop programs... Did the Eclipse project fold up and call it a good run?

This terrible review make the book sound terrible as well.

My Toolbox

[MrCopilot]

SVN, Kdevelop for editing browsing, gcc, qt.

When I have to go to the darkside I use Code::Blocks, SharpDevelop, and as absolute last resort VS.Net. I still use SVN, mingw, qt.

And the most important tool of course is a fast internet connection and a speedy browser. Firefox is the current favorite.

This simple setup gives me crossplatform support all the way from Desktop Apps, Through Server Apps, to Embedded Linux.

I've tried eclipse and I bet I could make it as usable, given enough time, but I'm not paid to redevelop my tools, only to produce code.

Rounding out the list is perhaps the most vital component of all, a nearly endless supply of CocaCola. I guess that goes without saying. Lately I've added VirtualBox or VMware to keep from getting dizzy from switching PCs. ( I keep myself surrounded with a server a Linux Box, a windows box and several embedded devices.)

I dare say it

[biscon]

environments like visual studio DOES make budding coders dumber imho.

The Visual IDE is just as valid a tool as everything else and if you know what goes on under the hood,
thats perfectly fine.

I've just seen to many people posting to mailinglists/forums with linker errors (especially places
like the libSDL list to give an example) they could have easily fixed themselves, if they had a clue
on how the compiler toolchain works, on each step of the process.

other than that im perfectly cool with IDE's. Right now im using netbeans with the C++ pack or KDE's Kate editor (why
they removed projectmanagement for session management is beyond me).

No VI or Emacs for me thank you very much.

Re:I dare say it

[sheldon]

Does an IDE make you dumber?

Or does the lack of an IDE just mean most people are turned away without even bothering to try?

Hmm... There are great IDEs for Linux!

[MrJerryNormandinSir]

XEMACS, EMACS, KDEVELOP, Glade, hmmm... all I got to say is N00B!

Does anyone use Real Basic on Linux?

[ClaraBow]

I'm just curious if anyone has developed programs for Linux using Real Basic. How is man enough to admit it? I'll say yes, if you do :)

Re:Does anyone use Real Basic on Linux?

[Anonymous Coward]

I defy anyone to tell the diffrence between my RealBASIC app and an application written using GTK!
Plus RB gives lots of easy to use system calls that work fine on Win32 & Linux. Way faster than .NET apps too.

Re:I have to say this doesn't sound like a good bo

[rafaMEX]

"All in all, the book gives suggestions that will help you get a good grade at CS, " yeah and i guess thats a plus since the book is about tools for linux programming and not the book you're describing ... and it does sound cool, nice post... for the wrong book tho.

Commercial IDE

[foo_script]

If you want commercial IDE, you can try out Active State's Komodo IDE. They do have linux version.

What are the major differences, in your opinion?

[benhocking]

I used VS professionally for several years before returning to grad school. Perhaps it has improved a lot since then (I used VS6, not .Net), but I don't see any significant differences between it and Anjuta *or* Eclipse. What features do you think are missing from Anjuta or Eclipse?

Re:I have to say this doesn't sound like a good bo

[rthille]

In a large crufty codebase, a good test harness may not be easily made. We had unit tests required for checkin at my last job. God I wish we had that where I am now...

As for printing state, depending on the system, printing may not be possible (embedded), or may throw off timing (or whatever) enough to make the problem go away...

A good debugger and skills in using it properly can be a huge advantage.

The best tool may not be the prettiest

[finiteSet]

I can't believe in this day and age someone would recommend starting with vi/vim .... Here's this crappy text-based editor, and then you can use these other command line tools to compile and then debug your program in text mode. Linux is pretty advanced!

While I agree that vim may not be the best place to start, I feel that it is a great place to end up, and I strongly disagree with calling it a "crappy text-based editor."

Crappy by what standards? Since when is a powerful text-based editor bad for editing text? I was raised on the Visual Studio IDE, but as soon as I discovered vim I jumped ship and have never returned. I find vim/make/gdb to be a far easier/faster/more convenient way to code. However much of an "archaic modality" this is, it is superior for my needs, and something that I encourage any coder to at least try.

I acknowledge that the "command line" part of the equation may cause problems for debugging GUI programs, that it may be subpar for managing a large number of files, etc. Indeed, it certainly isn't for everyone or every task; however, for the majority of the data-slinging / scientific computation / non-graphical coding and development I do, I wouldn't use a visual IDE if I was paid. The reason why I believe Linux is pretty advanced is because it supports an array of powerful tools like vim, make and gdb.

Re:The best tool may not be the prettiest

[Hooya]

> While I agree that vim may not be the best place to start, I feel that it is a great place to end up.

you, sir, are completely off base! it is clear as the mid-day sun in Arizona that *the* great place to end up is emacs. ;)

all kidding aside, i started off with TurboC++ IDE. well, a console based one - there wasn't a thing called windows(tm) back then. then onto VisualStudio (along with a number of others) and then i 'discovered' emacs. haven't looked back since.

i do, however, disagree that IDEs are better at managing a large number of files. grep/sed/awk/bash/elisp/python makes for a potent combination unparalleled by any IDE i've run into.

Re:The best tool may not be the prettiest

[blueskies]

it is clear as the mid-day sun in Arizona

Does that include the smog from LA?

My toolkit's always the same...

[radish]

Doesn't matter what platform I'm developing for (Linux/Solaris/Windows):

IntelliJ IDEA
A bunch of JDKs
JProbe

Knowledge of the internals of the JVM is valuable, of the linux kernel - less so.

What about documentation?

[muppet magnet]

What is a decent way to read API documentation under Linux? I'm comfortable using vim, and will happily edit Makefiles, but haven't found anything similar to the MSDN documentation.

Using 'man' and 'info' has been fine for finding out usage of command line programs, but (for example) I've been using GnoChm to read the Windows python documentation, because of the index, table of contents, and search facility features.

The ubuntu help (which includes the python docs) is no good for me; it's too slow to search, doesn't have a table of contents, and can't be restricted to just python (or C libraries, or ...).

What do you use for reading API documentation?

Re:What about documentation?

[Anonymous Coward]

Since Linus hates autocomplete e.g. IntelliSense, he would probably say that real programmers have all documentation memorized at birth. So if you don't already know it, you probably never should.

Re:What about documentation?

[klaasvakie]

API functions should be in the (3) series man pages.

In Vim you can jump to the man page of the word under the cursor with "\K". "q" gets you back. I wrote a Xlib app a while back and found this to be very nice and quick.

Your point?

[biscon]

No thats why said that I think they're great as long as you know how the compilation process work.
Was that some kind of attack on my person?.
As previous posters suggested there are numerous IDEs for linux so your last question is irrelevant.
But if people must have big and fullblow IDE to even consider coding for a platform I think they
should reconsider their profession. Its not to much to ask for that a programmer knows how compilation work,
we are not talking about the average joe user here.

Re:Your point?

[sheldon]

No thats why said that I think they're great as long as you know how the compilation process work.

Generally when I think of all the problems an IDE can hide, the compilation process isn't high on the list.

Was that some kind of attack on my person?.

No, rather your mother.

My point was rather simple. I think the IDE makes the technology available to a much wider audience. Yes, some of them may be idiots in your view, but without the IDE what do you think these idiots are going to do? Most likely, they're going to look at another technology which is easy to use. Say an Access database.

An IDE is just a tool. I use VS.NET, and while I hand code all of my HTML, CSS and so forth... I love the intellisense. I remember what's important, not all the minutia of syntax. But the IDE does allow someone starting out to do it the wizard way. As you learn, you recognize what the wizard is doing for you and judge whether you like it or not.

Oh give me a break...

[Tim Browse]

Most programmers with a Windows background will be forced to make a paradigm shift while embarking to program for Linux. While the Windows programmers are used to taking deceptive comfort within the cozy confines of a Visual IDE, when they make the shift to write Linux programs, they are suddenly faced with the hard facts of programming as it really is.

What a fantastic fantasy world to live in. Did I miss something, or is the software that millions of people run worldwide on Windows PCs somehow not 'real software'? Did the Windows developers who wrote large and/or mainstream applications such as Word, Photoshop, Quark, Winamp, Skype, etc somehow not actually know how to program?

I really would like to hear more about these 'hard facts' of programming...it makes it sound like it is harder to program for Linux - is this supposed to be a good thing? However, I don't believe this, and suspect it's the usual macho Linux bullshit that some F/OSS advocates seem to be afflicted with.

Luckily the rest of us can just get on with programming our software for whatever platform using the most appropriate tools, instead of banging nails in with our fists.

Re:Oh give me a break...

[drinkypoo]

Did the Windows developers who wrote large and/or mainstream applications such as Word, Photoshop, Quark, Winamp, Skype, etc somehow not actually know how to program?

Well, some of those are okay, but I think it's safe to say that the people who wrote both Word and Quark are complete fucking idiots. Especially Quark.

Re:Oh give me a break...

[Tim Browse]

I think it's safe to say that the people who wrote both Word and Quark are complete fucking idiots.

For Word, I really don't think so. To be clear, I'm talking about programming as separate from UI design, of course.

Especially Quark.

I may have to let you have Quark, though :)

Re:Oh give me a break...

[Nevyn]

I really would like to hear more about these 'hard facts' of programming...it makes it sound like it is harder to program for Linux - is this supposed to be a good thing? However, I don't believe this, and suspect it's the usual macho Linux bullshit that some F/OSS advocates seem to be afflicted with.

Being optimistic I'm hoping what he really meant was something like: "Linux and win32 are very different, you can't instantly program for one just because you've done so on the other. To add even more fun to the mix all your favourite tools won't be there if you go from win32 to Linux."

Although this works just as badly the other way around, all of the Linux software I've seen "ported" to win32 has just as many problems because win32 is not even close to Linux.

But you're probably right, it was probably just macho my X is better bullshit.

Re:Oh give me a break...

[dido]

Perhaps what is being discussed is the theme of Ellen Ullman's series "The Dumbing Down of Programming" (here and here). The point is that many of today's so-called programmers have lost touch with what the fundamentals of what it really means to program, having been too deeply insulated from it by the tools they use. Windows development does this isolation to an extreme degree, under GNU/Linux this is far less so, and likely to remain that way.

Re:Oh give me a break...

[Tim Browse]

So I typed out a longer reply, but it just boiled down to "No, it's still just macho bullshit."

So I'll leave it at that.

I certainly wouldn't trust someone who says:

For Microsoft's self-protective skin is really only a show, a lure to the determined engineer, a challenge to see if you're clever enough to rip the covers off. The more it resisted me, the more I knew I would enjoy the pleasure of deleting it.

Two hours later, I was stripping down the system. Layer by layer it fell away. Off came Windows NT 3.51; off came a wayward co-installation of Windows 95 where it overlaid DOS. I said goodbye to video and sound; goodbye wallpaper; goodbye fonts and colors and styles; goodbye windows and icons and menus and buttons and dialogs. All the lovely graphical skins turned to so much bitwise detritus.

Or, if you're not a muppet, you could just run fdisk, delete the partitions and prep the disk for a new OS. About 3 minutes work, I'd guess. Ooooh, I'm so clever - I defeated Microsoft!

Use Windows to Develop Linux Apps

[RonBurk]

Why restrict yourself to Linux tools just because you're developing a Linux app this week? I do all development (both Windows and Linux) from my Windows machine.

When coding for Windows, I have my editor open editing local files, and a console window open, for doing builds or whatever.

When coding for Linux, I have my editor open editing what looks like local files (but are actually a network share of the Linux development directory), and a Putty console window open, for doing builds or whatever.

It helps that my editor is Visual SlickEdit, which is very smart and flexible about handling end-of-line conventions. It also provides most of the IDE conveniences of Visual Studio.

I sense a problem...

[Mazin07]

To get started writing programs on Windows, you need a copy of Visual Basic.NET Express Edition. No programming skills required. Is that a problematic imbalance?

Re:I sense a problem...

[Anonymous Coward]

You don't need any version of Visual Basic to write programs on Windows. That's like saying you need Emacs to write programs for Linux, or you need iTunes to listen to music.

Re:I sense a problem...

[rubycodez]

but if you tweak VB .NET Express a little too well to actually make it a useful IDE Microsoft will send lawyers with threats to sue your ass.

Re:I sense a problem...

[oliderid]

I'm currently finishing an C# Mono application made with MonoDevelop.
To be fair, MonoDevelop doesn't even propose all the Visual Studio 2003 features.
But for an application with no UI interface, it does the job perfectly. If you are a Visual Studio user like me, this is the best tool you can find on Linux IMHO.

I have even developped a small Windows based client for this server application, again written with MonoDevelop and their Windows Form libraries that mimick approximatly all C# .NET methods and events. (there are still some problems with stuff like MonthCalendar and all, but I didn't need it, I just needed ToolBar and ListView). I tried other stuff like GTK but it was too different from Windows Form and I didn't have the time to study it.

It requires strictly no Linux skills. All you need is to download a distro like OpenSuse and MonoDevelop RPM and that's all.

Kate

[Anonymous Coward]

I am a Gnome user, but Gedit sucks for coding. I still haven't found a better graphical editor for coding.

Re:Need other things? Not really...

[metamatic]

Yup. If you write the code to have good logging and good exception handling, you'll rarely (if ever) need a debugger. This is especially true if you're using a modern language with automatic memory management.

As for profilers, they should be used once you hit beta, if at all. And even then, chances are you're going to use them in a very superficial way, to find out which chunks of code are taking the most time so you can see which algorithms might need replacing. Very little code these days needs the kind of call-by-call optimization that profilers will give you.

Re:I have to say this doesn't sound like a good bo

[Anonymous Coward]

> I can inspect a binary file better in emacs, as it prints non-printable characters as escaped ...

By the way, emacs also has a hexadecimal mode: M-x hexl-mode

Re:I have to say this doesn't sound like a good bo

[Lost Engineer]

There is no debugger superior to appropriate printing of state in the code. You are either crazy or you just really like to post on slashdot while your code recompiles.

Programmer efficency vs. hardware efficiency

[Tassach]

But most programs would be better off written in some other language, like Python or Perl

This needs to be repeated loudly and often. C/C++ is a great language, but there are only a very few instances where you really need to use it. C/C++ is optimized for making efficient use of hardware resources, CPU and memory in particular. On modern hardware, this is seldom the limiting factor -- you are far more likely to be constrained by I/O (network bandwidth / latency, database queries, etc). If you really need that kind of low-level control or cpu optimization, it's usually isolated to few critical functions -- the majority of the work that wraps those functions is better handled by a higher-level language. Writing an entire application end-to-end in C/C++ is usually a mistake

More importantly, most projects are constrained by PROGRAMMER TIME. A language that optimizes programmer efficiency rather than hardware efficiency provides a bigger benefit for the vast majority of development projects. Why write 100 lines of C or Java code when you can accomplish the same task with 10 or fewer lines of Perl, Python, or Ruby? Programmer productivity really soars when you have an easy-to-use repository of pre-written code modules like CPAN.

Re:Programmer efficency vs. hardware efficiency

[scotch]

"C/C++ is a great language"

No such beast.

Re:Programmer efficency vs. hardware efficiency

[Tassach]

C++ is a strict superset of C. A C++ compiler will accept any valid C program as input. (Or least this was the case 10+ years ago, which was the last time I wrote any C++ code)

Furthermore, any C++ code can be algorithmically decomposed into C. Recall that Stroustrup initially implemented C++ as a preprocessor (written in C) which fed it's output to a C compiler. (same caveat applies)

I've maintained a lot of "C++" code where the only thing that distinguished it from straight C was the use of cout and //, and even more "OO" code that had classes which did nothing more than wrap a C function or two. In my experience, there are a lot more programs like this in the real world than there are "proper" object-oriented C++ programs. YMMV.

. IMHO, because of these facts C++ should more properly be considered an extension of C and not a distinct language in it's own right. I'm sure many people will disagree with me, probably even Bjarne himself. I admit that it's a pretty fine distinction, however, and arguing about it is almost as pointless as debating whether vi is better than emacs. (it is)

If you object to the C/C++ notation (which is pretty widely used throughout the industry, it's not something I just pulled out of my ass one day), you can mentally transform it into

[C|C++]

if you prefer.

Re:Programmer efficency vs. hardware efficiency

[scotch]

C++ is a strict superset of C. A C++ compiler will accept any valid C program as input. (Or least this was the case 10+ years ago, which was the last time I wrote any C++ code)

You could have stopped writing after this (your experience being 10 years old). C++ is not a stict superset, but its pretty close such that it the missing overlap is not really a big deal in real programs (well, until C99, which adds a couple more things).

Furthermore, any C++ code can be algorithmically decomposed into C.

You can probably say the same thing about any language, they are still different.

I've maintained a lot of "C++" code where the only thing that distinguished it from straight C was the use of cout and //, and even more "OO" code that had classes which did nothing more than wrap a C function or two. In my experience, there are a lot more programs like this in the real world than there are "proper" object-oriented C++ programs. YMMV.

Well, // is in C99, so that codw was even closer to C than you let on. My mileage varies, of course, real C++ code tends to use more features than that.

D is similar to C and C++, and Java shares heritage and features with C++, and C#, again, is similar to C++ with some modest differences. Are all of these the same language?

If you object to the C/C++ notation (which is pretty widely used throughout the industry, it's not something I just pulled out of my ass one day), you can mentally transform it into

Well, I think that the C/C++ notation is unfortunate, but a sad fact of life. When it is used in a context where it could imply two (albeit related languages), I tolerate it. But not when the implication it that they are the same language.

Netbeans anyone?

[NoBozo99]

IIRC netbeans runs on linux platform fine and has addon for c/c++.
http://netbeans.org/

kdevelop

[mangu]

In my opinion, linux would be many times more successful if there were something more directly analogous to Visual Studio

Kdevelop is very close to VS in features, and much better than Eclipse for anything other than Java. I have done lots of development in C++, PHP, and Python using kdevelop.

It's hard to tell if it's kdevelop itself that's better, or if I'm comparing Qt with MFC, but for me at least, developing in kdevelop is several times more productive than in Visual Studio.

Besides, the fact that Qt is now very well integrated with Python brings even more productivity because we do not need to use C++ for GUI development. I don't know how well Visual Studio handles GUI development in Python, but I certainly do not miss the old days when I did develop for Windows using MFC and C++. Even better, there is PyQt for Windows, so you can do multiplatform development in kdevelop.

In my experience, the most productive platform for code development is a kubuntu machine with kdevelop creating Python code with Qt, using C libraries where needed. For integrating C libraries in Python I use swig.

Re:My Opinion

[Anonymous Coward]

lol i mean, you're so funny lol

i mean, your so funny lol

SunStudio 12

[Phatmanotoo]

I'm surprised nobody mentioned Sun Studio 12, which just came out recently. This time, the Linux release comes (for the first time) with its own compilers, instead of relying on gcc. It'll be interesting to see how they compare to Intel's, specially on AMD chips...

Re:Win32 dev bad? NOT for Delphi/Kylix & Win32

[maglor_83]

I can't stand the Delphi IDE. The Delphi debugger though is excellent, except for exception handling. Though its all personal preference anyway, plus I'm stuck using Delphi 7, which is a bit out of date now.

Re:What are the major differences, in your opinion

[aztracker1]

Well, you're comparing a VS version from what, 11 years or so ago, to a current version of Anjuta, or Eclipse... Honestly, I was a bit put off by Visual Studio .Net and 2003... 2005 is much better than any other VS version. Will probably try another Linux run before too long... I ran it for about 8 months as my main desktop last year, but switched back to XP, because 80% of my time was work related, and spent in a windows VM. Linux is a constantly moving and growing beast, though it would be nice to see some consolidation among some of the tools in Linux... Sometimes all the choices are simply *TOO* much to even have enough of a comparative grasp on to make a good decision.

There is the only answer!

[hotfireball]

Perl, Perl, Perl, Perl -- that is the only answer to everything! Bugzilla, DVD decoders, SSL, apache2.pm and a Tomcat -- all written in Perl! Even Windows 98 is written in Perl (Vista is just rewrite to C++ from Perl)...

*running away* :-)

Re:Win32 dev bad? NOT for Delphi/Kylix & Win32

[jma05]

You aren't really stuck. I use Delphi 6 and find no reason to upgrade. The later enhancements aren't exactly killer features. Personally, for what I do, I think Delphi 3 is quite adequate and I am fine with Wine performance.

No Debugger?

[chrismcb]

Anyone who claims they program without a debugger is either lieing, writing embedded code (or something that a debugger won't work with) or is a bad programmer.

Eclipse and Netbeans are excellent

[kungfujesus]

I highly recommend both eclipse and netbeans, they are great

Binary! Charge!

[WK2]

While the Windows programmers are used to taking deceptive comfort within the cozy confines of a Visual IDE, when they make the shift to write Linux programs, they are suddenly faced with the hard facts of programming as it really is.

True programmers only program in machine code.

Linux Programmer's Toolbox

[anwyn]

gcc including g++ if wanted. auto* tools. gdb. emacs. svn.

These tools do not have point and clicky sexyness; They just work. They are portable. You can even port to a winTurd OS, but only God would know why you would want to. They are all free as in freedom can be downloaded from the internet, and come with most GNU/Linux distros.

They were designed by programmers for programmers, without any care for what the suits might think.

They are complex in spots. But every bit of complexity addresses some real problem or issue.

Programmers that understand and use these tools, would not use any other.

If you can write better tools that replace all the features of these tools, please do so.

It isn't perfect and we've been there before

[dbIII]

Some of us are old, used stuff like "personal pascal" with it's highly graphical IDE and found that there was a lot of time wasting clicking things. We've seen it before and hit limits in the same places we would hit them today. When it comes down to it the code is text and fast and flexible text manipulation tools can work better than drawing some sort of abstraction that looks like a wiring diagram. We are the guys that will actually look at the source code of some "developers" that have only seen the GUI depiction and identify some problems in seconds the inexperienced that rely too much on the tools could not find. It is not that they use the GUI that is the problem, it is that they don't really know what the GUI is doing. Unfortuantely this comes off as elitism when you open the thing up in vim and the syntax problem stands out in bright red text and you have to remind them of something they were told to watch out for in high school.

As for VB and descendants with the same name that are very different - the lack of backwards compatibility and the difficulty of obtaining the source of even in-house applications should be considered more than a shiny GUI that repeat the flaws of 1990s graphical development environments. If you can't easily get it in text and change that one thing that stops it working today with a search and replace the environment is not paticularly useful. Keeping a machine stuck in late 1996 for one app to work and another in 1999 for a different app to work is annoying - virtual machines are a bandaid but environments the focus on fluff more than substance are the problem.

Re:I have to say this doesn't sound like a good bo

[GileadGreene]

As for printing state, depending on the system, printing may not be possible (embedded), or may throw off timing (or whatever) enough to make the problem go away...

To be fair, running a debugger on an embedded systems can cause just as many problems as state printing. In same cases more, since it can sssslllooooowwwww code execution. Depending on the embedded system, "printing state" can be a better choice - easier to get in to the system, and able to be targeted to a specific part of the system. Of course "printing state" in that case may not mean printf statements everywhere. I've used short diagnostic codes drawn on an NTSC display, bytes fired out an RS232 port, and logging to EEPROM, depending on the system. I've used debuggers too, but they've usually been more trouble than they're worth (I find them to be far more useful when writing desktop software).

My Tools

[Anonymous Coward]

For C, C++, Fortran and Python:

• Editor/IDE: Emacs + Xrefactory
• Compiler: various, as many different ones as possible (GCC, Intel, Pathscale, PGI, NAG, Sun)
• Debugger: Totalview
• Memory Debuging: Memscape/Totalview
• Build System: GNU Make + various scripts
• CVS

If the Fortran 9X support would be better, i'd use Slick Edit as IDE/Editor.

Recursive grep is also quite useful

[Chemisor]

When you have a large directory tree and constantly need to grep for stuff, you might find the following script useful. I wrote this last year after yet another round of typing complex find/exec commands. Basically, you give the script the search pattern just like to grep and it searches all source files in the current tree for it. Add the -v option and it automatically edits all the matches in vi.

#! /bin/sh
declare -i INREGEX=0
declare -i LEDIT=0
declare -a REGEX=
declare -a GREPOPTS="-H"
for i in `getopt -o vl -u -- $*`; do
    if [ "$i" = "--" ]; then
        INREGEX=1;
    elif [ "$i" = "-l" ]; then
        GREPOPTS="$GREPOPTS -l";
    elif [ "$i" = "-v" ]; then
        LEDIT=1;
        GREPOPTS="$GREPOPTS -l";
    elif [ $INREGEX = 1 ]; then
        if [ ! "$REGEX" = "" ]; then
            REGEX="$REGEX ";
        fi
        REGEX="$REGEX$i";
    fi;
done
 
if [ $LEDIT = 1 ]; then
    MATCHES=`find . \( -name '*.cc' -or -name '*.h' -or -name '*.c' -or -name '*.cpp' \) -exec grep $GREPOPTS "$REGEX" '{}' \;`
    if [ -z ${MATCHES} ]; then
        echo "No matches.";
    else
        vi ${MATCHES};
    fi
else
    find . \( -name '*.cc' -or -name '*.h' -or -name '*.c' -or -name '*.cpp' \) -exec grep $GREPOPTS "$REGEX" '{}' \;
fi

You got it wrong, ed is spartan.

[Anonymous Coward]

vi is madness.

Try reading The Pragmatic Programmer

[Anonymous Coward]

It's much more language-agnostic and focused on finding the way to do the job right. Take a look, though it does have a bit of that Agile infection.

Re:I have to say this doesn't sound like a good bo

[jd]

Ha! I'm far sneakier than that. I'm crazy AND I like to post on Slashdot whilst my code recompiles. :)

Look at the context of that statement

[benhocking]

If you look at the context in which I pointed out Knuth's warning, it is appropriate. They were talking about using tools to determine where an application spends all of its time. Also, note the use of the word "premature". Most people would not consider choosing your programming language up front "premature". (Yes, some would.)

What does optimization mean? Well, in this context he's referring to computer resources - memory, cpu (speed), disk I/O. "Premature optimization" in part refers to trading off code complexity for computer resource concerns. It also alludes to the fact that what you think is an optimization might actually end up using more resources. Anyone who has been programming for a significant period of time can tell you stories about cases like that.

What if I need to store a mapping between strings and integers? I could use a list of pairs, or a binary tree, or a hash table. The hash table is probably the most "efficient" of the three, depending on circumstances. But am I sinning by choosing it, when in theory a list of pairs could also work?

If you find using a hash table makes the code much more complicated (even if it makes it faster or use less memory), then that's probably premature optimization. Of course, a list of pairs would actually be more complicated, IMO.

"Don't prematurely optimize" does not mean the same thing as "Pick the slowest of all available techniques."

And here you seem to address all of the concerns you appeared to be raising. You're absolutely right, of course, but I don't know that anyone was suggesting otherwise.