Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 14 Jan 2006 13:00:22 -0500
From:      JD Arnold <jdarnold@buddydog.org>
To:        freebsd-questions@freebsd.org
Subject:   Re: Which is the best open source C/C++ IDE out there?
Message-ID:  <dqbe7b$4h9$1@sea.gmane.org>
In-Reply-To: <43C2C7FE.1010703@chuckr.org>
References:  <666bdb140601081330m3b394a02v@mail.gmail.com>	<20060109140254.92455.qmail@web33306.mail.mud.yahoo.com>	<dptv94$7ft$1@sea.gmane.org> <43C2C7FE.1010703@chuckr.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Chuck Robey wrote:
> 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.

A couple of notes on this:

* The coolest thing about Emacs is you learn it once and you are set for life.
No matter what platform, there's bound to be an Emacs port.  I've been using
Emacs for 15+ years, and I've never had to learn another editor. And that 
includes working on the Atari ST, OS/2, any Un*x flavor of the month, etc.
The native Windows port is one of the best ports, too.

* You in no way, shape or manner need to know lisp.  These days, with the
fancy "customize" stuff, you almost never need to program in elisp.

* I'd actually contend that emacs *is* the world's most popular (ie., "used")
editor in the world. Given the gazillion platforms it runs on, and it's 
amazing flexibility, I think you'd be hard pressed to name another one that
can contend with it.

* I'm not sure why you'd "have to go back to vi for a job". Why would anyone
care what editor you use, as long as you get the job done? I've worked in many
companies, using many different platforms, and I've always used Emacs.

-- 
Jonathan Arnold     (mailto:jdarnold@buddydog.org)
Daemon Dancing in the Dark, a FreeBSD weblog:
   http://freebsd.amazingdev.com/blog/

UNIX is user-friendly. It's just a bit picky about who its friends are.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?dqbe7b$4h9$1>