Hacker News new | comments | show | ask | jobs | submit login
Ask HN: IDEs vs. Text Editors
11 points by factorialboy 1829 days ago | hide | past | web | favorite | 16 comments
I've seen really good programmers using both.

I've had a really good run with IntelliJ IDEA after horrific experiences with Eclipse.

I've used gEdit and SublimeText as well in the past while struggling with VIm and emacs.

I can understand that using a text editor brings you closer to your tools while an IDE can make you 'lazy'.

But I also feel that IDEs (at least IntelliJ IDEA) makes you way more productive and allows you to refactor with ease.

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.

I guess text editor + plugins could give you a pretty good mini IDE.

What do you use?



Languages that I work with: JavaScript (Client + Server side), Scala, Python, Java, HTML, CSS, LESS, Bash

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.

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

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.)

At least I don't. tabbed vim, combined with vim --servername and --remote-tab works great.

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. ;)

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.

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.

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).

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.

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.

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.

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++.

Acme [0] via Plan9port [1].

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

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

netbeans all the way.

Curious, which languages do you work with?

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.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact