Hacker News Reader

Comment by geophile | Hacker News Reader

grepping for "foobar" is very different from finding invocations of the function named "foobar". Cross-file search and replace, which is doable from emacs, is different from refactoring. I love emacs and unix, but sorry, it's not an IDE. Intellij, now that's an IDE.

View on HN

Try cscope and xrefactory for emacs.

cscope is very good for searching through C codebases. You can use this with vim too. It has emacs integration using xcscope, and you can use sequences like C-c s g to quickly jump to a symbol.

xrefactory (though non-free) is very good with C++ navigation and can do refactoring. I have used IntelliSense with VAX and xrefactory is much better. This less known program is something incredible for C++.

Also worth mentioning Rope for Python refactoring. Rope's extract method works rather well in Vim.

If UNIX gets language-aware tools that allow me to search-replace methods of a particular name (and not other identifiers with the same name), and if Vim gets autocomplete* that understands which packages/libraries/headers/assemblies I'm importing, then I'll seriously consider moving to UNIX as an IDE.

Until then, I fully agree with you.

* To be ahead of the haters: autocomplete isn't a trick for avoiding having to type some extra characters. It's a way for exploring an API you're only vaguely familiar with. I guess you need to be at least somewhat familiar with statically typed languages in a decent IDE to really appreciate what this can do to your productivity. I seldom need to refer to the API docs of libraries I use.

The thing is that UNIX already has those tools--they just naturally depend on language. So, for example, Emacs has js2-mode and js2-refactor which are about as good as you can expect for JavaScript. There are also similarly capable modes for Lisp.

There are also editor-independent tools like Ensime for Scala which is basically a server that provides IDE-like tools that can be used from Emacs or Vim. Scion provides something similar for Haskell.

There are also things like CEDET for C/C++ which add very IDE-like capability to Emacs. In fact, CEDET is basically just a framework for parsing languages and using that information for things like auto-complete.

Of course, there are some languages conspicuously missing--Java and C# for example. I tried using JDEE for Java a while back and it was really bad; I've never used C# but I don't think it's well-supported either. Ironically, these are two of the languages that need an IDE the most in my experience. (And the language that needs it least--Haskell--has some support.)

So if you're doing serious Java/C# development, then you have a valid point. If you're using another language, chances are that Emacs or maybe several editors can actually support it intelligently. (Also, maybe there are options for C#/Java that I am not aware of. If so, I would appreciate being enlightened.)

Emacs != UNIX. The OP talks about awk, sed, etc.

Emacs, IMHO, is much closer to Visual Studio than to bash+vim.

I figure Emacs ⊂ Unix :)

Besides, some of the tools I listed (e.g. Scion and Ensime) are not part of Emacs but rather stand-alone IDE daemons.

Get what your saying about autocomplete, but the "avoid having to type extra characters" kind of autocomplete is very useful as well. I use it to complete things like long variable names and English text. Its main strength is that you can use it to autocomplete everything, not just the stuff your IDE is aware of.

If you set things up correctly, you can even get most IDEs to automatically fill in method signatures by making guesses based on what's currently in scope. This can save a lot of typing when it works, and even when it doesn't, it doesn't usually waste any keystrokes.

Absolutely, but can it complete column names in your database table? Or Redis commands? Or long hard-to-spell English words and sentences? :)

Vim will autocomplete based on whatever you have in the buffers. So when writing sql I sometimes open up a new buffer and paste the output of desc table.

Is someone begging you to drop your IDE for the UNIX toolchain?

IDEs have their use, Vim and Emacs have their uses, too. I'm perfectly satisfied by Vim (with omnicomplete and tags) for my JavaScript/HTML/CSS coding but I have to turn to Eclipse for AS3.

The "right" tool for the job.

Autocomplete is not tied to statically types languages. For instance, in the Python command line prompt you have autocomplete directly on the live objects.

Smart! But will it work without actually running the code? Will you be sure that the method which is available on the object now is available on each object passed to the method you're writing?

Visual Studio autocompletes Javascript by executing the Javascript and using stub objects for anything that they don't actually want to run (e.g. window, XmlHttpRequest, etc).

That sounds incredibly baroque, complicated, and fragile.

Sure it is, but so what? Would statically analyzing the code really get you any further?

Type inference would get you quite a way. Using a language that allows effective tooling would get you even farther.

Replacing Javascript with a better language has not been possible thus far. There have been many attempts, but getting every browser maker to agree on something is like herding cats.

So, when life gives you lemons, you make lemonade. We're stuck with Javascript. Personally, I think running the code while you're developing it is a brilliant way of dealing with the problem of how to do proper autocomplete on a dynamic language.

.. in other words, javascript

That kind of auto completion is very easy to do. The problem is when you have references whose creation site you can't trace statically.

To be fair, it's also probably a 90/10 situation. And whether or not it's easy to do, it's somewhat rare to see in the tools that most people use for non-static languages.

Even in Java and C#, arguably the best languages re: deep IDE integration, there are edge cases where the IDE can't know everything (reflection, for instance), but it still does the trick most of the time.

You can get some of that functionality out of ctags. I mostly use it for the navigational aspect, but I've seen it used for autocomplete too.

IDE's: When things feel only vaguely familiar, and you know just enough to be dangerous.

Yes, you're right. But a whole bunch of people don't need or use things like automatic refactoring, and more often than not write better code than the people who do.

I don't use IDE's and I love Emacs, but sorry, for "more often than not write better code than the people who do" I feel like I have to invoke "citation needed"...

Jeff Dean uses emacs

The automatic refactoring on IDEs are error proof (I'm thinking about eclipse and java here). Saying that you can do a line without a ruler is one thing, but saying your line will be straighter, I really doubt it. IDEs are important for people that do refactorings. If you don't, fancy IDEs will slow you down. I don't do refactorings that I'm not sure if they will break my code. It's the same reason I don't code with dinamically typed languages and avoid using reflection.

How do you know that the automatic refactorings in your IDE are "error-proof"? I've no experience to suggest otherwise, but it strikes me as a bold claim.

Presumably, you've got a suite of unit tests etc that you are using to verify your code still works post-refactoring. The same test suite would of course work outside of an IDE environment, so I don't think correctness is a valid argument here (but I agree that speed of refactoring is).

I work with smalltalk and java/eclipse so what I say come from this background. With statically typed languages and a IDE to aid, refactorings like rename, pull up, pull down, extract interface and such can be done without changing the code behaviour (if your code don't use reflection).This is a characteristic of statically typed languages, not IDEs, but IDEs can do it automatically. You could do this refactorings without a IDE, but not with text replace. For example, if you need to change the name of a method, category(), and two unrelated classes implements it, your refactor using text replace will change the method signature for both classes. You need to check every place where the code will be changed, and if your codebase is too big with too many calls, this is nearly impossible. The IDE rename the method calls based on the varible type, without risks of errors, if the refactoring is not possible eclipse warns you.

Presumably you still have someone review the automated refactor, right? Plus, smalltalk isn't a statically typed language.

Yes or no. Static code transformation with well defined equilivency is many orders of magnitude more reliable than the error finding rate of a code reviewer.

You still review to make sure it was an improvement, and to make sure that the person making the changes didn't make the mistake. But you don't review the correctness of the transformation itself, at least not any more than you need to review the original code.

Never said that smalltalk is statically typed, I said I work with both on my job. A refactoring don't change the code behaviour by definition. I don't need someone to review my refactoring to look for errors from an automated refactoring, maybe to tell me that the refactor didn't improve my code.

Isn't this what automated unit and performance testing is for? If a refactor (or any code change) causes slippage on any of those indicators it should be flagged or rejected.

There are people who write bad code, with and without IDEs. There are people who write great code, with and without IDEs. I suspect that everyone who writes great code does refactoring. Some prefer to do it manually, and some prefer the automation.

Problem with IDE is that they are often bloated and take lot of space. Also I think I don't use more than half the features they provide. You infact get slower there when you get used to something like Vim/Emacs.

grammar/language oriented libs/functions are missing, nothing more. People still process language with regexps over bytestreams, while they shouldn't. Eventually, and not too long from now, this idea will sink in.

Reply on news.ycombinator.com