The advantages of IDEs over text editors isn't look or feel. It's code quality.
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>
The best code I've ever read was written in emacs. The second best code I've ever read was written in vi. I can't think of code I've seen written in an IDE that I considered notably great code.
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).
> If the doohickeys your IDE does for you to improve code quality actually do so, I would expect to see evidence of it.
...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.
So your critique of IDEs is as much about the language as it is the IDE?
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?
I would say there are two components to it. Language and project size. Java and C# where designed with IDE use in mind. I am not sure I would want to work in either without an IDE. For smaller languages like C and Python an IDE wouldn't be my first choice of tooling, the cost of using the tool just isn't worth the benefit provided. I could see switching to an IDE if the project got a little too large.
C# probably was but I suspect it wasn't a factor in the initial design of Java - I don't even remember there being any IDEs for the first couple of years of Java being widely available.
I would say that Java was designed to be used with committees. Basically a language to use if you're in a design by committee situation. IDEs were then introduced to give individuals their own "virtual design committees".
Agreed regarding C#. I've tried using vim as my C# editor, then switching to VS for builds and debugging, but I miss Intellisense too much (and with vim emulator in VS, I don't lose any of my keyboard efficiencies).
As a counterpoint, the way VS does autocomplete drives me insane. In the middle of a frenzy of flow typing, I have to move my hands away from the keyboard to the mouse to select which autocomplete entry I want. Aargh. It breaks the flow. (Although, I am using the Express edition so have not tried a vim emulator; perhaps their autocomplete is better.)
I'm not going to argue against your points, but an alternative explanation is that Emacs/Vi(m) users have on average lots of more experience than the average IDE user.
(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. :-)
The point you're overlooking is that with your shell+emacs solution, you NEED those windows, because you need to run your compiler in one window, and edit in another, and lookup code in the third, and maybe have a browser for the javadoc or other reference in a fourth.
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.
What you're overlooking is that with Vim, I can code in 80x24 or less and be perfectly fine. Try that with an IDE.. Of course I can also throw more space at it if I wish, and it's just that much nicer.
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.
For comparison purposes: The best code I have ever read was written with Sam ( http://sam.cat-v.org ) by Ken Thompson, the second best code I have ever read was written in ed(1) (by Ken and Dennis Ritchie), and the third was probably code written by the rest of the Plan 9 team at Bell Labs written using mostly acme ( http://acme.cat-v.org ).
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.
> 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.
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:
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?
It's not a matter of forgoing unit tests. Example: rename a method to something more clear. It's used 1000x in your codebase. You can do that in probably 5 seconds and know that it's done correctly. It says nothing about how the method functions, but rather that the code hasn't suffered because of this trivial operation.
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.
I was responding specifically to the somewhat alarming claim that faith in the operation of one's IDE is a substitute for regularly running tests. I wasn't denying that automated refactoring tools are nice to have; they obviously are.
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. :-)
Well, here's the thing. I don't have an easy way to do those things, so I rarely if ever do them. And guess what? I don't miss that at all.
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.
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.
Umm, your XML binding stuff is great, but I would need a refactoring tool to go into Perl code, figure out what bits of it are actually C++ that are going to be output later, and change that. I would be really, really surprised if you have a tool capable of handling that routinely.
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.
Good point. I made the argument under the assumption that the team is, in fact, good. I know that that isn't a common situation. Bad programmers with text editors write unreadable code. Bad programmers with IDEs write slightly more readable code with autogenerated try..catch blocks that do the wrong thing. There's no real difference.
I just downloaded PyCharm to use the 30 day trial; I specifically wanted to test its claimed Vim emulation plugins.
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...
After reading this I looked and saw that PyCharm is on special for $49, which falls into my compulsive purchase zone! (I also have the significant remains of a 1 lb bag of bay leaves in my fridge which I ordered from Amazon under similar compulsive circumstances. That's a lot of bay leaves.)
I cook a lot and I was tired of running out and paying $5 for a jar of about 10 broken leaves. So I got a bag of organic turkish bay leaves from amazon for only $18. There must be at least 1000 leaves in the bag, which I'll leave to my children in my will one day. I'll drop the thread at this point, because I'm sure no one wants to hear more about my bay leaf glut.
Hm, cool. They must be doing some internal type inference, insofar that's at all possible, then, in order to add such refactoring features.
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)
PyCharm is produced by the same guys who created Resharper and a lot of other great tools like PHPStorm and TeamCity. Been using PHPStorm for nearly a year now, and I still find new things it can do.
Don't get me wrong, I love automated refactoring. It's fun to slice-and-dice a large Java code base using Eclipse, and to leave it tidier than you found it. I like the way that basic cleanup operations are fast and safe enough to do while browsing code.
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.
You are comparing Rails to Java, which is wrong because the first is a framework and the second a language. A fair comparison would be between Rails and Spring or Ruby and Java. And here things are different.
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).
Despite the disagreement, I'll stand by my earlier remarks: Many popular Java frameworks involve a lot of boilerplate. I've never used Spring, so I can't comment on it. But in the last two years, I've worked on multiple GWT and Android applications, and both frameworks encourage people to write a lot of code for something as simple as MVC bindings. Seriously, GWT can easily require 10x as much code as Backbone.js + CoffeeScript.
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.
The code of the webcrowd is getting less maintainable as time goes by? Hah. I suggest you compare the code complexity of a webapp written using the state of the art 10 years ago to one of the same size using the state of the art today.
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.
Ah, now I see your point. I'm talking about code that survives for years. Not about making a new project every half year with the latest & greatest libraries of the time.
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.
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>