Is this personal taste, or has it to do with the scope of the projects these guys are working on?
For verbose languages, you can't beat auto-completion and auto-import.
And you can get both in vim, emacs, etc. The lines between those and full IDEs are blurry with the right (or wrong) amount of plugins.
There are many other advantages like out of the box support for a lot of common use cases like refactoring, navigation, build tool support, reuse common shortcuts like Control-C Control-V for copy-paste etc.
I would definitely advice new engineers coming into languages like Java to pick up an IDE like Intellij instead of vim.
It's clang-based, so suffers from none of the tags-type issues: it's context-sensitive, and can see straight through gnarly stuff such as identifiers generated by token pasting.
Good points:
- Only mildly fiddly to set up
- Code browsing works well
- Code completion works well when it works
- Cute gcc/g++/etc. wrapper trick means you don't have to change any build settings
Bad points:
- Making it work with code you haven't built yourself on your local system (e.g., 3rd party stuff that's not complete, code for another platform) is less straightforward
- Code completion sometimes doesn't work with certain files (and for no reason that I've ever been able to figure out)
- It's probably my own limitations but I found it extremely inconvenient to debug (internally it's surprisingly complicated: separate client and server, lots of lengthy command lines, client code writes elisp code to stdout and elisp in emacs eats it up, the actual completion popup is a separate package, etc.)
BTW, I've used both. No need for a snarky response to me as well
And the whole point of me switching to vi is so I slow down a bit and get it correct.
I generally don't need an ide to keep popping up telling me what to type. I know what I'm doing.
If I uncharitably assume that grunt work means "redundant boilerplate", that sounds like more of a language issue than a tool issue. This said as a Java programmer who has been doing a lot of JavaScript this last year, and REALLY appreciates the brevity. Even if your IDE can generate it, that doesn't mean I want to read it.
Java: the language that has to wear a paper bag over its face while it's screwin' ya. :-)
(think of all those Eclipse plugins to visualize fugly XML bogo-DSLs and other cruft for The Enterprise -- sure, there are worse languages out there, but not in common use now)
I like how you can use command keys to quickly toggle on and off the project file and current-file's-components browsers, leaving the "distraction free" * editor window for much of your work.
* yeah, there's a mode with this name that auto-wacks ALL the supplemental panels, AND the window frame. I don't usually go that far, but it does show that they "get it" as far as what many of us IDE resisters disliked.
1. the ability to run everything (a.k.a the whole project) using the preferred SCM (or build tools)
for example: mvn clean install
where your pom.xml already set to have cobertura (code coverage), checkstyle/pmd (linting/style/formatting), and findbugs (static code analysis)
2. the ability to run a very specific unit-test somewhere deep down in your project via your IDE as you're writing code (the IDE compiles your code on the fly...) and get everything I mentioned above :)
for example: I want to run one new unit-test for a new code => I don't have to drop to my console/command-line/terminal to run mvn clean install. I just go to my unit-test, highlight the method name, run it through eclipse/intellij and I get everything.
My workflow goes like this:
1. Write new code
2. Write unit-test
3. Run _just that_ unit-test w/ code-coverage from within my IDE without compilation (e.g.: no mvn clean install)
4. Get feedbacks (unit-test results, code-coverage results)
I take it linting/checkstyle/style-formatter is a given in sublime (I use jshint so I guess I know the answer to that ;)).
Of course it doesn't work exactly the same way; for example, running a single test doesn't involve highlighting it and telling Emacs to do something magical, but rather flagging it in a way that's specific to the test runner and then doing M-x compile RET RET to point the test runner at that file. The first time I do that, I have to tell Emacs what command I want it to run, but that's no great hardship, since it's buffer-local (each file I'm editing has its own value) and, being a simple test harness invocation, need change only when the filename does. If it matters to me, I can put this information in a configuration file, so I don't have to worry about typing it out even the first time. So far, it hasn't mattered to me. (And, yes, when I run a single test this way, I still get coverage information. Linting happens inline, as linting should, so doesn't really figure into things here.)
The mechanism differs somewhat from what you describe, but the result is the same. Just highlighting the desired test and invoking a keybinding might be a little quicker and more convenient, but so far it hasn't seemed enough so for me to go to the effort of writing Lisp code to do it. It wouldn't be much effort, but since invoking a specific unit test alone takes about a second, it also wouldn't save me much time, which is why I haven't bothered doing it.
A major point of interest here is that none of this workflow is specific to a single language or a single toolset. It works the same way across all the languages I use. Since I work in multiple languages on a daily basis, that's very important to me. It sounds like you work primarily, perhaps exclusively, in Java, so that's not as important to you. The problem is, you seem to have assumed that nobody else's tools can do the same awesome things your tools can do. As I hope you've gleaned from this comment thread, that is rather untrue, and proceeding from the assumption that it is makes you come off as both ignorant and arrogant. What you do with this information is, of course, entirely up to you.
I know most test-runners have the capability to run specific test which suggest that any editor that is capable of executing command-line and bind it to something can support my workflow with some annoyance here and there (as you mentioned, your setup isn't as magical as my description ;)). I mean... someone could've written shell scripts that help them run a bunch of things too...
This is akin of the discussion of using ctags and the need to detect file changes and re-run ctags. Last time I google it there were plenty plugins for each editors and ways to set it up (except there's no clear winner ;)).
The whole idea here is that the IDE helps you not to worry about any of that. IntelliJ supports multiple (mainstream) languages that fulfill my workflow nicely.
Good point that I'm sure Emacs can handle way more languages but the steps to set it up and the limitation (filename change? method name change?) feels more static than dynamic to me.
https://emptysqua.re/blog/unittests-code-coverage-in-pycharm...
http://blog.jetbrains.com/idea/2012/04/code-coverage-for-jav...