Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Book Reviews Books Media

Linux Programmer's Toolbox 241

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.
This discussion has been archived. No new comments can be posted.

Linux Programmer's Toolbox

Comments Filter:
  • by Mockylock ( 1087585 ) on Wednesday June 13, 2007 @02:47PM (#19495183) Homepage
    And a true hate for Windows OS.
    • And a bar of soap.

      (yeah, right)
    • by SloWave ( 52801 )
      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: (Score:3, Interesting)

        by Yoozer ( 1055188 )
        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: (Score:3, Interesting)

          by jlarocco ( 851450 )

          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 t

    • Then it takes a stick of bubblegum (actually, just the wrapper), a shoelace and a pair of toenail clippers.
  • 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

  • A good IDE (Score:2, Funny)

    by jrwr00 ( 1035020 )
    I wish linux did have a great IDE, but i guess Emacs is good enough :)
    • by $RANDOMLUSER ( 804576 ) on Wednesday June 13, 2007 @03:27PM (#19495813)

      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.
    • by MobyTurbo ( 537363 ) on Wednesday June 13, 2007 @03:41PM (#19496033)
      Emacs would make an excellent operating system, if only if it had a good editor.
    • 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.
      • by bberens ( 965711 )
        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?
        • by NialScorva ( 213763 ) on Wednesday June 13, 2007 @06:11PM (#19498255)
          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.
  • IDE for Linux, yup (Score:3, Informative)

    by jshriverWVU ( 810740 ) on Wednesday June 13, 2007 @02:51PM (#19495265)
    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: (Score:3, Interesting)

      by dvice_null ( 981029 )
      > 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/ [codeblocks.org]
    • by Constantine XVI ( 880691 ) <trash DOT eighty ... AT gmail DOT com> on Wednesday June 13, 2007 @03:09PM (#19495551)
      Eclipse also does Python and C++ via plugins (pydev and eclipse-cdt respectivley)
    • Java use Eclipse.
      Eclipse also does C/C++ if you install the "CDT" (C/C++ Development Tools) plugin.
      • 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
    • by LWATCDR ( 28044 )
      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.
      • by jma05 ( 897351 )
        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?
    • by j00r0m4nc3r ( 959816 ) on Wednesday June 13, 2007 @03:28PM (#19495831)
      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!"
      • 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!).
        • 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.
      • 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.
      • by jgrahn ( 181062 )

        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 p

      • by finiteSet ( 834891 ) on Wednesday June 13, 2007 @05:00PM (#19497371)

        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.
      • by insignificant1 ( 872511 ) on Wednesday June 13, 2007 @05:19PM (#19497655)
        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: (Score:2, Funny)

      by bmk67 ( 971394 )

      Linux doesn't have a comprehensive IDE
      UNIX/Linux is a comprehensive IDE.
    • by twitter ( 104583 ) on Wednesday June 13, 2007 @03:58PM (#19496333) Homepage Journal

      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.

  • Blulhsit (Score:3, Interesting)

    by DoofusOfDeath ( 636671 ) on Wednesday June 13, 2007 @02:54PM (#19495301)

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

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

    • by jgrahn ( 181062 )

      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: (Score:3, Insightful)

      by SLi ( 132609 )
      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 s
      • by Tassach ( 137772 ) on Wednesday June 13, 2007 @06:16PM (#19498329)

        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.

  • My ToolBox (Score:5, Funny)

    by warrior_s ( 881715 ) <kindle3@gm[ ].com ['ail' in gap]> on Wednesday June 13, 2007 @02:57PM (#19495367) Homepage Journal
    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*
  • by Ngarrang ( 1023425 ) on Wednesday June 13, 2007 @03:01PM (#19495423) Journal
    "...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.
    • 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)
    • 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...
    • Re: (Score:3, Insightful)

      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 environm

    • by CodeBuster ( 516420 ) on Wednesday June 13, 2007 @04:57PM (#19497343)
      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.
      • by bit01 ( 644603 )

        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, scr

      • kdevelop (Score:5, Informative)

        by mangu ( 126918 ) on Wednesday June 13, 2007 @06:30PM (#19498529)
        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.

  • My tools (Score:3, Informative)

    by ggambett ( 611421 ) on Wednesday June 13, 2007 @03:06PM (#19495491) Homepage
    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 :)
  • 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 regurgitatio
  • * 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...)
  • A few tools... (Score:5, Informative)

    by Savage-Rabbit ( 308260 ) on Wednesday June 13, 2007 @03:33PM (#19495907)

    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.
    • by bfields ( 66644 )

      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' | xarg

  • by jd ( 1658 ) <imipak@@@yahoo...com> on Wednesday June 13, 2007 @03:40PM (#19496003) Homepage Journal
    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.


    • 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: (Score:3, Insightful)

        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

  • Source control! (Score:5, Insightful)

    by eli173 ( 125690 ) on Wednesday June 13, 2007 @03:50PM (#19496215)
    Ask a professional programmer, and a good source control system should be high in the list.
  • ...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 "in

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

  • XEMACS, EMACS, KDEVELOP, Glade, hmmm... all I got to say is N00B!
  • 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.
  • by Tim Browse ( 9263 ) on Wednesday June 13, 2007 @05:16PM (#19497615)

    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.

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

  • 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

What is algebra, exactly? Is it one of those three-cornered things? -- J.M. Barrie

Working...