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...

[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...

[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.

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.

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

[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

[Doctor Memory]

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

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

[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.

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

[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

[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

[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...

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

[Zygamorph]

Shouldn't it be:

and in the darkness bind them : *ld*

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

[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

[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.

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: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?

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.

After strange aeons, even Death may die!

[Number6.2]

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

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.

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.

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

[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

[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

[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

[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.

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.

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.

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.

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.

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.

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: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: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.

Re:Depends on the project

[OutOnARock]

You say that as if it were a bad thing.

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: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?

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...

[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!

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.

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: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.

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).