Someone not getting their job done is a problem. Someone using vim as their editor is not. I could understand giving that feedback ("try an IDE") but telling them their job is contingent on it is probably missing the point.
Most of the people I work with seem to use vim/emacs, and it doesn't appear to be for "machismo" reasons. It's likely just what they're used to.
My trick (not really a trick) for efficiency is some simple key bindings to navigate between windows in Screen.
And if I really need power I'll run tabs inside of individual Vim instances within each Screen window.
I really think IDE dependence is one of the things that can prevent agility within a team. As soon as you introduce a product into your stack that a person's IDE doesn't have deep integration with, or doesn't play nicely with, all that productivity that person gained by learning that IDE is all of a sudden gone.
The best programmers I work with use emacs or vim and are good enough to keep up even though most others use intelliJ ides, but it is a handicap, they are just good enough to overcome it. I have no doubt they would be even better in a good IDE.
Do you really think the best programmers spend enough time refactoring for the use of an IDE to help?
> Is refactoring a bad thing now?
It isn't, he just intended that the best programmers refactor less (since they are the best they must get things right or better predict the future more often then the others).
And yes I know those I work with do, because we work on the same codebase and I see their commits.
But then, that's probably why those IDEs ship with sophisticated debuggers, right? ☺
They design it well the first time. They refactor is to a better design as needed as new requirements arise.
For C/C++ specifically, the state of code analysis in emacs has greatly improved due to clang. For example, I get full auto-complete (including for variables declared 'auto') in emacs with irony-mode [0] for code completion, flycheck-irony [1] for on-the-fly syntax checking, and I get jump to definition/find references/etc via clang-ctags [2]. I assume vim has similar extensions.
[0] - https://github.com/Sarcasm/irony-mode
I use PhpStorm, cLion and PyCharm, and im happy to pay for them, the editor itself is very high quality and having common tools across all the 3 languages i use is great. If only they did a "golang" IDE.
Oh, that's amusing, and rather misinformed. Emacs in particular, when programming Common Lisp or Clojure, has a really impressive environment that Java IDEs can only aspire to (in part, that's an unfair comparison, because CL and Clojure are well suited to interactive programming and Java isn't).
I would be more careful with strong words like "professional negligence" or "hardcore, programmer machismo".
I feel the same.
Having been brought up with all Borland products, Smalltalk Visual Works and Oberon, I really cannot grasp they keep themselves in a UNIX V7 world, instead of a Xerox PARC one.
And I did use Emacs several years, while deeply missing Borland tooling, as that was the best thing one could look for in UNIX back then (VIM did not exist just VI).
However in 2015, there are so many nice IDEs also available for UNIX...
What is amazing is that in 2015 there is people out there that believes Vim or Emacs have no intelligent, realtime analysis.
In fact, in year 2015 Emacs and Vim have the best real time, intelligent analysis out there for those that know how to use them and are trained on them.
You can use elisp inside emacs and automate EVERYTHING running circles around anything commercial.
I have a company making software and I know. With the proper training those tools are incredible.
I develop Cursive, an IDE based on IntelliJ for Clojure code. Its completion and navigation are categorically better than Emacs's, even for a language that supposedly has one of the best levels of support under Emacs.
To say that Emacs is automatically better than everything else is pure Stockholm syndrome.
I'm not saying there isn't any, and certainly I've used better refactoring tools than https://github.com/clojure-emacs/clj-refactor.el in other languages. But what on earth is wrong with the navigation? The main advantage I've seen form a colleague is the highlighting automatically of usages, but I'm pretty sure I can set that up in Emacs too.
If you're interested in the implementation of this sort of functionality in Emacs, Steve Yegge's article on implementing JS2 mode is really interesting: http://steve-yegge.blogspot.co.nz/2008/03/js2-mode-new-javas.... He says at the end that IntelliJ's JavaScript support is just better, and it's very clear from the article how difficult it is to retrofit this sort of functionality into something that isn't built from the start to support it.
But you're right that the tone of my comment wasn't great, and in general getting involved in these discussions is just a bad idea. Every so often I see a comment that makes it difficult to resist, but I always regret it.
To answer this specific question - Cursive's Java interop support is much better than anything else I'm aware of. It implements Clojure's type inference in the editor, so method calls are accurately resolved to the right method based on the number and types of the parameters, and completion takes this into account so that you can explore Java APIs almost as well as with Java in IntelliJ. Cross-language navigation and Find Usages works - in Cursive you can navigate from RT.var() calls to the Clojure code, and Find Usages from Clojure will find the RT.var() calls. This also works for other JVM languages - there are quite a few Cursive users with mixed Clojure/Scala codebases, and this all works there.
You can search for all usages of a particular keyword, and it will also find all local bindings destructured from it using :keys. Namespaces will be auto-required during completion based on examples elsewhere in your project, not hard-coded config. This works in the REPL too - you can type str/tr and when it's completed into str/trim Cursive will automatically (require '[clojure.string :as str]) in your REPL.
One other nice thing is that since Cursive works from source, pretty much everything that works for Clojure works for CLJS too.
There's lots more along the same lines, hopefully this gives you an idea. Again, there's nothing wrong per se with Emacs' navigation, but IntelliJ just provides a much more sophisticated infrastructure for it. Obviously elisp is Turing-complete so all this could in theory be implemented but it's much harder, as Yegge describes in the article I linked in my other comment. The clj-refactor guys are doing a great job but the lack of a good indexing infrastructure is going to mean that a lot of this functionality is hard or impossible to implement.
Emacs is a great choice for a lot of people and if you're willing to invest the time to trick it out and maintain it, especially for Clojure you can get a really nice environment. But probably the feature that most people like about Cursive is that it just works out of the box, and stays working with no messing around and no development of your editor required. And WRT my original comment - to say that Emacs has the most sophisticated runtime analysis is just wrong.
Emacs is more extensible, and more easily extensible, than Eclipse.
Yes, an IDE is pretty nice for a particular kind of horrible enterprise coding: the sort where no-one understands the system, where everything's horribly over-architected and where, yes, ultra-fast auto-completion is necessary to get anything done. But…why live like that? There're interesting problems and fun environments where one doesn't need to live in that kind of hell.
emacs can handle that, but you have to start asking yourself if it even makes sense to do. A lot of times, those IDEs are just managing spurious complexity, not actually helping build something great.
One can look at it the other way. If your language needs a million lines of IDE code to function and for programmers to be productive with it, maybe it is time to sit down and tell that language to "get lost".
I think it's mostly that the current state of "intelligent, realtime code analysis" is so terrible that it can be replaced with "rename" and "find references of". I.e. ctags.
Yet some people hate it because it's not "modern", mostly meaning you can't control it with the mouse.
Try that with rename and you will quickly run into trouble, unless you have only one class that has a method called length.
Refactoring is still in its infancy. A), it's not entirely possible on C/C++ because of macros. B), they are serialized extremely poorly to diffs, so any boon from refactoring is sidestepped by SCM. C), most of the refactoring done by programmers cannot be done automagically by the IDE (e.g. type signature changes are painful as hell). D), 95% of changes are supported by ctags-like functionality; i.e., a basic identifier index, and re-compiling to fix the bugs.
Given this, I'm pretty sure IDEs have made a lot of progress towards renaming and looking up references really well, but not a lot of progress towards actually being useful.
That said, I do find that when the language supports it, a precise tool to find usages and/or rename is worth its wait in gold. But this is hardly anything near "intelligent, realtime code analysis". Pretty sure that's referring to typeahead, which again is a step removed from a source code index and can be faked by using a regular expression to extract identifiers to suggest.
Yup, until merges/conflicts. :) Semantic diffs with refactoring operations would solve this.
> (e.g. type signature changes are painful as hell) Resharper handles this very well.
For the life of me, I've never been able to get any advanced code stuff to work. Auto-complete etc.
In addition to code completion, having documentation available to you as you type, and easily navigating code (e.g. jump to definition), you also have all the usual emacs goodies (unlimited undo/redo, easily defining keyboard macros, writing functions for emacs and binding them to keys).
After 9 years of using emacs, I still don't find it unambiguously better than Visual Studio for working with C/C++. The text editing is a lot better in emacs, but the code browsing/completion is not - and for large, multi-person projects I've always found the code browsing/completion functionality more important. You can always load files into emacs for one-off operations if you need to do something in particular.
I never needed it in Python, because Python libraries are so clean and orthogonal.
I think you hit the nail on the head, IDE's are an excellent choice for when you don't know what you're doing. :p
Seriously though, auto popups of docs are very helpful for huge libraries and new codebases. I wrote a little script for that.
These days there's also things like eclim. I don't know it seems like vim style editing is still the best way to get around the codebase and actually work with the text but IDEs have great integration to work with the code. So I think the optimal solution is a "best of both worlds" approach which means a vim-plugin for the IDE or an IDEfeatures-plugin for vim. I see the former setup a lot.
--- and my wild guess is that emacs actually has great code integration for Lisps. I don't know what the state of the art Lisp IDE is but I'd be shocked if it was better than emacs.
For me, I've used both IDE's and plain ordinary text editors for close to 30 years (the first IDE being QuickBasic 4), and tend to find that IDE's get in the way more often than not. My personal software designs tend to use single components for single functions, so the additional complexities of an IDE's second compiler, second build tool, second VCS front end are less than appealing to me. That said, I've gotten a lot of use in the last 24 hours out of code refactoring the the IntelliJ debugger, so I think the honest answer is to use both approaches if you like.
You found me out! My preferred environment set up is nothing more than machismo directed at you, a complete stranger. If only I'd had the humility to try an IDE, I could have been enlightened
My eyes hurt from rolling them so hard at your comment.
Emacs, Slime and Common Lisp is something that I would give an exception to. The major productivity I give to that combo is the ability to change the code on the fly while debugging, especially Common Lisp's continue from exception mechanism.
Smalltalk environments have had this ability forever. I just imagine how much more productive I could be if in Visual Studio I could edit-n-continue on everything...even if my code wasn't in a successful compilation state.
Java has this and Jrebel has this on steroids, but I want to be able to edit-n-continue even if my compilation state is broken. Just throw an exception when it fails because of bad state.
like 'zero'. ;-) Use Clozure CL: http://ccl.clozure.com
> Clozure CL also provides a mechanism for defining callbacks: lisp functions which can be called from foreign code.
> Clozure CL provides facilities which enable multiple threads of execution
Runs on Linux / Windows / Mac OS X and others.
It's amazing that in 2015 we have people that use Emacs, Vim, or other editors that don't have intelligent, realtime code analysis and we consider that "hardcore, programmer machismo".