Slashdot Mirror
What Free IDE Do You Use?
postermmxvicom writes "I program only occasionally and mostly for personal interest. I went to update my favorite free IDE, Dev C++, yesterday and noticed that it had not been updated since 2005! I went looking for other free IDEs and came across Code::Blocks and Visual Studio Express. I work from a Windows machine, use C++, and make mostly console apps; but have written a few Windows apps and D3D or OpenGL apps. I wanted to know what free IDEs you use and recommend. What do you like about them? What features do they lack? What about them irritate you (and what do you do to work around these annoyances)? For instance, when I used Visual C++ 6.0 in college, there was an error in getline that had to be fixed, and the code indenting in DevC++ needed to be tweaked to suit my liking."
I don't mess with C++ often but I still use Dev C++. Code::blocks wouldn't even install on my machine(or maybe it did, but never started up without a fatal error, can't remember which) and Visual Studio Express is a monstrosity which will take 45 minutes to install tons of weird crap while making your monitor flicker. Visual Studio express also allows only one programming language.
Contrast those with Netbeans and Eclipse which are known as Java IDEs but can be configured with plugins and add-ons to do all kinds of stuff, including C/C++ development. I haven't tried either of the two for C/C++ but I believe that Eclipse would be a the good middle ground between Dev C++ and the bloated NetBeans.
Here's[PDF warning] a good place to start. Good luck.
What else would you need?
I like Eclipse as an IDE because it supports many languages/modes and is very customizable. I mostly use it for Java, Perl and HTML/XML/CSS right now. There are MANY plugins and the context-aware help/auto-complete is very well done.
Keep in mind that VC++ is not the Microsoft Platform SDK. These are two completely different, albeit related, products. The SDK had a bug in getline(), but VC can't really do anything about the quality of the installed SDK.
The best free IDE is the one that you don't have to think about, it just gives you the tools to do your job without getting in your way.
My in-laws have a Mercedes. On the infrequent opportunities I have to drive it, I am always amazed at how well it supports my driving. It is the little things like rotating the headlights into a turn, actually automatically switching into neutral when the car comes to a stop, and auto-dimming rear view for night driving that make driving it a pleasure.
version 7.0 RC5 came out 2 months ago.
Wiki page with link
As long as you don't piss yourself in disgust when Microsoft is mentioned (as many here do) - Visual Studio is actually very good.
I'm sure lots of people are happy with emacs.
I'm sure lots of people are happy with American cars too, but we have objective standards for a reason.
If you're writing 10,000 lines in a single file regularly, then your probably need to re-evaluate your coding methods (and you're probably not writing "good stuff"). An IDE does more than just allowing you to fill a file with many lines of text, it keeps your 10,000 lines over multiple files organised... and you know... a huge number of other helpful things (code-completion/etc).
If you're writing 10,000 lines in a single file regularly, then your probably need to re-evaluate your coding methods
Word wrap is deceiving. I only wrote 5 lines of code. They are just very long lines.
I don't think the parent's point about handling 10k lines of code has to do with with ability to load these files into memory but rather about managing the complexity of such projects. When a program becomes this big, it becomes harder to keep track of all the names of variables, the argument types of subroutines etc. IDEs like Netbeans or Eclipse have autocompletion functionality that make your life as a developer at lot easier.
It's possible of course that Emacs or vi provide similar functionality but the main point is that you need some type of IDE when managing a large, complex development project.
I've been using NetBeans lately for C/C++ development, and (for the most part) it has it's usual awesome editor features. Unfortunately, the C/C++ plugin only works with the Cygwin/MinGW development tools on Windows.
I'd say that it's most useful editing feature is it's code completion- it completes quite a few of the usual syntactical characters, and it enters them for you in a way that makes sense. Compare that to Eclipse, which only fills in (as far as I know) parenthesis and some brackets. Being accustomed to the completion NetBeans offers, I found the way Eclipse completes characters to be more frustrating than helpful.
For example, if you have this mostly-typed statement (')' autocompleted by editor):
...you might think that pressing the ';' key should make the cursor jump to the end and skip over the ')'. NetBeans will do the small things like this, where I haven't seen Eclipse do it.
some_function(something()[cursor])
I haven't used Eclipse as much as NetBeans, so I may have missed the "turn this feature on" checkbox, but I've always found NetBeans to be a more intuitive editor. I'm not an expert C/C++ programmer (Java is my main language), so I could just be making assumptions that may be true for one language but not another. Either way, its just my $0.02.
If anyone says Emacs or Vi they are insane and have never done 10k lines of code in a modern environment.
Hoping that I'm not about to start a flame war: why?
I assume you're qualified to make that statement, which means you know both emacs and vi very well. Whenever you think there's something $EDITOR can't do, you have (1) searched the web for that functionality; (2) asked in the relevant IRC channel(s); and (3) asked on mailing lists, news groups, forums and the like.
Let's see; they have (I'm most certain that I'm speaking about emacs, less certain about vi)
Uhmm... what more do you want? Especially for small 10k-line projects. Example: wminput, which translates wiimote events to uinput events, is 9236 lines (in wminput/**/*.[ch]; this doesn't include bluetooth or wiimote libraries).
I think that if you think 10k lines even begins to stretch the capabilities of emacs (or vi), you don't know either editor very well. And you can probably find people who'd point at me and laugh (and suggest I don't know the editors very well) when I suggest that 10m begins to stretch their capabilities ;-)
And I think they'd have a good case: at 10m lines, it's not a question of good editors but of good architectures. Good architectures will allow each developer to work on somewhere between 10 to 100 klocs at a time, not worrying about anything outside their slice of code (until they move on to their next project). [But this is wild conjecture, so take it with a bucketload of salt...]
* pronounced "a(rrrrrhhhhh)ida", like how Stallman pronounces the chi in "LaTeX" and "TeXinfo" or ch in "Bach". I'm not sure about spelling. Search Google tech talks for Bram Molenaar if you really want to know (and hey, it's a nice talk in its own right).
If anyone says Emacs or Vi they are insane and have never done 10k lines of code in a modern environment.
While the handling of Vi or Emacs actually *is* breathtakingly bizar and unwieldy, what you're saying is not correct. If someone actually takes the time to learn to use Emacs and the extensions it offers for developement - which can take a few years - it can be the most powerfull and fast IDE out there. And it opens files upwards of 40 MB (that's Megabyte) in half a minute and then you can navigate around them with no delay at all. That league of performance is the reason I started using it. In terms of performance Emacs is the most powerfull IDE on the planet.
Then again, I started using Emacs 3 years ago - after briefly considering the purchase of Macsperts new darling child TextMate, basically a modern Emacs rip - and I still can't bear it for longer than 10 minutes - mostly because it so totally doesn't comply with CUAS (Common User Access Standard). Yet then again, Emacs was created when CUAS didn't even exist, so that's no fault on behalf of Emacs.
Bottom line:
If you are willing to invest months (!) of time actively learning an IDE, the cli version of Emacs will be with you until the day you die, as it runs well on everything that uses electricity. Up from the most powerfull supercomputer using the most bizar unix variant right down to a 10-year old handheld PC.
We suffer more in our imagination than in reality. - Seneca
Bollocks: Ctrl-x b. For us emacs-users, it's second-nature.
The reason why so many people still prefer vim or emacs is that we can do everything efficiently using the keyboard only. Coding, switching files, compiling, debugging, everything. And we can do that on our own computer, or on one on the other side of the world with merely ssh and the command-line editor of choice.
You might think that something as simple as switching between files isn't trivial in vim/emacs, but that only shows that you haven't learned either. You can point and click all you want, but programming isn't done with a mouse.
This sig is intentionally left blank
What more does anyone want?
The efficiency that is gained by not having to move your project through 20 different tools manually?
In other words, the INTEGRATED part of "IDE".
I don't know about emacs, but in vim I can open multiple windows at a time (not to mention multiple buffers!), and switch between them rather effortlessly.
Look, most of use defending vim and emacs are not saying that it is impossible to use an IDE to be productive; just that it isn't necessary. I certainly believe that each person should work with whatever tools they feel comfortable.
However, the "IDE kids" keep categorically rejecting the notion that you can be productive in anything but a large, bulky (and yes, maybe even bloated) integrated system. They would do good not to be so narrow-minded.
I've used both and, although I see value in some IDEs, I personally prefer using the leaner, smaller tools. Sometimes all those windows and automatic wizards and code injectors just get my way.
-dZ.
Carol vs. Ghost
too awk ward
I tried using Visual Studio at work, and was frustrated with the amount of effort it took to create and configure a project
Maybe you're incompetent.
I thought people preferring GNU make did so due purely due to availability or having all their experience with that - but if I read you right, you say you actually have deep experience with both and still prefer the GNU variant?
I used BSD make ~10 years ago and only very shortly. So I can't really opine on it.
GNU make is often pain, but with careful planning it's getting the job done. But from my experience I would admit that GNU make has enormous capacity to confuse and freak out people. Lazy evaluation isn't for everybody. I probably should be considered GNU make profi, as I have read through its documentation numerous times already. That further precludes me from commenting on BSD make.
I personally prefer (and use for all my pet projects) GNU cons. It's simple and perl based. (N.B. There is also SCons which is Python based. At times slower than cons, but has more features and more portable.) Cons is pretty much only known to me solution to retain sanity on large projects: built-in dep checker, built-in installation support, proper dependency handling for static libraries, built-in object caching, support for commands having multiple products, etc. But the main goal of cons (and what I love it for most) is to guarantee consistent builds: unlike make(s), cons uses MD5 to check whether the source have changed. (Though can be reconfigured to use timestamps). Takes time to get used to, but is really worth it.
All hope abandon ye who enter here.
Sounds like you've never found an IDE that suits you. I've tried using the vim + gdb + strace type of development and gotten along just fine, but when you find a decent IDE with a good debugger, stack trace, good search facility, debug probe and a ton of other helpful tools it's hard to go back to messing around with lots of separate ones. I think it's important to be able to use the separate utilities to get a project done, and understand what you're doing with them, but why make life more difficult if you can get something that's integrated and does everything you need in one place?
Try to stop being so suspicious of people who like to work differently to you. It's likely they know how to use the tools you use but prefer an integrated environment to get their work done. Not everyone using an IDE is using it because they want their hands held. Those that do won't be using their IDE properly anyway.
Silly rabbit
Strangely enough, you're not the first person I've seen who's sed that.
For newbies and people who cannot touch type, yes. For professional programmers, not so much.
Spoken by someone, who very obviously, has never taken the time to learn the ins and outs of a good IDE like Eclipse or VS. There's no argument here. If all things are equal, ie you know both methods the same, and IDE is SO much faster to work with that it's not even close.
You'll have that sometimes...
Vim with Exuberant CTags, GNU tools and a little self-education comprises a fully featured IDE.
The reason so many use and keep using Vim as an IDE, even for large projects is that they can roll together the toolchain - including debugger, profiler, code browser - and builders that suit them, in the way that suit them. Much of the time the people that complain that Vim cannot function as a full featured IDE seem unaware of Vim's shell interface (:!<program> <args> && <program2> <args> [..]) or its 'plugin' architecture, let alone tabs, split modes, keyword completion, folding or numerous other features typical of other IDEs.
A single terminal hosting Vim is enough to comfortably develop large projects in almost any popular language, covering coding, compiling, debugging and execution. Having worked a lot with the awfully bloated and manifold XCode, the sprawling and mysterious Visual Studio and a little with the rather nice Code::Blocks it's clear that I have no reason to consider changing IDE, for the time being.
As much as I enjoy using bash for the things it's best at, you are showing the blind spot that irritates me most about open source evangelism and UNIX purism.
That is the mistaken 100 tools that do the same thing (and more) as one single specialized program are just as good as having a single program custom tailored to your tasks. With that sort of attitude, nobody would ever have written "make" in the first place, let alone all those automated tools to write makefiles.
For that matter, "bash" would never have been written because "sh" can already do most of the same stuff and commandline tools and cleverly written shell scripts can make up the functionality, right?
I think by now, if you're reading this at all, you're scowling and looking for something to disagree with.
The point is that sh and the dozens of powerful commandline GNU tools based on the great old stuff that was written for UNIX are still useful and relevant today, but they're not the only thing that is useful and relevant today. Sometimes you just want a single tool which does the job and gets out of your way with the least amount of effort. That doesn't make you stupid or lazy or childish, or everybody who's using bash right now needs to grow up.
If you have to spend 5 minutes writing a command with 12 pipes and output redirection through 13 programs which duplicate a functionality I get from a single checkbox in, say, Visual Studio, then you're not working efficiently. And merely because I choose to skip those steps does not mean I have no idea how to do them - I'm a professional UNIX system administrator as my day job.
The point is that although practice makes perfect, familiarity breeds contempt. When I get home to code on my own projects, I'd prefer not to have to write makefiles, build scripts, hand compile everything, edit out of a single window so I never forget to save anything, and constantly search for line numbers in a lousy no-syntax-highlighting no-code-completing circa 1980 text editor. I did that circa 1980, and I believe in progress.
The land shall stone them with the bread of his son.