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!
Given a large codebase that you are unfamiliar with, it's hard to start understanding the code with just Vi. It sounds like your ideal environment would allow you to pull a Mozilla project file into something like Eclipse or VS or KDevelop and have everything parsed out into structures, functions, methods, classes... You're not going to find that with the way Mozilla is built (at least the last time I checked). I think KDevelop does have the ability to parse autoconf files and set up a project that way, so you might be able to pull in parts of Mozilla that way. I think Anjuta might have a similiar ability.
I've since moved on from C/C++, but last time I checked the Eclipse CDT was getting a lot of work done on it. What is the problem with it these days?
Agnosticism. (ducks)
Though, actually, that's not far from my recommendation. Learn a bunch of different stuff. Learn vi and emacs, they both have their place. Spend some more time with Eclipse, I'm curious as to what you found lacking there? If you still don't like it kick around some of the other Linux IDE's. Hell even if you do like it kick around some that look appealing. Try some different frontends for gdb/vim/emacs/etc./etc. Just like anything, different tools are appropriate to different projects, and if you don't get too stuck with one (as seems to be the sad state of affairs for many here) you won't find yourself in the frustrating situation of trying to put in a nail with a screwdriver or hammer in a screw.
To fight the war on terror, stop being afraid.
Visual Studio 2005 just rocks.. I only wish there was something remotely similar for Linux.
-- -- Warning. Do not stare directly at the sun.
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
When a tool provides me a better view of how my program works, it's worth using.
No offense, but if you need a tool to tell you how your program works, you've got bigger problems. Even in multithreaded code, with sufficient diagnostic output, you should be able to solve any bug. In all my time as a developer, I have yet to come across a bug that can't be solved by developing a mental model of the code (usually with the help of extensive telemetry) and working through things logically.
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.
I do this all the time, using a simple editor which is similar (text-only, fast-starting) to vi.
I just open 20 or more xterm windows.
Probably that seems insane to you. It is, if you don't free yourself from the Windows-style desktop. I can deal with dozens of windows with little effort by setting up a traditional workstation-style environment:
a. focus-follows-mouse, not click-to-focus
b. never minimize, maximize, or roll-up
c. 6 to 12 virtual desktops (use them all)
d. never use the GUI file manager or desktop icons
e. traditional xterm, white on black, default font
You'll want a native-resolution LCD (digital connector, not VGA connector) of at least 1600x1024. Go with 2560x1600 if you can afford it.
BTW, if you really need to actively edit all those files, see if the task might be scriptable. The sed and awk commands are great. You can use perl too, right on the command line instead of with a script file.
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
Conversely, vim also has all of these features and more. If you're coming from emacs, you can set vim to use emacs-style keyboard bindings, if you wish. Some emacs-style completion is supported by default.
My colleagues and I had an all out war (emacs vs. vim). In the end, we discovered that they are both just as feature complete and able to emulate each other quite well. Emacs could be a tad more efficient, as it requires more RAM, disk space, and CPU time than vim. It's a non-issue if you have enough resources. For us, it was an issue (flash drive).
In any case, if you are willing to invest the time to master either emacs or vim, I think you'd be best served. Graphical IDE's are often easier on the eyes, but I've yet to find one as customizable. All the features you'd ever need can be had in either of these two editors and they really are superb at what they do.
Regarding Visual Studio and Microsoft programming in general. I use Visual Studio when writing code for Windows, but I dislike it for one of it's major strengths. I have heard it said that very few people really understand WIndows, and that most Windows programming is an exercise in cutting and pasting bits of code from a book, or the web, or whatever. There are several things I hate about Visual Studio. The first is the project wizards. They ask you a bunch of questions about the program you want to write, then generate 28000 lines of code. When compiled it has the look and feel of a windows program. A menu, populated with submenus and everything. That's the good news. The bad news is that you have to sit down and comprehend 28000 lines of code before you can take the next step. Assuming you still remember what the program was supposed to do. You immediately have a todo list of hundreds of things and you only just got started. You are already way behind. The second thing I hate about Visual Studoio is the Class Wizardry. If you really do understand Windows, you can sit down and hit a thousand buttons in a row, and write a complete program. I believe there are some people who can do this, but I never met them. What I hate the most about the wizards, is that their functionality is inscrutable. They touch a thousand things behind your back, and speaking of back, you can't back up. Using wizards is a one way deal. If you do need to back up, that usually means changing parts of the code by hand, that screw up future use of the wizards. Then there is the problem that the projects settings are kept in binary files, and there are so many binary files in a project, that its difficult to use source code control tools with any comfort. That's why I still enjoy programming with Makefile at the command line over using the Microsoft IDE. I know it's powerful, but too powerful for me. VS IDE is hooked right in to their knowledge base, but most of the knowledge base talks about ancient history like millenium edition or Windows 95. The minute you start using VS, the list of things you don't know starts expanding exponentially. I think I have said enough. Does anyone else have an opinion about something better?
I personally find that IDEs make it far too easy to navigate around the code base, preventing me from ever really learning how things fit together. If you can memorize how things fit together from within an IDE, more power to you. I also feel that it's important to be able to perform various tasks without an IDE because eventually you will find yourself in a situation where you are not able to use the IDE (Going to the desk of a co-worker who doesn't have the IDE, working on a customer's site with whatever software they decided to provide you. etc) and if you don't know how to do things outside the IDE then you're pretty much lost. If you use the IDE as a crutch to avoid learning the tools that are available on the system, perhaps a career in marketing and sales would be more your speed.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
1. It Works
2. Qt
3. You can use Embedded Vim if that's your thing
Reasons enough for me never to come back to the stone age.
OTOH, if you can live with Emacs, it can be used as an IDE. (And an distro, too.)
Making laws based on opinions that stem up from false informations leads to witch hunts.
https://libre2.adacore.com/gps/main.html