It's almost professional negligence. I had the same situation 15+ years ago when Eclipse was coming out and Java was on the rise. We really didn't know Java all that well and so Eclipse's auto-completion and doc popups were a godsend. The guy sitting there with Vi(m) was bogging down beyond belief. It got to the point, where we had to sit him down and tell him he needs to use the right tool for the job or get lost.
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".
I guess I can't tell if this post is a troll or not. :)
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.
I've been curious in the past, trying to find a reason to use an IDE. For me, the loose coupling of tools that you get when working with Vim in a console is priceless.
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.
I was that guy & never switched to an IDE because I was really good at tearing through text with the vim model. intellij's vim plugin (ideavim) is top notch. Just having auto completion, find definition, find file and rename are worth the price of admission.
>Someone not getting their job done is a problem. Someone using vim as their editor is not.
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).
I work on a large C++ codebase in emacs. I find emacs keybindings and extensibility (via elisp) far superior to any IDE - and I have tried Eclipse, CLion (IDEA for C++), Code/Blocks and Netbeans.
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.
CLion is only a few months old and can be considered to be a 1.0 release, its already growing more and more capability on each minor update.
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.
You can use the Go plugin for almost any IDE based on the IntelliJ Platform, that includes CLion and Android Studio. And the best of all, it's free. Give it a try by installing it: https://github.com/go-lang-plugin-org/go-lang-idea-plugin
> 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".
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".
In 2015, do you think most people are using emacs or vim to work with Java or with a Lisp? I think this point stands for the vast, vast majority of people using emacs and vim.
> 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".
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...
"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"."
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.
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.
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 have nothing against Cursive, and in fact, have been eying it from afar. But this kind of comment is just needlessly dismissive with little in the way of substance, as far as I can tell. Would you like to expand on what these features that Cursive has that are "Categorically better" than Emacs'?
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.
I have nothing against Emacs either, and I didn't say that there was anything wrong with its navigation. What I said was the assertion that Emacs and Vim have the best realtime analysis is just wrong - most Emacs modes have none at all.
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.
Do you realise that emacs supports 'intelligent, realtime code analysis'? I program in Go, and I have auto-completion and documentation.
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.
> where we had to sit him down and tell him he needs to use the right tool for the job or get lost.
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".
If you are more productive with a million lines of IDE code backing you up + that language than you would be in Emacs with C++, why would you tell that language to get lost?
That's pure nonsense. There is nothing that prevents languages like Lisp or Smalltalk from being used with a console editor and the compile-pray-debug cycle, but that's no reason to shoot yourself in the foot. This is true of any language, but for some reason there's a large mass of developers of those other languages that see shitty tools and incomplete programs (remember kids, high LOC count means bloat!) as some kind of virtue.
Emacs + slime for Common lisp and tuareg mode for ocaml can do everything that my intellij can do in Java. Then I can extend Emacs to cast a spell, hex vim users and spam HN every time I fixed a bug -- even with plug-ins system I suspect intellij isn't that extensible.
> 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".
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.
Then you have no idea about the current state of intelligent, realtime code analysis. Any old Java IDE should be able to rename length to size on an interface and have all the classes that implement that interface update the name, then have all the places that calls it update to use the new name.
Try that with rename and you will quickly run into trouble, unless you have only one class that has a method called length.
This is still a rename operation. I have difficulty understanding how this would require an IDE for anything but the more complex codebases, and even then, I would much prefer a discrete code server.
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.
Using a tool to refactor is better for source control. The diff sucks, but it sucks because it actually found every instance and refactored properly, meaning going through to review it is simpler as long as you trust the tool. We should be using tools for this type of thing, for exactly the same rules as automated formatting should be the default response to any debate on formatting issues.
It would seem that you've not used Resharper. Best refactoring tool I've ever seen. Actually seems like they are forcing the Visual Studio team to pick up their game.
> (e.g. type signature changes are painful as hell)
Resharper handles this very well.
I think it's that if you use Vim and Emacs properly with the right extensions, then they can be pretty amazing, but if you're just cargo culting and use Vim just to say you use Vim, then it won't work.
I use Emacs to write everything. So, in the last 12 months at least C, C++, D, Haskell, Ruby, and Python.
For Python I use rope and jedi. Auto-complete, goto definition and refactoring.
For C/C++ I use my own package cmake-ide. As the name implies, it only works for cmake builds. But it does work. Similarly to Python, autocomplete, on-the-fly syntax highlighting, goto-definition, ...
For D I use another one of my packages, flycheck-dmd-dub.
For Haskell I can't remember now but it'll all very good.
For Ruby I use flycheck, rubocop and rsense.
Not OP, but I use emacs + jedi[1] for Python development.
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).
I've had reasonable success with company mode and rtags for C/C++. Fairly straightforward to set up and reasonably accurate. I'd hesitate to call it streets ahead of even Xcode, let alone Visual Studio, but it does roughly what you'd hope for, without too much hassle. Definitely worth turning off company mode's complete-as-you type functionality, though...
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.
From hat I've seen I'll disagree. The people that use vim efficiently [emacs users just substitute emacs] don't just use vim. They are also very efficient using the surrounding (Unixoid) environment. Specifically file searching...I'm not sure IDEs have an edge there.
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.
It's more than a little ironic that you claim Emacs/vim users use their tool out of 'harcdore, programmer machismo', and you're doing basically the same thing in the opposite direction by accusing them of being unprofessional.
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.
>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".
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.
Common Lisps exception mechanism is indeed out of this world, but that isn't something that has been implemented in any other language that I know of (not even Clojure) and you have to pay a fortune to get a CL system that works cross-platform with things like threading or a FI that allows lisp callbacks from C code. Java has supported both since forever (and its java.util.concurrent namespace means any old Java programmer has access to all sorts of really advanced non-blocking data structures, including a ConcurrentSkipListMap and an AtomicInteger) and for most people, for almost all tasks, that makes Java better. And for Java you need an IDE.
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".