
Ask HN: IDEs vs. Text Editors - factorialboy
I've seen really good programmers using both.<p>I've had a really good run with IntelliJ IDEA after horrific experiences with Eclipse.<p>I've used gEdit and SublimeText as well in the past while struggling with VIm and emacs.<p>I can understand that using a text editor brings you closer to your tools while an IDE can make you 'lazy'.<p>But I also feel that IDEs (at least IntelliJ IDEA) makes you way more productive and allows you to refactor with ease.<p>I currently use IDEA in a team that's full of VIm aficionados. No they aren't forcing me to 'convert' ;-) but I am a little curious.<p>I guess text editor  + plugins could give you a pretty good mini IDE.<p>What do you use?<p>---<p>Edit:<p>Languages that I work with: JavaScript (Client + Server side), Scala, Python, Java, HTML, CSS, LESS, Bash
======
nostrademons
Long history of switching back and forth between them.

I started with Turbo Pascal and Think C, which I guess were very early IDEs,
then used Notepad for my early Java/HTML/Javascript days as a teenager.
Discovered JBuilder at my first professional job, it was a revelation.
Switched to Eclipse (which had just come out) just as that job was ending, and
used that for most of my Java courses and hobby projects in college. Did PHP
using Notepad++, attempted to use both PyDev (Eclipse) and Wing IDE for Python
but found them lacking. Attempted to write an Eclipse plugin for Dylan.
Eventually learned vim so I could edit PHP files on the server, and stuck with
it for Haskell. Used all 3 of Netbeans/Eclipse/IntelliJ in my first
professional job, and wrote a Netbeans plugin. Switched to vim for my startup,
which was all Python/Javascript/HTML/CSS/SQL. Stuck with vim at Google, now
use it for basically everything.

I'm not anti-IDE, I like a lot of the functionality available in it and wish I
could get at some of that from within vim, but ultimately it's not worth it
for me now. Eclipse has difficulty indexing the Google code base because it's
so large (I've heard reports of it taking up to 2 hours to startup), so I'd
much rather stick with vim and pop up an editor instantaneously. I have enough
memory issues just running our build system and frontends on my workstation.

~~~
swah
Do you open and close vim every time you edit a different file, or a file on a
different folder?

~~~
nostrademons
I typically use tabs & multiple windows with gvim and have all the files I
need to touch for a given commit open at once. Then when I commit, I close
everything so I can flush it out of my brain and not need to deal with it.
I'll usually close stuff when I get >6-10 editor tabs open as well; I don't
like having things open that I can't mentally keep track of.

(I do the same thing with browser tabs; I rarely have more than 6 browser tabs
open, while a lot of my coworkers will have 20-30, so many that you can't see
the titles on each.)

------
gexla
The choice of IDE's and what they bring to the table is different for each
ecosystem. For example, I'm probably going to be much more inclined to use
Visual Studio for .NET development than Vim.

In some cases a text editor might have an extension available that is so
powerful for a particular use that it has become a de facto standard.

In some cases, you may not have much choice (Squeak development.)

In some cases you may have invested so much time in learning a certain tool
(you can grow with Vim for your entire coding lifetime) that you may not want
to give it up even if there are some things in a different tool which may make
your life easier.

Personally, I'm a Vim user because I'm absolutely convinced there is no faster
editor for text. I also feel that outside of text editing, features bundled
with my text editor or IDE aren't often going to be the most powerful options
available. For example, I prefer command line Git over any other method of
using Git.

So, I think what I'm really trying to say here is, learn Vim. ;)

------
ishbits
For Java or Scala I use an IDE. Currently Eclipse but I'm giving IntelliJ an
honest shot at the moment. I find that Java requires an IDE for me to be
productive, even though I used emacs back in the Java 1.0 days.

For C and Python I use emacs. I'm more comfortable with emacs here as decent
documentation can be had from the command line (man and pydoc) so have never
spent the time trying them in an IDE.

An average day for me involves Java, C and Python. So I flip back and forth
between an IDE and emacs and feel that I'm using the best tool for the job in
each case.

------
mhd
I always considered this to be a false dichotomy, as there's really a
continuum between text editors and what we tend to call IDEs. Let's pick Java
as an example.

At one end of the spectrum you have very simple editors without any extension
and/or abuse capabilities, e.g. Windows' Notepad.exe. Not a lot you can do
besides adding and removing text, and possibly searching for it. Everything in
a per-character level, no introspection in the structure of the current class
or the whole project.

The next step in the editor/IDE spectrum either pulls in external tools or
moves us towards "programmer's editors". Probably the best known example of
the "toolshed" version is Unix. You still use a rather simple editor (plain
vi, pico, leafpad…), but combine it with a plethora of text-based tools to
manipulate the source files. grep, sed, awk etc.

As for more advanced editors, probably the first two features that bring us
closer to the "true IDE" end are syntax highlighting and compiler output
parsing, allowing you to jump to lines causing errors. Add some simple way to
manage multiple files (i.e. a directory tree) and you're rather close to some
earlier IDEs (outside of the Lisp/SmallTalk school).

At this stage, some simple parsing of the source files is often added,
allowing you to autocomplete and navigate to some extent. Quite often some
version of the ctags utility is used for that.

I guess that leaves us the biggest step: Going from such regexp-based ad hoc
parsing utilities and modules to properly understanding the code, like the
compiler or interpreter itself uses. This allows better completion and enables
complicated structure-based actions like refactoring or context-sensitive
search and replace.

The "power" of the editing component is pretty orthogonal to all that and I'd
argue that this is the main dividing line. People wouldn't mind having better
"integration", but are wary to miss all the editing and/or extension
capabilities. Forced asceticism is relatively rare (outside of 9fans), it's
just that quite often it comes down to a choice you have to make between high
level and low level abilities. With the IDE you might be able to navigate and
change a lot on a class point of view, but once you leave the syntax tree and
there's little support for "common" editing tasks where you'd just fly through
with e.g. emacs/vim macros. It would look like the "IDE" part is the more
complicated one and so it's easy enough to add those missing text editing
features.

If only. For some kind of reason, most IDEs (esp. the Java ones) aren't that
good at extending their capabilities. If you're ever cornered by a horde of
former Java developers turned zombies, shouting "Eclipse plugin" is pretty
sure to reach even their rotting cerebral cortex and send them shambling away
(if that alone doesn't work, add some "maven! pom!" into your mix). Meanwhile,
there are working vim plugins and emacs lisp modules for any non-physical task
(and probably quite a few physical ones).

From the other side of things, the success of making those editors into IDEs
is mixed. For Lisp and some other languages, Emacs _is_ one, but the Java
module isn't quite up to par. Vim has its "eclim" plugin, which in conjunction
with Eclipse might actaully get somewhere. But for most languages and
development environments, it probably still comes down to making a choice.

One thing that I've found (although, again, there's nothing inherent in the
distinction enforcing that) is that "IDEs" are better integrated with the
_language_ (singular, sadly), whereas the extensible editors are more
integrated/adapted to the _user_.

As a final personal note: I generally don't like it when I have to be "helped"
by my environment too little or too much. Some support is good, but if I have
to consult the program all the time, it probably means that I'm wasting time
and might not understand the solution domain enough. Waiting for
autocompletion is a good example, for common tasks, I'd like to _know_ things,
not look them up all the time. And if it's rare enough, I'll probably be
better served by reading the documentation that just hoping that this method
with those parameters is sufficient. And as languages come and go, I prefer to
invest a bit more time in editors that will stand the test of time (which
means a lot of hopping back and forth between emacs and vim).

For some languages, it's IDEs, though. That includes SmallTalk (because the
IDE is that good) and Java (because the language is that bad).

~~~
frou_dh
Nice writeup! I'll go with the distinguishing characteristic of an IDE being
that it understands the content as a specific language (or strives to) rather
than "some kind of scoped/indented code with keywords". Whether this is
particularly compelling depends on how deft the implementation of a pairing
is. Visual Studio fits C# like a glove, but with C++ there are sharp and wonky
bits sticking out everywhere. I suppose another major characteristic is GUI
abstraction of the build process.

~~~
mhd
Well, GUI _handling_ of the build (and jumping to errors) maybe, although this
is rather common (and easy) in most programmer's editors, too. Abstraction is
more a matter of taste. True, Visual Studio and XCode tend to hide away any
kind of Makefiles, but mostly because native GUI apps don't have that many
build stages and options, so the built in method is sufficient for 90+% of the
cases. For servers and similar projects, you often have to include your own
tasks, and thus the innards are exposed. Especially in Java IDEs it's rather
common to edit the Maven files - although part of that is because putting a
nice GUI around that monster isn't exactly easy.

What we also didn't talk about is version control, but as this is completely
orthogonal to the language itself, both IDEs and extensible editors handle
this equally well.

------
sergiotapia
When working on ASP.Net MVC pages I use Visual Studio because really, what
else can I use realistically? It's fantastic and I love the tools and helpers
it gives me.

For Rails I use Sublime Text 2, not because it's 'more leet' but because it
works just fine. Plus any IDE's I tried using just sucked and slowed me down
for little benefit. As a direct result of using a text editor I memorized the
Rails keywords and helpers instead of relying on autocomplete so in that sense
it helps.

------
rartichoke
I think as long as you're not being held back by whatever tool(s) you use,
then it's fine.

For example, I couldn't use an editor without a split pane view. I feel like
not having that feature would be a serious productivity killer.

------
navneetpandey
I use text editor when I start learning any language, and after spending
sometime I switch to IDE.

for Java I used Netbeans but moved on to eclipse for PHP I prefer text editor
Notepad++.

------
s2r2
Acme [0] via Plan9port [1].

[0]: <http://acme.cat-v.org/>

[1]: <http://swtch.com/plan9port/>

------
bee
netbeans all the way.

~~~
factorialboy
Curious, which languages do you work with?

~~~
kls
I use Netbeans for JavaScript, Python and C++, it get's a rap as a Java IDE
but it's actually an excellent JavaScript and C IDE.

