Date: Mon, 09 Jan 2006 15:30:54 -0500 From: Chuck Robey <chuckr@chuckr.org> To: JD Arnold <jdarnold@buddydog.org> Cc: freebsd-questions@freebsd.org Subject: Re: Which is the best open source C/C++ IDE out there? Message-ID: <43C2C7FE.1010703@chuckr.org> In-Reply-To: <dptv94$7ft$1@sea.gmane.org> References: <666bdb140601081330m3b394a02v@mail.gmail.com> <20060109140254.92455.qmail@web33306.mail.mud.yahoo.com> <dptv94$7ft$1@sea.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
JD Arnold wrote: > Danial Thom wrote: > >> >> --- Vladimir Tsvetkov <npacemo@gmail.com> wrote: >> >>>> This is obviously a trick question, because >>> >>> real >>> >>>> programmers don't use IDEs. Case Closed. >>> >>> I'm not a real programmer, but UNIX is a great >>> developer environment. >>> It's a tool based environment. >>> Small tools, strong cohesion in what they are >>> designed for, easy ways >>> to combine them to form more complex tasks. >>> Good documentation too. >>> Actually you don't need anything else, you >>> don't need a colourfull IDE. But... >>> Maybe only few, really exceptional people can >>> benefit and grok the >>> power of this kind of environments. >>> To me the ideal "IDE" is actually a toolkit: >>> - Source Editor, preferably with a object >>> browser or other kind of a >>> source browser. An autocomplete functionallity >>> could increase >>> productivity too - this could increase quality >>> if we measure quality >>> of code by the low number of syntax mistakes, >>> but this could also be a >>> threat to quality letting the programmer write >>> without reading >>> carefully what is written - code bloating. >>> - Compiler with a debugger. We must discuss >>> about the pros. and cons. >>> of a grafic debugger versus a text-mode >>> debugger. The things are >>> getting really messy when it comes up to >>> debugging multithreading code >>> and I really don't know what is the ultimate >>> tool for this task. >>> - A build tool. Ant or make will suffice. >>> - Source control tools. CVS, SVN etc. >>> - Documentation tools. POD, Doxygen, Javadoc or >>> something else. >>> - Unit testing framework. This is not always a >>> tool. This could be a >>> language extension, or a testing API. >>> - Other tools. >>> >>> You don't need to put everything together in a >>> single swissknife-tool, >>> but this could be convenient in some cases. >>> >>> IDE vs. Toolbased Environments ??? >>> >>> Which is more productive and how to measure >>> productiveness? >>> >>> Best Regards, >>> Vladimir Tsvetkov >> >> >> Tools, schmools. vi and cc work for me. >> >> I do admit that I wish someone would get make to >> accept spaces instead of the (damn) tab. I think >> its time for that :) > > > That's why you should graduate to Emacs - with the makefile syntax > highlighting, > you'll at least see the differences between tabs and spaces before > getting into > trouble due to bad whitespacing!-) > you're certainly giving a viewpoint that has a great deal of truth to it, but I guess what scares folks is the horrible, horrible emacs learning curve,. At one point in my career (in school, lisp programming) I learned/used emacs. I admit, it's got so much power, there isn't even a close competitor. BUT at that time, I had a genius girl programmer at my side, and she helped me with emacs syntax so heavily it was funny, and so I could make use of emacs without really having to scale the learning curve. If I'd actually had to scale that learning curve, do you think I would have, even COULD have used emacs? One of the worst things I had happen, I needed, one year later, to go back to vi for a job, and just forgot enough emacs usages, and never went back. I'd love to, but I'd have to find another genius Lisp girlfriend, before I could do that. Likely? That's why emacs isn't the world's most popular editor/IDE.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43C2C7FE.1010703>