What is the Ultimate Linux Development Environment? 643
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?"
You might as well ask... (Score:5, Insightful)
vim (Score:5, Insightful)
Its called emacs (Score:5, Insightful)
Regarding Debuggers, everyone should read (Score:4, Insightful)
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.
Re:You might as well ask... (Score:1, Insightful)
Which one?
Eclipse (Score:5, Insightful)
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.
Re:You might as well ask... (Score:4, Insightful)
Re:vim (Score:3, Insightful)
Vim is simply awesome, it's a daily rejoyce to work with it.
Every minute spent learning it's multitude of features will save you a hundred minutes with gained produtivity. And it never stops, you allways learn a bit more everyday. There's nothing it can't do, you just haven't learned it yet. If you're lazy to study it's excelent documentation, just ask at vim@vim.org or #vim.
It's in the top five best software ever, along with:
- Linux, for saving my soul from Windows;
- LaTeX, for saving my soul from Word;
- Quake, for endless fun with my friends;
- Screen, to master the text terminal environment.
Personally... (Score:5, Insightful)
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 :)
Understanding and Navigating Code (Score:4, Insightful)
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?
In the least popular opinion... (Score:3, Insightful)
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.
Visual Studio 2005 (Score:4, Insightful)
Don't write off simple tools until you know them (Score:5, Insightful)
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.
Re:Personally... (Score:5, Insightful)
In what way is it more "in place" to click on different tabs in a terminal window versus clicking on different sub-menus in an IDE?
An IDE is typically just a collection of specialised, tiled windows with some menus and buttons up the top. The specialisaton of each window has a downside in that it wastes precious screen real estate when you don't happen to be using those specialised functions. Personally, I prefer to be able maximise my code window and keep all the other junk out of the way as I find that maximises my productivity.
While a well designed IDE can help they are overrated as productivity boosters. Most of the productivity gains come not from the IDE per se but from the various tricks, noted by other posters, incorporated into it. Non-IDE programmers have their own bag of tricks e.g. Often writing small scripts to accomplish some repetitive function that might not be anticipated by an IDE designer, or taking advantage of a full OS of command line and GUI tools that an IDE can only dream about. Most IDE's have external tools functions but they are usually badly integrated.
---
Don't be a programmer-bureaucrat; someone who substitutes marketing buzzwords and software bloat for verifiable improvements.
Re:You might as well ask... (Score:3, Insightful)
Re:SlickEdit (Score:5, Insightful)
I suppose I could get work to pay, but that doesn't help me at home (no, I don't illegally copy software).
Obvious answer to all such questions (Score:5, Insightful)
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.
Re:You might as well ask... (Score:4, Insightful)
The difference between a religion and a cult is in the beliefs of its leaders. In a religion such as Catholicism, as you go up in the ranks from the lowly follower all the way up to the Pope, the devotion of its members increases. In a cult, it decreases, because its leadership sees the teachings for what they are: a means of control. Furthermore, whether you believe the teachings of a given religion yourself or not, its leadership believes they are acting in the spiritual interests of its followers. They believe they are bettering their members.
However, in both cases the rewards for being a member increases, and for a cult, this works like a pyramid scheme, siphoning wealth into the upper ranks. So yes, there is a fundamental difference between a "religion" and a "cult", other than the number of followers. Scientology is a prime example today: it was a cult when Hubbard was sailing the Mediterranean under the Sea Org flag, and it's still a cult today.
Re:Don't write off simple tools until you know the (Score:4, Insightful)
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.
found your problem (Score:5, Insightful)
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.
Re:Regarding Debuggers, everyone should read (Score:2, Insightful)
What the grandparent means is that if you can't sit down and just type in your code without a bunch of IDE help, you probably aren't ready to start coding yet. You need to refresh yourself on the APIs you're using, sip some coffee, think about the code you're going to write, and get it right the first time. It's hard to maintain that discipline, and IDEs make it harder. If you tend to be less careful than you should (and don't we all?), using an IDE is like an alcoholic living across the street from a liquor store.
OTOH, much commercial coding is done on a trial and error basis. Why bother trying to get something exactly right when the API documentation you're using is unreliable, your boss cares how fast you do it more than how well, and you won't find out what you were really supposed to implement until you've delivered the first version anyway? Under those conditions, you might as well use a tool that lets you spew the code out as fast as possible, because that's the optimal behavior.
Seriously, I think the usefulness of an IDE depends on what you're doing. If you're doing simple modifications of a large codebase that uses many large APIs, then an IDE is handy for navigating all that stuff. If you're doing difficult, critical work that depends on a small or nonexistent set of external APIs, then a text editor will keep you honest and not help you code when you aren't ready yet.
editing 20+ files is not hard (Score:3, Insightful)
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.
Re:Don't write off simple tools until you know the (Score:4, Insightful)
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
Its called vim (Score:4, Insightful)
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.
Re:You might as well ask... (Score:5, Insightful)
Thankfully, popes and antipopes all had the best interest of their followers at heart.
I guess Heaven's Gate was a religion since Marshall Applewhite believed strongly enough in it to save his followers' souls and his own soul by committing suicide so they could get on that UFO. After all what is earthly flesh compared to the eternal soul.
The difference, a religion been around long enough that people forgot it was a cult.
I'm sure when Christianity started that people said it was a cult. After all, a lot of people didn't immediately recognize Jesus as the Son of God.
I'm AC because it's bad enough talking religion with friends let alone complete strangers.
Re:vim (Score:3, Insightful)
Re:If you must... I must (Score:3, Insightful)
Re:You might as well ask... (Score:1, Insightful)
The Ultimate Linux Development Environment (Score:3, Insightful)
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.
Re:You might as well ask... (Score:3, Insightful)
Actually there is a 'sect' of Judaism that considers itself to be both Jewish and Christian (i.e. they're jews that consider Jesus to be the Messiah). Given that Jesus and the first generation or two of deciples would have fit in this definition, I'd say that they'd have to classify as Christian -- Unless you want to consider St. Paul and the other apostles as non-christian (not to mention Jesus, himself).
KDevelop (Score:2, Insightful)
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.)
GNAT Programming Studio (Score:2, Insightful)