Slashdot Mirror
What is the Ultimate Linux Development Environment?
nachmore asks: "I've been programming on Linux for a while now, always content to use vi for my editing and any debugger tools out there (gdb for C/C++, and so forth). As part of my SoC project I was working on Thunderbird (my first huge project on Linux) and I found that , although shell-based tools can do the job, they lack in easy project management, ease of debugging and other development features. I've only ever programmed with a GUI on Windows — and I have to admit that I find Dev Studio to be one of the few programs that Microsoft seems to have gotten (nearly) right. I've played around with Eclipse but find it's C/C++ support still lacking. So what GUIs would you recommend for Linux? I would like something with debugging (single step, step through, step-to-end, etc) support, CVS access and of course, support for large projects (e.g. Mozilla) and especially good support for C/C++. Is there anything really good out there, or is vi the way to go?"
...which religion is best.
vim 7 + cscope == awesome
thisnukes4u.net
emacs has all of these features that you are asking for: front-end for gdb enabling highlighting in source code for debugging, integrated support for source control including CVS, and incredibly good support for C/C++ syntax highlighting/editing. If you are coming from vi, you can even change the default keybindings to vi-style bindings.
The best environment in Linux - as with on any platform - is a text editor and a solid mind that thinks the problems through before typing. IDEs inhibit that thought process.
Care to enlighten us on what was lacking with Eclipse and CDT?
My only real complaint is the large times it takes to recompile large projects. Slow indexing/parsing times for large amounts (1000+) of files are a given however for any type of tool that is going to cross reference new projects. However, if I have control of the project extraction of projects into logical subcomponents rather than editing huge single projects with Eclipse/CDT will give you a very nice time speed up.
A personal fave is that the debugger integration in eclipse is second to none.
By preference I use zsh, vi and make.Screen or multiple terminal windows (aterm by preference). Depending on the task and the requirements, GCC/gdb/ctags or perl/CPAN or boo+nmake+nunit. Throw in find grep and all the usual suspects in support. Tools with a command line interface preferred over ones without, commands that read from stdin and write to stdout by default perferred over others. Special exemption made for browsers and drawing programs.
If the structure of an application is too complex to manage under a unix command shell, that's a reflection on the design of the app in my book. I don't expect that's going to be a widely held viewpoint around here. Never mind, it works for me :)
Don't let THEM immanentize the Eschaton!
Tool choices are clearly an issue of personal taste. And as my tastes clearly don't match yours, I won't be making any suggestions.
But I will say that, without exception, all the best developers I've known in my career (yes, every single one of them) work with a text editor and a shell window. They use GUI and web tools where needed or useful, but their minute to minute activity is spent at the keyboard, writing, running and reading code.
I submit that this is not a coincidence. The best developers write their own simple tools for small problems, and the proper environment for running simple tools is the command line. Great programmers work in varied environments and use diverse languages and configuration formats, where IDEs work well only within their target realm and are pretty much useless outside of it (e.g. no PHP mode in MSVC).
The benefit you get from fancy tools is real, but it's ephemeral. It make the typing of code (and maybe the reading of code) easier. But it does this by simplifying and obscuring the underlying details. Want to add a file to the project? Add it to this dialog. Need to check something in? Click here. Never mind how it all works, and hope that you never get tasked with doing something complicated (like an automated check-out-build-and-package script over a secure remote link).
By contrast, the understanding inherent in using your tools on the lowest level provides benefits all through the development process. These are the folks who won't think twice about writing a quick shell script to do the remote build.
So, by all means try out the fancy tools you can. But don't skip the part where you learn how to use the underlying tools well. Use the GUI stuff as an aid for the tasks you do understand, not as a substitute for what you don't.
It might be really slick, but at almost $300.00 for a single user linux license, it's not just a tad on the expensive side.
I suppose I could get work to pay, but that doesn't help me at home (no, I don't illegally copy software).
Stupid sexy Flanders.
When it comes to FOSS there is no Ultimate, Best, Top, Only, or other perfect solution.
There are MANY excellent solutions which provide different pros and cons, to be considered by the potential user.
You must be recently freed of Windows where you are simply told what you want, here in the world of FOSS you have choices.
Reminds me of a lady who came to the US from Russia some twentyish years ago, when she saw a grocery store with CHOICES she flipped, couldn't handle the concept.
-Tim Louden
Rethink your desktop, abandoning the Windows-like defaults you were given. Do like the UNIX workstation users. Example:
Put a thick (50 to 60 pixel) gnome task bar at the bottom. Eliminate the one at the top. Put a 5x2, 4x2, or 3x2 virtual desktop selector thing on the task bar. Set your window policy to the traditional UNIX-style focus-follows-mouse. Never ever minimize, maximize, or roll up a window; simply spread them across the virtual desktops. You should use the traditional xterm, white on black, with the default font. (80x70 characters is good) A sharp LCD (native resolution, digital connector) is strongly suggested, at a minimum resolution of 1600x1024. Choose a fast-starting editor: original vi, joe (like WordStar), microemacs, or even (ick) pico. Linus uses microemacs; the source is on the kernel.org site probably under the name uemacs. Never use the file manager or file selector if you can possibly avoid it.
That's what the real hackers use, at least when the hardware is available. It's an upgrade from the "screen" program or the Linux console virtual terminals, without much change to the tried-and-true work habits.
You don't have to go with that exactly, but it's clear that your current setup isn't working for you. An IDE is a workaround, not a proper fix. An IDE only helps with one very specific task. A proper fix will make you more efficient at many other tasks. You might even start to like the gimp (zillions of windows instead of tabs) or set your web browser to open windows instead of tabs.
BTW, learn the extra tools. Valgrind usually whips gdb. You may also like ltrace, strace, nm, eu-readelf or readelf, oprofile, etc. Rarely will you find an IDE button to make these tools run. Learn the shell, really: you can do loops right on the command line, backtick substitution, etc.
That's my experience too, actually. And it's also the way I worked back when I pounded code for a living, working with (actually working around) the big Rational APEX IDE, this on a project with well more than its fair share of studly coders.
I also fully agree with those who have emphasized code reading/understanding as the critical activity in software development. Things like ctags were a really important development. At the same time, I've emphasized the readability of the running text itself. I've heard some advocate that "the IDE will locate cross-references, etc for you" implying that all developers will have equal access to the IDE -and- the IDE will be fail-proof in finding cross references/relevant related information through its own code understanding. Rather, I think that the one-and-only thing you're guaranteed to get in a maintenance situation is the source code, so source code must stand alone in its ability to be understood.
dave