Sometimes you want every feature. Other times, you want something that might have fewer features, but might feel better. When the iPhone came out, it didn't have a keyboard, it didn't have 3G, etc. Yet, it just felt better - the size, the icons, the way you interacted with it. I think that editors like Sublime Text and TextMate really go for that feel.

Users seem to see Sublime Text or TextMate as just missing a feature or two while looking at Eclipse and finding that it has the features, but lacks the basic joy of interaction. They also feel that it would be easier to extend something like Sublime Text than to fix the feel of Eclipse. Personally, I'm starting to warm to Eclipse as I use it and I appreciate the features it brings to the table, but I don't ever think I'll see Eclipse as "feeling good" in the way that TextMate feels right.

I somehow have this problem with Eclipse too. I really love its features, especially for Java/Android development, but it sometimes handles like you're driving a truck. Even on a fast PC. So its not that much 'fun' to use for me.

Qt Creator is one of the fow IDEs I positively like working with. It is fast, featureful and somehow doesn't get in my way like Eclipse does. The only drawback is that it's very Qt and C++-focused, so outside that area usefulness quickly dwindles.

For the rest I like Sublime Text. ST somehow helps you stay focused on the text. It is very fast and feels smooth. Like other "simple" editors it opens very quickly so can be used for editing independent scripts and configuration as well as source code, and does not impose any kind of framework or project structure.

A few years ago when I was doing heavy Flash Actionscript development, I always preferred the free Flash Develop IDE over Adobe's expensive official Flex Builder IDE, which was based on Eclipse. Price wasn't the issue. Flash Develop was simply better—much better. First on the list of why it's better is that FD just "felt right" which meant I was much more productive in FD than Eclipse. Features were easier to access than Eclipse, from keyboard shortcuts to menu options. Eclipse always feels clunky. 

Fast forward to today and my least favorite aspect of Android development is interacting with Eclipse.

Most editors less integration, but are far more flexible. Take Sublime or Vim, you can customize every bit of the experience with scripts without too much effort.

Also, I think some languages tend to need an IDE more than others. E.g. Java's relatively small feature set increases its verbosity. An IDE is almost required to avoid too much typing and memorizing. Haskell, on the other hand, is very expressive, making it less fit for smart autocompletion.

OTOH, I like to use an IDE like NetBeans to navigate Ruby code (go to method implementation, go to class implementation, etc).

I'd say it depends on what kind of project you're working on. If you're writing a small one-off script in Haskell, you probably don't need to use an IDE. The same goes for Java.

Once you integrated 3rd-party libraries (like not just one, but say, 5 of them), you either have to memorize those libraries or be grateful that IDE can help you.

- Reliable code completion. I have to deal with many different third party libraries and APIs, many of which have their own implementation of basic maths classes. It's just not possible to remember them all. I've tried clang complete and it's ok but nowhere near as nice as CDT in Eclipse.

- Inline popup of definitions on mouseover.

- Reliable jump to definition or header.

- Proper refactoring.

- Local file versioning on save with diffs. Incredibly useful once in a while.

On the other hand, I'm appreciating having a responsive editor I can run everywhere and I like having text based configuration and plugins.

I agree with the article that if you want an editor that really understands your code (and you're working in a statically typed language) then you need an IDE, not a text editor with plugins.

Re IDE's being slow/bloated - Our group does a Python IDE (free/oss plug-in) and the performance is pretty decent. If you have SSD's, VS can feel pretty snappy. Here's a video to give you an idea: http://www.youtube.com/watch?v=7CoGsSlrxKk . For 1.1 we're working toward becoming more Editor+ like, ie, less Project System overhead - just open a file & go.

For anyone who didn't get it: You have to actually spell out what you want before you can say if it fits this answer or not. The car vs bike thing only makes sense if you didn't care how fast you got there, how tired you were when you arrived, or how much pain it was to haul the luggage there.

The answer to original question is easy in that light: Because IDEs aren't the only solution to the problem. Just because IDEs have a certain feature is no reason that other things can't have that feature as well.

http://en.wikipedia.org/wiki/Bicycle_performance#Energy_effi...

For this particular example, you can apply this sequence of logic (with thanks to wccrawford):

  if(Baggage)  use a car.
  else if(In a hurry?)  use a car.
  else if(Need to be rested?)  use a car.
  else if(Need to go 150 miles^ or more?) use a car.
  else use a bike.

I don't have to.

But it's got a lot to do with the fact that while IDE's are good for something like Java or C++ programming, they tend to become really crappy once you get into web development and have to regularly work with 5+ different languages at a time.

With most IDE's that would mean I'd have to have 5 of them open to work comfortably with every language.

I used Vim to modify CSS and JS but I struggled to navigate JS code because I cannot jump to the method implementation with some sort of magical shortcut key easily. This is pretty tough if I want to know why I don't get my intended result out of calling the method.

To add injury to that, I found out that I have to redo the implementation and call the method something else to describe the intent in full. I can't refactor that easily without going to the path of hell: grep, regex, sed.

If I'm looking at something downloaded from GitHub, I use Sublime Text because the focus is on browsing the source quickly. I don't want to have to create or import a project.

Whereas, if I'm actually developing something, I'll use IntelliJ because then I need all the additional build tools.

I think it's a matter of using the right tool for the right job. Opening something in IntelliJ seems like a lot of effort because of the extra step of creating a project, and hence I choose the easier option: Sublime Text.

Here's my workflow using Emacs and magit:

1) Right Alt-G to bring up the magit git interface.

2) Down arrow and tab, repeatedly, to review diffs, with "s" to selectively stage part of a change.

3) "c", a commit message, and Control-C, Control-C to commit. Then I'm working on the next feature. This whole process is in muscle memory.

Obviously, the workflow in SimpleText or vim would be different, but there's no reason it shouldn't be just as fast. Fast commits are not just for IDEs.

And while I haven't looked, I bet you can get enough integration with vim, at least on the level of Visual Studio 5…

Meanwhile, Smalltalkers know where to draw the line and tell us that we never used an IDE at all (or an object-oriented language)…

Especially with statically typed languages, good IDEs make developers significantly more productive.

Programmers spend most time reading code, navigating code, understanding code. Much more than writing code. Unless you've only done greenfield solo projects in your life, you know this is true. IDEs have code navigation features and tooltips over types and methods. Features like this help a developer understand code significantly faster.

Additionally, code occasionally needs refactoring. Most common are the real simple refactorings: A method might grow too hairy and need a split up, maybe a method's name does not correctly convey its meaning anymore, arguments would have to be reordered for consistency, and so on. In a text editor, you have to manually update all references to the changed method. All you can do is compile (or unit test, in case of dynamically typed languages) until all the errors are gone. This is cumbersome, error-prone and time consuming. Search&replace often creates more errors than it fixes. IDEs have direct support for simple operations like these.

Larger refactorings are mostly compositions of smaller, simpler ones like I described above. Being able to trust the tool to have made the change correctly is invaluable in this process; it avoids a full unit test suite run after each step, and significantly speeds up major refactoring work.

The end result is that a team that uses IDEs and understands its navigation and refactoring features find it very easy to increase code quality. A room full of vi users, not so much. A text editor user would prefer to keep things as they are and add new features instead. The cost of minor refactorings, such as method renames, does not weigh up to the gain. This gain is small in the short run, because the developer is actively working with that part of the code. In the long run, repeatedly skipping these improvements makes code ununderstandable.

Also, let's not forget the "not invented here" syndrom. IDEs make it easy to figure out how to use 3rd party libraries and colleague's code with ease. Type the name of the class/object, press "dot" and you get a nice overview of the class's capabilities, including tooltip documentation. A text editor user has to task switch to the browser for docs all the time. If there are docs. Or read the source code that is being used.

This means that for relatively simple operations (say, a Point class, a string operation, etcetera), a text editor user will often find it easier to just write the damn thing right now. Its easier and more fun that scouring the code base for something that looks like it. The result is low code reuse.

In conclusion, correct usage of a decent IDE increases code quality, makes maintenance a blaze and keeps developers happy. Except the first week, when they're not yet used to the slightly odd UI. But if that holds you back, you're not a professional, you're a whiner.

I admit that IDEs have most value for statically typed languages (which, for me, is the strongest case for statically typed languages out there). Dynamically typed languages basically have the problem that they can't get decent IDE support, ever.

<sad rant>Which is why the web crowd keeps using TextMate and vi, keeps using Ruby and Python, and keeps writing increasingly unmaintainable code.</sad rant>

If the doohickeys your IDE does for you to improve code quality actually do so, I would expect to see evidence of it.

And, regarding your sad rant...The reason the web crowd (and many others) keep using those tools (though I don't understand the appeal of TextMate, in a world with vi and emacs), is because they are more productive with them than alternatives. One of the best Java developers I've known (famously so, he'd written some Open Source libraries that were in very widespread use), turned into one of the best Python programmers I've known nearly overnight when he got hired by a Python shop. And, while he occasionally lamented the loss of some of Java's tooling (mostly for testing and coverage and instrumentation of the running code), he used emacs for both languages.

In short, when I meet a developer that relies on an IDE, I have suspicions that they may be a cargo cult programmer, rather than the kind of programmer I want to work with. It may not be true, and I'm sure there are excellent coders working in IDEs. But, I can't really take your pro-Java/pro-IDE rant seriously, because I know what happens when good developers get the chance to work in a better language (of which there are many; Python and Ruby are among them).

...and then you bring up examples of superstar programmers. They are outliers, they'd be productive in whatever. That's not where IDEs do anything, instead you should look at average programmers in average companies with large codebases. That's where IDEs shine, because they can analyze large amounts of other people's code and hint you and guide you in the right directions when interfacing with it, without forcing you to read all of it.

Another improvement IDEs offer, especially when doing Java in Eclipse, is that you're always in a compiled state, and any errors in your code are highlighted while you write. You don't have to "context switch" to another mode where you run a compiler to check what you just written for syntax errors and other errors, and then bring that information back with you when you switch back to editing. It's all there, all the time, which increases your productivity, because it decreases the time you spend on fixing small errors, spelling errors, syntax errors, etc.

In short, when I meet a developer that rejects IDEs, I have suspicions that he may be a grumpy old programmer that just refuses to go outside his comfort zone.

I don't see a difference between someone rejecting a newer better language to stick with one they know, and someone rejecting a newer better IDE to stick with an environment they know.

As far as your Java programmer, how long did it take him to get emacs in a state with a similar amount of power as an IDE? I'm thinking about compiling, debugging, source control integration, code completion and API hints, and so on? I do a fair amount of C# coding at my day job, and I've tried to work exclusively in vim, and the productivity hit I take trying to get the conveniences of an IDE in vim pushes me to just Visual Studio and install vim emulation.

As far as other text editors go (Sublime, TextMate, Notepad++), aren't the existence of these just proof that programmers like to build things?

(Otoh, IDEs aren't that new anymore. Those programmers might have more of a tendency to exchange the keyboard for a tie?)

My personal problem with IDEs is the screen real estate. On the same screen I get an A4 of shell and two A4 of code with Emacs, the local Eclipse users get at most 40 lines of code...

Disclaimer: I've gotten scared of judging anyone since I saw really cool people speaking at conferences -- and realized they use Windows. :-)

With an IDE, all of that is in the same window, but in popups and overlays. It's presented differently, and the flow is different, so comparing lines of code on the screen is meaningless, it just shows that you haven't really gotten far enough into it that you understand how it is different.

Uh, no. [edit: It is not only compiler/tests.]

I also have half a dozen tabs of shell, where I also keep documentation (perldoc, pydoc, etc). (Real Emacs users use emacs buffers for all their shell needs and documentation. I'm a wimp.)

>>comparing lines of code on the screen is meaningless

I have used IDEs (not exactly lately) and have seen people use them quite a bit.

Personally, I don't make non-intuitive claims, and argue that others just don't know what they talk about, without good references.

>>presented differently, and the flow is different,

Obviously the work model is different. But...

You are arguing that all the screen area left to buttons etc is paid for by the IDE's popup functionality.

Screen estate has simple and obvious advantages, since when I write the code, I can see the documentation and/or the functions it calls at the same time.

You need references for your claim.

That said, with a language which gives Cobol fingers (Java, etc) and/or use half a sentence to write a library call, I do see a case for an IDE.

P.S.: Both sam and acme were written by Rob pike (ken wrote ed), in Plan 9 circles some people would call acme 'an ide', and while I use acme, I would consider sam a better text editor in part because it is precisely just: a text editor and nothing else.

If your unit tests aren't fast enough to run the relevant set after each change, you're most likely writing poor unit tests. And if you need to re-run the whole test suite after making a localised change that doesn't alter behaviour, then either your code is too tightly coupled, or your tests aren't really unit tests, they're integration tests. Maybe both.

I also have to wonder at the sort of attitude that prefers to have faith in Visual Studio or Eclipse, rather than in tests that specify the code's behaviour. And how do you know you didn't mess up using the refactoring tool? Faith in your IDE's correct operation is no substitute whatsoever for checking your code's correct operation.

This whole argument is ludicrous, anyway. A text editor that's been enhanced with powerful plugins is, as far as I can see, an IDE. My Vim setup has project navigation, method completion, build integration, you name it. I could even have automated refactoring if I felt the need:

https://github.com/ecomba/vim-ruby-refactoring

In the end we all use editors with high levels of language-awareness, and varying levels of project- and build-awareness. Some of us put them together ourselves, some of us installed a complete package. Judaean People's Front, anyone?

Another example: you want to abstract a chunk of code into a new method. Easy, select the code, refactor it out and provide a method name. 2 seconds.

You want to reorder the way the arguments appear in the method? 1 second.

You want to know if a variable is in use anywhere? 1 second.

This stuff is painful without an IDE. I don't know what you do in life, but I find this functionality indispensable.

Regardless, I don't really think that the examples you give have much to do with the IDE vs (editor+plugins) debate; they're to do with the amenability of one's language to static analysis. Certainly code modification features are available to statically typed languages that aren't available to dynamically-typed ones (and this may explain why users of the latter are less drawn to IDEs), but there are compensatory benefits to using a dynamic language. Let's not get into that one, though, eh? One eternal flame-war per thread is probably sufficient. :-)

And I'm guessing your fancy refactoring tools probably don't correctly handle the case where part of your code is in one language, which then automatically builds code in another language to compile into the main project. I've never seen an IDE that didn't get in my way with that workflow, and that's the secret sauce that my programming style cannot live without.

Yes, they do. IntelliJ products are capable of updating XML bindings for renamed Java classes/methods, reasonably good guesses about JavaScript/Python functions used in maps (i.e. with their names used as string keys, outside of the AST).

I don't want to be judgemental here, but it seems like you yet have to meet the really big codebase.

It's true I've never really worked on a project with more than a million lines of code, though. My core work is more on the scale of 300,000 lines of code.

PyCharm.

I was debating myself whether to spend $50 for PyCharm, or $60 for Sublime Text. Then I came to my senses.

My first impression is that it's the standard, ugly Java IDE, but more importantly, it's awfully slow. Loading a small, five file project from a Github repository took me almost ten minutes to get to the point where the UI was done doing things and would actually respond to me in a reasonable time frame. But even after that point, just about every action, like opening files or even just browsing the window menus, is an exercise in waiting for the UI to catch up with what I'm asking it to do, and there's never any indication that it's actually doing something when I tell it to. I'm left just wondering if I need to try clicking again, or if I'm just being too impatient. I haven't even tried to edit an actual file yet, and I'm already frustrated by the software...

Thanks for pointing it out!

How does it work for you in practice? E.g. does it help you what operations are possible on a function argument? (inside the function definition, I mean)

But I maintain some large, older Rails projects in Emacs, too. And personally, I'd rather maintain a slightly hackish Rails 2.3 application than a typical Java application. Why?

- Rails has rigid conventions for database tables, model classes and controllers. Even in a strange app, the structure is familiar.

- The Rails application will generally express the same ideas using far less code. I can dive in, figure out everything that's going on, fix it, and get out. In Java, I often have to dig through various facade classes, gratuitous design patterns, and parallel class hierarchies. Maintenance is cheaper when the fugly evil all fits on one page.

- The Rails world is in love with cute libraries that (for example) reduce an entire application's access control to 20 lines of code. Even if I don't know the library, I can learn it, and then I've only got 20 lines of code to think about.

Mind you, I keep hearing about fancy new Java frameworks, so I suppose the Java world is getting better. And a truly awful Rails application—especially one without unit tests—can be a Lovecraftian horror.

But in the real world of at least semi-competent teams, it's possible to understand both Elicpse+Java and (Rails|Python)+(Emacs|vim|shiny Mac editor), and still choose the later, even if you're a maintenance programmer.

In Spring you also have clearly defined rules about the Model, View and Controller classes like in Rails. However you still get all the benefits of tooltip JavaDoc and auto-complete on . and Ctrl+Space (in Eclipse).

I'm impressed by newer Java frameworks like Play, which make Java look terse and flexible. And I agree that refactoring IDEs are amazing tools, and well worth some sacrifices to use.

I merely disagree with skrebbel's remark that, The advantages of IDEs over text editors isn't look or feel. It's code quality. The are multiple, valid ways to achieve high code quality. IDEs are one of them. But there are real tradeoffs here, and other legitimate choices.

Facts allow me for a quick (friendly) "shut up": PHPStorm, PyCharm, etc.

You will find that if you use tools like Rails and Django then you will end up with a much higher maintainability than if you used the tools available a decade ago.

There have been some rants about unmaintainable Rails projects here on HN the last months. It's those kinds of projects I'm referring to.

That said for quick scripts I'll just use something like kate or vi, but for a large project, the IDE greatly simplifies things.

I use Eclipse heavily with a few plugins: m2eclipse, subclipse, EclEmma (code coverage), FindBugs (static analysis), and CheckStyle (code rule enforcer).

Being able to navigate the codebase blazingly quick (go to method implementation, class definition, etc) and get a better overall picture of the class (Outline provides the list of all methods, constructors, member variables complete with access modifier) is definitely more productive than anything else.

P.S. Vim is ok too. D.S.

Also, for Java projects Eclipse w/emacs+ is way nicer than vanilla emacs(at least for me)

The main reason I'm still using IDE is mostly because of code debugging and code browsing. If I could debug code on vim or ST and do code browsing I would switch in no time.

Honestly, though, probably 80-90% of the time I do prefer printfs for debugging. A debugger is great if you can easily get to the problem area. If you're just trying to figure out what is going wrong with complex code, dumping a lot of information in a format you can easily look over with a text editor is generally a superior approach.

It can be faster, but output (printf or more complicated state outputs) seems to always be more reliable.

I don't compile my code inside vim, so why should I expect to be able to debug it there?

Learning that the tools don't have to be integrated with each other to be useful was a major eye-opener for me, after using MSVC for many years.

For any thing else, I believe the OS is the IDE. An OS is in particular an integrated development environment. It contains all your favorite tools to get the job done.

To insist having all the functionality you need stuffed into a single unified plugin-ed application is like insisting to get the entire web into Facebook - it sucks.

That said, I recently had a surprisingly pleasant experience developing a C# project with VS 2010.

Please do not underestimate the long term benefits of tinkering and discovering new things in the process. For me personally, I noticed that those kind of activities might not seem productive in a short term, but tend to give me important insights (and productivity gains) in other areas of my professional life later on.

I want an editor that is aware of the language I'm using, syntax highlighting, remote execution, etc. and any other piecemeal features I add.

But I want the editor to be simple. Hello Textmate.

Maybe I'm too used to VS+Resharper and IntelliJ and don't want to waste my time reformatting code by hand. With those two editors I can reformat HTML inter-mixed with Javascript and CSS and even get colored curly waves below spelling errors and calls to functions that do not exist. They are damn good tools for a pedant. :)

Being a Lisp fan for many years(programmed quite a lot in CL, owns every cool book about it), I've come to the conclusion that I think I prefer statically typed languages, especially those with keywords like "var", "val", "def" etc so I don't have to type out something twice. Limitations can be good, it stops me from being too clever "in the small".

Some languages, especially those from Microsoft, are designed to be written in an IDE. That is not a bad thing IMHO. The amount of insight something like Resharper gives you is sometimes totally awesome. On several occasions Resharper has claimed parts of an condition is always true/false, and it's often not obvious but I've never seen Resharper being wrong on those.

I'm now more pedantic than ever with details.

That said, it's very handy to have TextMate in the Dock and in the command line path. I've used vim and emacs a lot in the past and like them too.

I find it interesting that a lot of folks in this discussion seem to accept that an IDE is advantageous for cases involving a large code base or a statically typed language. Why is an IDE any less appropriate to use with dynamically typed languages? A lot of the niceties provided by a good IDE for statically typed languages are still available for dynamically typed languages. For me, the case in favor of using an IDE is the same regardless of the language. The "killer features" an IDE provides are: autocompletion (i.e. intellisense style) and code analysis as you type. I see no reason an IDE cannot provide these features in a dynamically typed language.

Serious question, to those of you who believe an IDE is not useful for dynamically typed languages: Without intellisense like capabilities, how do you remember everything in the language's standard library and for that matter any non-standard libraries you use? Looking up a method or property in the documentation everytime you want to use it seems horribly inefficient. That's the type of job that is perfectly suited for a computer. It seems incredibly ironic to me that computer programmers are manually performing steps that a computer could easily be performing for them. As Albert Einstein said: "Why should I remember anything if I can just look it up?"

As some background I think Vim is a great editor - I use a Vim plugin in Visual Studio all the time, and I often use Vim for editing simple files. I think the addition of omnifunc in version 7 brings Vim a lot closer towards becoming an IDE. Unfortunately Vim's omnifunc capabilities are limited. Contrary to what you'd be led to believe by a lot of well meaning folks - Vim's omnifunc capabilities w.r.t python are nowhere near as capable as the same functionality found in Visual Studio or Eclipse.

I tried an experiment, wondering if I really was more productive in an IDE, and timed myself coding the solution to a couple of simple problems, using python in Visual Studio - I waited two weeks, so the solution was no longer fresh in my mind, and then coded a solution to the same problem again using Vim (note that I even gave Vim the benefit of the doubt here by using it second). For every one of the problems I tested I was significantly more productive in an IDE - sometimes by a factor as high as 2 or 3 times. Anecdotally I think the two features that make me so much faster are intellisense, and code inspection. Having errors appear automatically without the need to run my code is a huge time saver.

I think in the end it's not really about an IDE - it's about the availability of good intellisense like features, automatic code inspection, good refactoring tools, and a good debugger (integrated or not). If those features are available to me when I'm coding then I'll be happy and productive. If they're not then the tools I'm using are inadequate. As much as I would like to use Vim exclusively - unfortunately those features are not available (or do not work well) for the languages I predominately use (C# and python).